이것은 우리에게 필요한 기능입니다. 우리는 버그 보고에 대한 승인(approval) 제도를 사용하고 있습니다(15만 명 이상의 사용자들이 있기 때문에, 그들은 보통 먼저 글을 올리고 나중에 읽는 경향이 있습니다). 우리는 "지원(Support)"이라는 일반 포럼도 운영하고 있으며, 여기서 사람들은 "방법"에 대한 질문을 하도록 장려하고 있습니다. 만약 무언가가 고장 나면, 버그 보고 포럼에 글을 올리도록 요청합니다. 문제는 글이 거부되는 경우(중복이거나 적절한 정보가 부족할 때 등) 사용자가 이를 알 수 없다는 점입니다… 글이 단순히 사라지고, 처음부터 제대로 전송되었는지조차 알 수 없게 됩니다.
이것은 사용자들이 마찰이 적은 지원 포럼에 버그 보고를 올리도록 부추깁니다. 보통 내용은 동일하지만, 보고를 재현하기 위해 우리가 필요로 하는 정보가 빠져 있는 경우가 많습니다. 이는 우리에게 더 많은 업무를 발생시키고 있습니다. 저는 예를 들어, 버그 보고를 적절하게 제출하는 방법에 대해 교육하거나, 기존 보고에 대한 링크를 제공하면서 거절 사유를 알려줄 수 있는 기능이 있으면 좋겠습니다.
사용자가 이 문제를 우려 사항으로 보고하는 논리 흐름은 다음과 같습니다:
현재 버그 보고 포럼의 글 작성 방식은, 글이 접수되었음을 명확히 보여주는 피드백을 전혀 받지 못할 수 있습니다. 이러한 글은 게시되기 전에 관리자 승인이 필요합니다 – 그리고 이는 타당합니다. 버그는 많은 사람에게 영향을 미칠 수 있으므로, 승인 메커니즘이 없다면 여러 개의 다른 스레드가 생성될 수 있습니다. 또한 실제로 버그가 아닐 수도 있습니다. 버그 보고 포럼이 버그 목록의 역할을 겸해야 한다면, 글이 승인을 받아야 하는 또 다른 이유가 됩니다.
그러나 글이 결국 게시되지 않는 경우, 글이 접수되었음을 확인해 주는 명확한 알림이 없어 보입니다. 그리고 (유사한 보고든, 해당 글이든) 결국 게시되더라도 상당한 시간이 걸릴 수 있습니다. 문제가 지속되면, "글이 정말로 접수되었을까? 다시 올려야 할까?"라고 생각하게 될 수 있습니다. 또한 아무것도 게시되지 않았는지 확인하는 데 시간을 보내게 되기도 합니다.
이는 동기 부여를 떨어뜨립니다.
반면, 제안 및 피드백(Suggestions & Feedback) 포럼에 게시한 경우라면, 글은 적어도 게시되므로 접수되었음을 확인할 수 있습니다. 나중에 이동되거나 삭제되더라도, 전송 과정에서 사라지지 않았다는 사실은 알 수 있습니다.
이는 동기 부여를 덜 떨어뜨립니다.
문제를 지적함으로써 도움을 주려 하는 사람의 관점에서 보면, 버그 보고에 글을 올리는 것보다 제안 및 피드백에 글을 올리는 것이 더 잘 작동하는 것처럼 보입니다. 버그 보고에 글을 올리려면 최소 하나의 태그를 제공해야 하기도 하며, 이것도 게시를 꺼리게 만듭니다. 또한 관련이 없을 수도 있는 많은 정보를 제공하도록 요구받습니다.
결과적으로, 포럼의 동작 방식은 버그 보고 대신 제안 및 피드백으로 문제를 보고하도록 우리를 부추기고 있습니다.
이것이 승인 메커니즘이 방지하려는 중복 스레드를 생성할 수 있다고 주장할 수도 있습니다. 그러나 우리는 게시 전에 기존 스레드를 확인하도록 되어 있으며, 다른 글들이 게시될 시간을 주려면 잠시 기다린 후 게시하는 것도 충분히 쉽습니다.
따라서 모든 것을 종합해 보면, (보고를 제출하고 싶어 하는 사람의 관점에서) 제안 및 피드백에 글을 올리는 것이 여전히 더 잘 작동하는 것으로 보입니다.
.
