사용자가 너무 빠르게 입력한 모든 사례를 검토 큐로 보내기

우리가 모르게 많은 사용자(약 50명)가 무음 처리(silenced)된 것을 확인했습니다. 사실, 사용자가 너무 빠르게 글을 입력하는 경우 게시물이 검토 대기열로 전송되지만, 일부 경우에는 전송되지 않는 것으로 드러났습니다.

  1. 게시물이 검토 대기열로 전송되지 않으면, 사용자가 무음 처리된 사실을 알 수 없습니다.
  2. 너무 빠르게 입력한 사용자를 처리하는 방식이 두 가지로 나뉘어 있어, 대부분의 모더레이터는 이러한 모든 경우가 항상 검토 대기열로 전송된다고 오해하고 있었습니다. 이는 합리적인 추측이며, 동일한 상황에 대해 두 가지 다른 처리 방식을 두고 있는 시스템의 혼란스러운 구조 때문입니다.
  3. 사용자는 무음 처리되어 게시물이 공개되지 않을 때 좌절감을 느끼며, 모더레이터에게 메시지를 보내는 데 신경 쓰지 않는 경우가 많습니다.
  4. 무음 해제 후에도 게시물은 여전히 사라진 상태이며, 이는 다시 한번 사용자를 위축시킵니다.
  5. 미친 듯이 빠르게 입력하는 사람이 모두 스팸 봇인 것은 아닙니다. 장문의 글을 영어로 번역한 후 게시하기 위해 구글 번역을 사용한 사용자일 수도 있습니다.

이 문제를 개선하여 해당 게시물을 모두 검토 대기열로 전송하도록 변경해 주시기 바랍니다.

5개의 좋아요

저도 같은 상황이었고, 동의합니다. 정말 혼란스럽네요.
이러한 “일부는 검토 대기열로 가고, 일부는 가지 않는” 현상 뒤에 특별한 이유가 있을까요?

사용자가 대량의 텍스트를 붙여넣을 것으로 예상되는 경우라면 사이트 설정을 그에 맞게 변경하세요. (참고로 이는 정말 이상한 일이며, 스팸머일 가능성을 강력하게 시사합니다.) 사이트 설정에서 min_first_post_typing_time 값을 조정하면 됩니다.

문제 해결. :handshake:

@codinghorror 이 부분에 대해 어떤 의견이 있으신가요?
아직 무슨 일이 일어나고 있는지 파악 중입니다.

먼저 내 질문에 대한 답변을 원합니다:

사용자가 대량의 텍스트를 붙여넣을 것으로 예상된다면 사이트 설정에서 min_first_post_typing_time을 변경하세요.

이 설정을 변경하셨나요? 아직 변경하지 않았다면 그 이유는 무엇인가요? 변경을 막고 있는 요인은 무엇인가요?

1개의 좋아요

아니요, 해당 설정은 여전히 기본값인 3000ms로 되어 있습니다.
왜 변경해야 합니까? 사람들이 구글 번역기를 사용해 내용을 붙여넣은 뒤 엔터를 누르는 상황을 충분히 상상할 수 있으므로, 이 설정을摆弄할 이유는 없다고 생각합니다.

아마도 제 질문이 충분히 명확하지 않았던 것 같습니다.

min_first_post_typing_time 도움말은 다음과 같이 설명합니다:

첫 번째 게시물을 작성할 때 사용자가 입력해야 하는 최소 시간(밀리초 단위). 이 임계값을 충족하지 못하면 게시물이 자동으로 승인 대기열로 이동합니다.

제 이해를 말씀드리자면: 임계값이 충족되지 않을 때마다 예외 없이 모든 게시물이 검토 대기열로 들어간다는 것입니다.

하지만 "스태프 작업(Staff Actions)"에서 확인한 바로는, 때때로 시스템이 너무 빠른 타이핑을 이유로 사용자를 무음 처리(silenced)하지만, 해당 사용자는 검토 대기열에 표시되지 않습니다.

제가 지적하는 바로는, 너무 빠르게 타이핑하는 대부분의 사용자는 검토 대기열로 이동하는 반면, 일부 사용자는 검토 대기열로 이동하지 않는 이유를 이해하고 싶습니다.

제 기대는 min_first_post_typing_time 값이 1초든 60초든, 게시물이 임계값을 충족하지 못하면 예외 없이 검토 대기열로 가야 한다는 것입니다. 그러나 현실에서는 그렇지 않은 것을 보고 있습니다.

2개의 좋아요

맞는 말씀이지만, 문제의 근본적인 원인을 해결하려면 이 설정 값을 더 낮추어야 합니다. 대부분의 사용자가 콘텐츠를 게시에 일반 활동처럼 붙여넣고 있기 때문입니다. 따라서 다른 일반적인 Discourse 인스턴스의 사용자들과는 다른 특성을 가진 사용자층을 보유하고 있으므로, 해당 인스턴스에서는 이 설정을 반드시 더 낮은 값으로 설정해야 합니다.

이것이 제 문제의 근본적인 원인인 이유를 이해하지 못하지만, min_first_post_typing_time을 3000에서 1500으로 변경했습니다.
제 기대는 이것이 정확히 아무것도 바꾸지 않을 것이라는 것입니다.

동의합니다. 계속 붙여넣기만 하는 사용자들을 대상으로 하고 있으므로, 100밀리초처럼 훨씬 더 낮은 값으로 변경하는 것이 좋다고 생각합니다. 3초에서 1.5초로 줄이는 것만으로는 충분하지 않다고 봅니다.

좋은 소식은 이 제한이 신규 사용자에만 적용되므로 _기존_의 기존 사용자들은 영향을 받지 않는다는 점입니다.

와, 100ms? 제가 직접 선택했다면 절대 안 선택했을 값이네요. 한번 시도해볼게요.

1개의 좋아요

사람들이 텍스트를 붙여넣는 것이 왜 이상하다고 말씀하시는 건가요? 제가 활동하는 포럼 중 하나는 전화 앱 개발에 전념하고 있습니다. 이 앱에 대한 피드백은 전 세계에서 오며, 영어를 말하거나 쓰지 못하는 사람들로부터 오는 경우도 많습니다. 그들은 구글 번역을 사용해 영어로 피드백을 전달하려고 시도하기 때문에, 자연스럽게 붙여넣기가 발생합니다. 우리는 이것이 매주 일어난다고 추정합니다.

이것은 게시글이 거부되는 문제를 해결하지만, 이미 지적하신 대로 스팸이 증가하는 문제를 도입합니다. 따라서 제가 요청하는 것은 이러한 사례를 처리하는 더 스마트한 방법입니다: 해당 게시글을 무작정 거부하는 대신 검토 대기열로 보내는 것입니다. 검토 대기열은 처음부터 이런 용도로 만들어진 것이 아니었나요?

당신은 붙여넣기를 이상하다고 말하지만, 저는 게시글을 무언가 없이 거부하는 것을 이상하다고 말합니다.

1개의 좋아요

또한, system 사용자가 silenced_by_staff: New user typed too fast로 침묵 처리한 신규 사용자가 최소 두 명 있었는데, 이 사용자들은 리뷰 대기열에 전혀 표시되지 않았으며, 사용자 프로필 요약에도 숨겨지거나 삭제된 게시글을 나타내는 배너 메시지가 없습니다.

@community-moderators 이 스레드를 #contribute:bug으로 이동하거나 이 주제와 병합할 수 있을까요?

1개의 좋아요

Contribute > Bug 주제에 인용되어 있어 정보가 연결되어 있습니다. :+1: 현재 문제를 추적할 수 있도록 일관된 재현 단계를 찾고 있습니다. 도움이 될 만한 추가 정보가 있으시면 Automatic silencing for "typing too fast" doesn't notify administrator 에 공유해 주세요. :crossed_fingers:

Automatic silencing for "typing too fast" doesn't notify administrator 를 이유로 닫힘