거부된 게시물을 수정할 수 있는 기능 추가 요청

기여 UX
1

관리자가 게시글을 거부하면 다음과 같은 메시지가 표시됩니다.

Hi [user],

We’ve reviewed your new topic titled “[topic titles]” and have some feedback for you.

Reason: N/a

Feedback: This is what it shows when your post is given feedback

You can edit your topic’s original post below and re-submit to make the suggested changes, or reply to this message if you have any questions.

하지만 실제로는 아래에 아무것도 표시되지 않아 게시글을 수정할 수 없습니다.
승인이 필요한 게시글을 생성한 후 수정이 필요한 이유로 거부된 경우, 해당 테스트 사용자에게 전송된 개인 메시지(PM)의 화면 캡처입니다.

What the PM looks like of a denied post with revision
What the PM looks like of a denied post with revision999×927 59.3 KB

아래에 수정할 수 있는 부분이 전혀 없습니다.
따라서 제 요청은, Discourse에서 개인 메시지(PM) 내에서 게시글 자체를 실제로 수정할 수 있는 기능을 추가하고, 수정 후 포럼에 자동으로 다시 제출(resubmit)하여 관리자가 다시 검토할 수 있도록 해달라는 것입니다.

3개의 좋아요
How to Understand the Request Revision Feature
How to Understand the Request Revision Feature
No edit option for flagged post?
2

좋은 지적입니다! 이 문제는 인터페이스의 언어와 관련이 있어 Contribute > UX 채널로 이동했습니다.

모더레이터에게 받은 개인 메시지(PM)를 검색해 비슷한 내용을 찾았습니다. 첨부해 주신 스크린샷과 PM에서 복사한 텍스트를 확인해 보면, 피드백을 받는 사용자가 작성한 부분은 "test post for meta topic here"입니다. 나머지는 템플릿에 포함된 내용입니다.

말씀하신 대로 "아래"에 있는 게시글을 수정할 수 없기 때문에 이 안내 문구가 혼란을 주고 있습니다. 수정하려면 해당 토픽으로 돌아가서 거기서 수정해야 합니다. 아니면 모더레이터와 논의하기 위해 답글을 달 수 있습니다.

이 변경은 UI를 너무 복잡하게 만들기 때문에 불가능할 것 같습니다.

여기서는 다음과 같이 안내 문구를 개선하는 것이 해결책이 될 것 같습니다:

제안된 내용을 반영하기 위해 게시글을 수정하거나, 질문이 있으시면 이 메시지에 답글을 남겨 주세요.

더 쉽게 원래 게시글로 돌아가도록 실제 게시글에 대한 링크도 제공할 수 있습니다.

1개의 좋아요
3

그것도 괜찮은 방법이지만, 문제는 관리자가 게시글을 거부하면 더 이상 편집할 수 없다는 점입니다. 개인 메시지는 보내지지만, 사용자는 다시 돌아가서 게시글을 처음부터 새로 만들어야 합니다.

또한, 게시글 제목과 함께 사용자의 초안 페이지에 답글이나 초안을 만들어 게시글을 다시 작성하게 하고, 그걸 다시 제출하도록 하는 방식도 좋을 것 같습니다.

이 아이디어가 말이 되는지 알려주세요.

추가로, 링크를 추가하게 되면 게시글을 거부할 때 삭제할 수 없게 되는데, 그러면 사용자가 자신의 게시글을 다시 확인하고 평가할 수 없게 되는 건 아닌지 걱정됩니다?

4

아, 그렇군요. 검토 대기열은 사용자가 새 게시물로 복사해서 수정할 수 있도록 편의를 위해 (현재 삭제된) 게시물의 사본을 제공하는 것뿐이군요. 이렇게 하면 더 간단해집니다:

게시물이 삭제되었지만, 편의를 위해 아래에 사본을 제공합니다. 제안된 변경 사항을 반영하여 다시 게시하거나, 질문이 있으시면 이 메시지에 답글을 남겨 주세요.

1개의 좋아요
5

대기 중인 ‘post/topic’를 편집할 수 있으면 좋겠습니다. [사실 이 시점에서 post/topic라기보다는 그 전 단계에 가깝다고 생각합니다.] 이렇게 되면 사용자 경험의 매끄러움이 크게 향상될 것입니다. 과거에 이 부분에 대해 논의가 있었던 것 같습니다.

현재 대기 중인 게시물은 게시물 스트림과 /activity/pending 페이지(이 페이지에는 대기 중인 게시물과 토론이 모두 포함됩니다)에 모두 표시되지만, 삭제만 가능하고 수정은 불가능합니다. 검토 대기열(review queue)에서 관리자/모더레이터가 ‘수정(Revise)’을 통해 승인 처리하는 방식과 유사하게 대기 중인 게시물을 편집할 수 있게 한다면, 게시물을 삭제하지 않고 ‘대기 중’ 상태로 유지할 수 있습니다. 그러면 피드백 PM에 링크를 포함시켜 사용자가 해당 페이지로 쉽게 이동하여 수정하고 다시 제출할 수 있게 할 수 있습니다. :magic_wand:

동시에 사용자와 모더레이터가 동시에 편집하는 것을 방지하기 위해 다듬어야 할 부분이 있을 수 있지만, 아마도 새로운 자동 검토 가능 클레임(auto reviewable claiming) 기능이 이를 돕고 편집 잠금을 제공할 수 있을 것입니다.

또한, 검토 가능 항목(Reviewable)이 ‘수정(Revise)’로 처리된 후에도 이를 허용할 수 있는 조치가 필요합니다. 이론적으로는 플래그가 처리되었지만, 여전히 대기 중 상태일 수 있기 때문입니다. (수정이 언제 올지, 혹은 아예 오지 않을지 모르는 무기한의 시간을 기다리는 동안, 검토 대기열에 라이브 플래그로 남아 있는 것은 원치 않을 것입니다.) :thinking:

4개의 좋아요
6

리뷰 대기열에서 작업 중인 새로운 변경 사항으로 인해 플래그가 지정된 항목을 다른 사람에게 할당할 수 있게 될 것 같습니다. 이 경우 게시한 사용자에게 다시 할당할 수도 있지 않을까요?

7

‘포기(abandonment)’라는 실제 가능성을 허용할 수 있는 시스템이 필요할 것 같습니다. 즉, 합리적인 시간 경과 후 스스로 정리될 수 있는 것이죠.

예를 들어, 원래의 대기 중인 항목을 삭제하되, 사용자에게는 완전히 동일해 보이도록 즉시 동일한 복제본으로 대체하는 방식과 같은 기발한 방법이 있을 수 있습니다. 이렇게 하면 재제출 시 큐에 새로운 검토 가능한 항목을 생성할 수 있습니다.

또한 삭제된 게시글 삭제와 유사한 삭제 타이머를 도입할 수도 있습니다(단, 24시간보다는 훨씬 합리적인 ‘수정 시간 창’을 설정하는 경우).

1개의 좋아요
8

사실 그렇지 않은 것 같습니다. 피드백과 함께 게시물이 거부된 사용자가 거부를 확인할 수 없을 가능성이 있고, 2일 후에 다시 돌아왔을 때 24시간 삭제 타이머가 이미 만료되어 게시물을 수정할 수 없게 될 수 있습니다. 이는 다른 포럼에서 문제를 일으킬 수 있습니다.
아마도 기본값이 24시간으로 자동 설정되어 있을 수 있고, 관리자 대시보드에서 이 자동 타이머를 변경할 수 있는 기능이 있는 것일까요?

2개의 좋아요
9

아, 혼동을 드려서 죄송합니다. 기존 관리자 설정인 삭제된 게시물 유지 시간의 기본값이 24시간이라는 점을 말씀드린 것이었습니다. 비슷한 기능을 여기서도 적용하여 대기 중인 게시물이 영원히 남아있는 것을 방지할 수는 있지만, 훨씬 더 넉넉한 시간 범위가 필요할 것입니다.

2개의 좋아요
11

그렇다면 그것으로 PM이 되는 건가요?

타이머 포함인가요?

?그 후 거기서 수정하고 다시 제출할 수 있습니다

12

음. 솔직히 말해서 그렇게까지 생각하지는 않아요. 다만 제품 팀이 이 아이디어에 관심이 있고, 개발 팀이 이것이 구현하기에 가장 좋은 방법이라고 생각한다면 반대하지는 않을 거예요. :slight_smile:

제 생각에는 해당 항목이 대기(pending) 상태의 '항목’으로 유지되고, /pending 페이지에서 편집할 수 있도록 해야 합니다(최소 한 게시글/토픽인 것처럼 보이는 형태). ‘수정(Revise)’ 시 받는 PM은 현재와 표면적으로는 동일하지만, 대기 중인 항목을 편집할 수 있는 곳으로 이동하는 링크가 포함되고, "자동 삭제되기 전에 {30일} 이내에 기여물을 수정하여 다시 제출하십시오"라는 일반적인 안내 문구(또는 비슷한 내용)가 추가될 것입니다.

13

사실 좋은 아이디어인 것 같고 가장 합리적인 것 같습니다.
하지만 리뷰 전체 리워크에 대해 UX를 정말 엉망으로 만들지 않을까요? 그리고 메시지라는 최신 추가 기능을 넣는 것도요? @JammyDodger

14

솔직히 말하면, 여기서는 아이디어가 대부분이고 개발 팀이 [1] 내 머릿속 그림이 최선의 방법이 아니거나, 아예 실현 불가능하다고 말할 수도 있습니다. :slight_smile:

하지만 첫 번째 대기 항목을 독립된 엔티티로 취급한다면(즉, 플래그가 처리되고, PM이 전송되며, 검토 대상이 더 이상 대기 상태가 아닌 경우), 수정 및 재제출을 허용하기 위해 두 번째 중복 대기 엔티티를 생성할 수 있습니다. 그러면 재제출 시 승인 대기열에 ‘새로운’ 검토 대상으로 삽입될 수 있습니다. 수정을 기다리는 대기 항목은 /pending 페이지에서 명확하게 표시하여 혼란을 줄이는 것도 좋습니다(모드 승인 대기 중인가, 내가 수정해야 하는가?).

  1. (이 기능을 실제로 개발하기로 결정한다면) ↩︎

15

하지만 두 번째는 어디에 두어야 할까요? 검토를 위해 두 번째를 다시 변경하거나, 예를 들어 감시 단어를 빼먹는 경우는 어떻게 해야 할까요?

16

질문을 100% 정확히 이해한 것은 아니지만, 나는 다음과 같은 플로우를 구상하고 있습니다:

flowchart TD
    A[게시물/토픽 생성] --> B[승인 대기열에 대기]
    B --> C[수정]
    C --> D[수정 대기]
    D --> E[재제출]
    E --> B[승인 대기열에 대기]
    
    B --> H[게시물/토픽 승인] --> I[사이트에 게시]
    B --> F[게시물/토픽 거절] --> G[삭제]

    style F fill:#ff4c4c,stroke:#000,stroke-width:2px
    style H fill:#4caf50,stroke:#000,stroke-width:2px

따라서 2차, 3차, 4차 수정 등은 이 루프를 반복하게 됩니다(충분하다고 판단될 때 관리자가 수동으로 시간을 종료할 수 있습니다 :)).

‘수정’ 옵션은 더 나은 버전이 나올 가능성이 높은 경우에 사용될 것으로 예상합니다(즉, 그 기준에 미치지 못하는 것은 애초에 수정을 위해 반환되지 않습니다).

2개의 좋아요
17

네, 그건 좀 더 말이 되는 것 같습니다. 그런데 만약 post rejected reviews delte라는 이름의 설정을 추가해서, 관리자가 (x)번의 수정 거부 후 게시물을 자동으로 삭제하도록 설정하면, :infinity: 번의 수정을 방지할 수 있지 않을까요?

18

인터페이스의 복잡성에 대해: 디스코봇 튜토리얼의 방식과 유사한 방법을 사용할 수 있다고 생각합니다. 이 방식에서는 시스템이 사용자 식별을 사용하여 이 개인 메시지에 편집할 내용을 자동으로 전송하고, 사용자가 편집 대상 게시물의 소유권을 획득할 수 있도록 합니다. 또한 이 방식은 외부 인터페이스 변경이 필요하지 않으며, 시스템이 보낸 원래 메시지에 기능적 확장이 필요하지 않습니다. 남은 부분은 편집 시 검토를 트리거하는 프로세스의 문제입니다(각 편집 후 검토를 자동으로 트리거하는 것과, 사용자가 특정 버튼을 클릭하거나 특정 단어가 포함된 후속 답변을 보내어 수동으로 검토를 트리거하는 것 중 어떤 것이 더 좋다고 생각하시나요?).

1개의 좋아요
19

최근에 이 문제를 겪었는데, 현재 상태가 이상적이지 않다는 데 동의합니다. 당분간 이 문제를 개선할 수 있는 가장 간단한 방법은 거절된 게시물의 내용을 초안으로 생성한 후, 사용자가 해당 초안으로 이동하여 수정하고 다시 게시할 수 있도록 링크를 제공하는 것이라고 생각합니다.

이 동작을 업데이트하기 위해 PR을 열었습니다:

image
image1382×1522 191 KB

1개의 좋아요
How to Understand the Request Revision Feature
20

오, 도움이 되네요. 네, PR이 승인되면 그렇게 하면 될 것 같아요. 다음 단계는 무엇인가요?

1개의 좋아요
21

PR이 승인되면 팀이 이를 병합하며, 이후 업데이트에 포함됩니다. 특정 사이트에 업데이트가 적용되는 시기는 해당 사이트가 사용하는 릴리스 채널에 따라 달라집니다.

1개의 좋아요