모더레이터로서 저는 때때로 문제 있다고 생각하는 게시물을 접하게 됩니다. 다만 해당 인물과 이전에 개인적인 갈등이 있었던 전력이 있어, 제가 직접 조치를 취하기보다는 단순히 신고(flag)하는 것이 더 적절하다고 생각합니다. 하지만 불행히도 신고를 하면 해당 게시물이 자동으로 숨겨져서, 원래 의도와는 다르게 됩니다.
다른 모더레이터들에게 수동으로 메시지를 보내는 것을 제외하고, 이런 상황에 적합한 다른 방법이 있을까요?
모더레이터로서 저는 때때로 문제 있다고 생각하는 게시물을 접하게 됩니다. 다만 해당 인물과 이전에 개인적인 갈등이 있었던 전력이 있어, 제가 직접 조치를 취하기보다는 단순히 신고(flag)하는 것이 더 적절하다고 생각합니다. 하지만 불행히도 신고를 하면 해당 게시물이 자동으로 숨겨져서, 원래 의도와는 다르게 됩니다.
다른 모더레이터들에게 수동으로 메시지를 보내는 것을 제외하고, 이런 상황에 적합한 다른 방법이 있을까요?
그렇지 않다고 봐. 이 문제를 처리하는 가장 쉬운 방법은 속삭임을 통해 다른 관리자들을 조용히 @멘션하는 거라고 생각해.
생각나는 방법 중 하나는 테스트용 TL0/TL1 사용자를 사칭하여 게시물을 플래그하는 것입니다. 다만 이 방법은 다소 복잡할 수 있습니다.
테마 컴포넌트를 사용하여 플래그 모달에 버튼을 추가하고, 해당 버튼을 통해 테스트 사용자의 관리자 페이지로 이동하여 사칭하는 방식도 생각해 볼 수 있습니다. 이를 위해 Custom Components -- add button or text at any plugin outlet 와 같은 방법을 활용할 수 있습니다.
모든 플래그 유형이 게시물을 즉시 숨기는 것은 아닌 것 같습니다. "다른 것"을 안전하게 사용할 수도 있고, 사용자 정의 플래그를 만들 수도 있습니다.
만약 그것이 "문제"라고 생각한다면, 적절한 유형으로 플래그를 달고 다른 moderator가 스스로 판단하도록 하세요. 그 후, 다른 moderator가 동의하지 않는 경우 숨김 해제(un-hide)를 선택할 수 있습니다. 이것이 검토 대기열(review queue) 및 Discourse moderation의 일반적인 올바른 워크플로입니다. "해당 인물과의 과거 개인적 갈등 이력"이라고 말씀하신 것은 moderator로서의 판단이 영향을 받을 수 있다는 의미로 이해되며, 따라서 일반 사용자처럼 행동하여 적절하게 플래그를 달아야 합니다. 언급하신 대로, 다른 대안은 다른 스태프가 볼 수 있는 속삭임(whisper) 게시물을 사용하는 것이거나, "가끔"만 그런다고 하셨으므로 단순히:
여기저기서 Customization > Theme component 코드를 작성해 보았는데, 신고된 멤버와 게시물을 신고한 멤버를 비교하여 플래그를 확인하는 것이었습니다. 만약 그 모더레이터가 신고된 게시물의 소유자이거나 게시물을 신고한 사용자 본인이라면, ‘보류’ 버튼을 제외하고 리뷰 버튼을 숨기는 방식입니다.
AI를 사용해 보았지만, 최근 플래그 리뷰 메뉴에 생긴 변경 사항이 문제를 일으키고 있는 것 같다는 의심이 듭니다.
이 기능은 카테고리 모더레이터에게도 유용할 것입니다. 제 생각에는 이렇게 하면 모더레이션 조치의 무결성을 보장할 수 있습니다. 과거에는 어떤 모더레이터가 의견 충돌이 있던 멤버의 게시물을 신고한 후, 자신의 플래그에 동의하는 경우가 있었거든요. 일부에서는 '더 나은 모더레이터를 고르라’고 할 수도 있겠지만, 유혹을 방지하는 간단한 방법을 마련하는 것이 최선이라고 생각합니다.
물론 TC(테마 컴포넌트)가 지나치게 보안에 강하지는 않을 수 있습니다. AI 코드가 제안한 대로 누군가가 우회할 경우 로그를 생성하도록 구성할 수 있을 것입니다. 아마도 나중에 Dev 포스트에서 샘플 코드를 공유할 것입니다.
리뷰 큐에서 무언가를 숨기는 컴포넌트를 만들려는 시도가 게시물이 모더레이터의 플래그로 인해 숨겨지는 것을 어떻게 방지하는지 정확히 이해하지 못하겠습니다. 신뢰도가 높은 사용자의 플래그는 의도된 것보다 더 큰 권한을 가질 수 있습니다. @Steradiant는 게시물을 숨기지 않는 플래그를 원했던 첫 번째 사람이 아닙니다. Trigger Moderator Attention Instead of Auto-hiding Flag
그러면 내가 목적을 충분히 설명하지 못해 이해하기 어려우셨겠군요.
아이디어는 꽤 단순합니다. 리뷰 대기열(Review Queue)을 검토하는 노드(Nod)가 문제된 콘텐츠와 직접 관련이 있다면, 해당 콘텐츠의 검토를 다른 관련 없는 중재자에게 이관하는 것 외에는 선택지가 없습니다.
즉,
mlMod는 플래그가 지정된 게시물의 작성자입니다. 작성자는 자신이 작성한 콘텐츠에 대한 플래그를 해결할 수 없습니다. 무결성을 위해 다른 중재자가 이를 검토해야 합니다.
Mod는 해당 게시물을 플래그한 사용자입니다. 이 또한 이해 충돌에 해당하므로, 자신이 플래그한 게시물의 플래그를 해결할 수 없습니다. 따라서 다른 중재자가 검토하고 플래그를 해결해야 합니다.
이 방식은 편향된 중재를 방지하는 안전장치를 마련함으로써 중재 프로세스의 무결성을 보장합니다. 제 경우를 들자면, 의견 충돌로 인해 다른 사용자에게 플래그를 부과했던 동료 중재자가, "중재자와 논쟁"과는 무관한 상황에서 자신이 부과한 플래그를 스스로 해결하는 것을 방지할 수 있습니다.
정책을 구현하고 팀에 적합한 인원을 선택하는 데 의존할 수 있지만, 유혹을 제거하는 가장 좋은 방법은 예방적 안전장치를 두는 것입니다. 또한 카테고리 중재를 추가함으로써 이 안전장치는 자원봉사자 중재자들의 무결성도 보호합니다.
이 단순한 아이디어는 중재의 중립성에 도움이 됩니다.