검토 대기열에서 사용자를 무음 처리/정지할 수 있는 기능을 추가할 수 있을까요?
우리의 커뮤니티가 우호적인 링크 정책(즉, no-follow가 아닌 정책)을 가지고 있다는 이유로 여러 SEO 포럼에 언급되어 왔기 때문에, 해당 사이트들로부터 상당한 양의 스팸 트래픽을 받고 있습니다. 물론 해당 개념이 등장한 이후로 거의 no-follow 정책을 적용해 왔지만요. 스팸 트래픽은 물결처럼 찾아오는데, 일부는 자동으로 스팸을 뿌리고, 일부는 상당한 시간을 기다렸다가 접근하며, 일부는 호출/응답 방식의 스팸을 진행합니다. 심지어 일부는 팀을 이루어 오는 경우도 있는데, 아마도 우리가 몇 명을 놓치면 그들에게 존재하지도 않는 소량의 링크 주스(link juice)가 전달되기를 바라는 것 같습니다.
다양한 유형의 스팸 활동으로 인해, 우리는 문서화와 추적을 충분히 갖추는 것이 더 이롭다고 판단했습니다. 이는 SSO(Single Sign-On) 때문에 삭제/차단(이것이 우리가 사용해야 할 조치)을 수행할 때 필요한 사항입니다. 그러나 문서화가 부족하여(작은 정보 팝업은 있지만 로그 기록 자체에는 표시되는 내용이 없음) 스팸 유저를 주시하기가 더 어려워졌고, 실수로 스팸 유저로 지정된 사람들을 처리하는 것도 힘들어졌습니다(우리는 결국 사람이니까요). 그래서 결국 수동으로 사용자를 정지하고, 게시물을 승인한 뒤 삭제하는 방식으로 대응하고 있습니다.
플래그 스팸 처리 과정에서 나타나는 “조치 취하기” 버튼을 사용할 수 있다면, 스팸 대응 과정에서 일관된 행동이 가능해질 뿐만 아니라, 문제 있는 사용자의 패턴을 파악하는 데 가장 높은 가시성을 확보할 수 있을 것입니다.
6개의 좋아요
저는 보통 이런 “업” (bump)을 하는 사람 중 하나가 되고 싶지 않지만, 이 문제를 다시 한번 검토해 주셨으면 해서 글을 올립니다.
스팸이 정말 많이 들어옵니다… 정말로요. 시간당 15~20개의 스팸 메시지가 쏟아지는 날도 있습니다. 그래서 우리는 사용자 삭제 방법을 사용할 수밖에 없었습니다. 그렇지 않으면 승인, 게시글 이동, 신고, 조치 수행(직접 조치가 가능한 경우) 또는 대기열로 이동 후 조치 수행이라는 4~5단계 과정을 거쳐야 하기 때문입니다. 이 모든 과정 동안 커뮤니티 멤버가 “승인된” 게시글을 신고하지 않기를 바랄 수밖에 없습니다. 그렇게 되면 우리 업무가 더 늘어나기 때문입니다.
하지만 이제 직원이 인간이라는 현실적인 문제에 부딪히고 있습니다. 가끔은 게시글이 의심스러워 보였지만 실제로는 정당한 사용자로, 그 사용자가 삭제되는 일이 발생합니다.
그런데 사용자 복구(undelete) 기능이 없습니다. 적어도 제가 찾을 수 있는 범위에서는요. 또한 로그를 통해 삭제된 사용자를 확인하는 깔끔한 방법도 없습니다. 로그를 확인하려면 삭제된 사용자 각각의 정보 팝업을 확인하거나, 로그를 내보낸 후 해당 사용자를 찾아야 합니다.
결국 우리는 "어떤 악마와 함께 살 것인가"라는 딜레마에 직면해 있습니다. 조정(moderation) 시간을 두 배 또는 세 배로 늘리거나, 지원 팀이 경계선에 너무 가까운 게시글을 작성해 우연히 삭제된 정당한 고객들을 처리해야 하는 부담을 지우는 것 중 하나를 선택해야 합니다.
참고: 검토 대기열에 게시글 거부(reject post) 기능이 있다는 것은 알고 있습니다. 하지만 이 기능은 사용자 자체를 처리하지 않기 때문에 양날의 검입니다. 사용자는 다시 돌아올 수 있고, 대기열에는 이전에 게시글이 거부된 적이 있는 사람이라는 표시가 없기 때문입니다…
리뷰 대기열로 들어오는 스팸 중 가장 큰 비중을 차지하는 방법은 무엇인가요?
Akismet에 의해 플래그가 지정된 경우, ‘예’ 드롭다운 메뉴에 ‘일시 정지’ 옵션이 있는 것 같습니다:
커뮤니티 플래그가 지정된 경우에도 해당 옵션이 있는 것 같습니다:
혹시 우리가 놓친 다른 옵션이 있을까요?
저희 쪽에서는 대부분이 "새 사용자의 첫 게시물이 의심할 정도로 빠르게 입력되어, 봇이나 스팸머로 추정됨"이라는 유형입니다.
해당 게시물에는 게시 승인, 게시 삭제, 사용자 삭제 기능이 있습니다. 다른 두 대기열과 동일하게 사용자 정지 옵션이 있는 기능을 제공해 주셨으면 합니다. 게시 거부 메뉴에 드롭다운 형태로 추가할 수 있을 것입니다.
2개의 좋아요
아, 그렇군요. 해당 항목은 대기 중인 게시물/토픽으로 분류되므로 플래그 버튼 대신 ‘승인’ 버튼을 상속받습니다:
해당 설정은 잠재적인 봇과 스팸을 걸러내기 위해 특별히 존재하는 것이므로, 일관성을 위해 Akismet 옵션과 동일하거나 유사한 옵션을 제공하는 것이 좋다고 생각합니다.
개인적으로는 스팸을 '삭제’하는 편을 지지합니다 
하지만 대신 계정을 정지하는 방식을 선호하는 사이트도 몇 곳 알고 있습니다. 다른 항목들에 해당 옵션이 있다면, 이 항목에도 포함되는 것이 적절하다고 생각합니다(가능하다면).
4개의 좋아요
문제를 보여주는 스크린샷 예시입니다:
코드를 빠르게 살펴봤습니다. 해당 사용자 작업은 ReviewableQueuedPost 클래스 메서드에서 여기 근처에 추가되는 것으로 보입니다. 이 클래스는 delete_user_actions()를 제공하는 Reviewable을 상속받습니다.
레이블은 여기에서 가져오며, ReviewablePost 클래스(이것도 Reviewable을 상속)에서 사용 중인 reject_and_suspend에 대한 레이블이 이미 존재합니다.
저는 레일스(Rails)에 대해 잘 알지 못하지만, "게시물 승인"과 “사용자 삭제” 사이에 “사용자 거부 및 정지” 권한을 해당 페이지에 추가하는 데는 큰 노력이 필요하지 않을 것 같습니다.
이 옵션이 있으면 가끔씩 사용자가 나쁜 하루를 보내는 상황을 방지하는 데 도움이 될 것입니다.
2개의 좋아요
공정하게 말하자면 (이것은 볼트로닉(Boltronic)과 공유할 생각을 하지 못했던 부분이지만) 우리는 의도적으로 게시물 거부 버튼을 숨겼습니다. 이 버튼은 단순히 게시물을 삭제할 뿐이며, 그에 따른 로깅 기능이 없기 때문입니다 — 버튼을 숨겼을 당시에는 그랬습니다 (적어도 로깅 기능이 있다면 다시 표시해 드릴 기꺼이 하겠습니다).
하지만 사용자 삭제 버튼에 유사한 접근 방식을 적용하여, 게시물 거부와 게시물 거부/사용자 정지 옵션을 추가한다면 그것도 잘 작동할 것이며, 버튼 간 동작 일관성이 유지될 것입니다.
"사용자가 너무 빨리 입력함"과 같은 항목은 이제 검토 대기열(Review Queue) 기록에 저장되는 것 같습니다. 
1개의 좋아요
