궁금한 점이 있습니다. 이 지침은 주로 누구를 대상으로 한 것일까요? 해당 토픽 자체에 게시하셨으므로, 토론 참여자들을 위한 것이라고 가정합니다. 하지만 실제로는 어떻게 처리되어야 할까요?
많은 경우, 문제가 발생하여 누군가 토픽을 열 때 서드파티 플러그인, 테마 또는 컴포넌트가 관여하는지 즉시 명확하지 않습니다. 이는 대개 토론이 진행되면서야 비로소 드러나는 경우가 많습니다. 그 시점에는 우리 중 대부분은 게시물을 전용 토픽으로 이동시킬 수 없습니다. 따라서 이 문제를 처리해야 한다고 생각하는 방식은 제 생각과 다를 것입니다.
사용자가 게시하기 전에 이미 문제의 원인을 알고 있을 것으로 기대하나요? 불확실한 경우 Contribute > Bug 대신 #support에서 토픽을 시작하는 것이 합리적일 수 있다는 점에는 동의합니다. 하지만 이 토픽도 #support로 이동시키지 않으셨으므로, 그것이 당신이 제안하는 방식인 것 같지는 않습니다.
저는 우리가 일반 참여자로써 여기에서 무엇을 다르게 해야 했는지 이해하려고 노력하고 있습니다.
이 경우 처음에는 원인이 불명확했으므로 #contribute:bug에 게시한 것이 옳았다고 생각합니다. 이후에는 테마 컴포넌트 관련 주제로 병합되었어야 합니다. 그 전까지는 컴포넌트가 문제의 원인임을 나타내는 태그를 붙여 #contribute:bug에 머물러 있어도 괜찮았을 것 같습니다.
모든 종류의 주제를 수용하는 포괄적인 공간이 되어버린 General 카테고리는 별로 좋아하지 않습니다. 사람들이 어디에 게시해야 할지 몰라서 #general에 올리는 상황을 상상해 볼 수 있습니다. 그런 경우 модератор들은 이미 적절한 장소가 존재하면 해당 게시물을 옮기거나, #general에 유사한 주제가 충분히 쌓이면 새로운 카테고리를 만들 수 있습니다.
샘, 이런 경우 게으를 때는 신고(플래그) 기능을 자유롭게 사용해도 됩니다. 그러면 модератор들이 처리할 수 있으니까요.
이것은 unsupported-install 태그를 사용하는 것과 유사하게, #3rd-party라는 새 태그를 생성하고 사용할 수 있다는 생각을 하게 합니다. 예를 들어 Dashboard New Posts statistics broken 의 경우, Discourse 디버깅에 대해 전반적으로 배울 수 있는 내용이 많지만, 대화의 일부만이 문제를 일으킨 특정 플러그인에 관한 것입니다. 저는 문제를 좁혀 나가는 방법에 대한 예시를 찾기 위해 이 장소를 보지 않을 것이므로, 전체 대화를 해당 플러그인의 토픽으로 이동시키는 것이 이상적이라고 생각하지 않습니다.
따라서 #3rd-party 태그를 달아 별도의 토픽으로 유지하는 것이 더 합리적이라고 생각합니다. 버그 카테고리보다는 지원 카테고리에 배치하는 것이 더 나을 수 있습니다. 그렇게 하면 사용자가 해결책을 선택할 수 있고, 토픽이 자동으로 닫힙니다. 버그 카테고리에서는 스태프가 수동으로 닫아야 합니다.
즉, 토픽을 생성하고, 답변에는 원인을 식별하는 단계를 포함합니다. 원인을 식별한 게시물을 해결책으로 선택하면, 해당 토픽에 #3rd-party 태그가 달리고 필요시 다른 카테고리로 이동됩니다. 그런 다음, 작성자가 이미 모르고 있다면 전용 플러그인/테마/구성 요소 토픽에 게시물을 작성하여 해당 플러그인/테마/구성 요소의 제작자에게 알릴 수 있습니다. 다만, 그런 경우에도 해당 토픽에 게시물을 남기는 것이 동일한 문제를 겪는 다른 사람들에게 도움이 될 수 있습니다.