답변이 원 게시글에 대해 ‘기술적으로’ 정확한 답변이라면, модератор(모더레이터)가 게시글을 해결로 표시하는 것이 괜찮다고 생각합니다.
특히 다음과 같은 경우라면 더 그렇습니다:
해결로 표시되면 올바른 답변을 찾는 것이 더 쉬워집니까? 검색이나 AI 봇이 해결로 표시된 주제에 더 높은 가중치를 부여합니까?
prioritize_solved_topics_in_search 설정에 따라 달라질 것 같습니다. 제 경우에는 검색 결과에서 해당 주제가 해결되었는지 확인할 수 있다는 것만으로도 이미 유용합니다. 해결된 주제만 검색하도록 필터를 걸 수도 있습니다.
제가 다음으로 묻고 싶었던 질문이었고, 알아두면 좋은 정보네요.
‘콘텐츠 가드닝(content gardening)’ 개념은 포럼에서 해결책을 더 쉽게 검색할 수 있도록 하는 데 초점을 맞추고 있는 것 같습니다.
해결된 주제가 검색 결과에서 더 우선시되어야 할까요? ‘이 주제에는 지정된 해결책이 있습니다’라고 명시하는 배너나 명확한 표시 방법을 제공하는 것도 좋을 것 같습니다.
더 큰 배너를 선호하지 않을 것 같습니다. 녹색 체크박스가 제공하는 정보보다 더 많은 정보를 추가하지 않으면서도 공간이 필요합니다.
이 토론을 가드닝 요청과 분리하는 것이 적절한가요?
일반적인 콘텐츠 가드닝 토론을 어지럽히지 않도록 이 토론을 계속 진행해 주시면 좋겠습니다.
모든 지원 관련 카테고리(이곳 메타에서)에 ‘해결로 표시’ 옵션이 사용되고 있나요?
추가 편집:
그러나 저는 그것이
이라는 것을 암시하려는 의도는 아니었습니다. 오히려 정반대였죠.
‘해결로 표시’ 옵션이 ‘콘텐츠 가드닝’ 과정에서 매우 유용할 것 같습니다.
여러 가지 가능한 해결책이 제안될 수 있는 여러 영역에서 이 기능이 사용되고 있습니다:
Creating form templates 에 form-templates 태그를 붙일 수 있을 것 같습니다
Mods가 해결된 답변을 표시하는 것에 대해:
좋은 목록입니다!
JammyDodger는 더 짧은 시간 범위를 사용했습니다:
2주에서 6개월 사이의 어디쯤을 기준으로 하는 경험칙을 정하는 것이 좋겠습니다 
네, 그냥 숫자를 하나 던져본 거예요
2주가 더 적합한 것 같아요
또한, OP가 답변을 달아 문제가 해결됐다고 하지만 해결책으로 표시하지 않았다면, 그건 확실한 증거예요
시도해 볼 잠재적인 우회 방법을 구현했습니다. 결과를 지켜보겠습니다.
<!-- 팀원이 아니라면 이 카테고리에서 주제를 생성하지 마세요. -->
<!-- TL3 사용자는 제목과 태그를 수정할 수 있도록 생성 권한을 가집니다 -->
이 방식이 TL3 사용자가 해당 문서 카테고리에서 제목과 태그를 수정할 수 있게 하면서, 누가 어떤 주제를 생성할 수 있는지 또는 생성해야 하는지에 대한 혼란을 크게 유발하지 않을 것이라 _생각_합니다.
결과를 지켜보겠습니다.
(git 저장소에서 동기화되어 관리되는 #documentation:developer-guides를 제외한 각 Documentation 하위 카테고리에서 이 작업을 수행했습니다)
요즘 이 문제에 대해 좀 더 생각해 보고 있습니다. 많은 경우 OP가 "감사합니다, 제 문제가 해결되었습니다"라고 말하지만 해결로 표시하지 않는 것을 목격했거든요. 어제 저는 직접 개입해서 해결책으로 표시했는데, 만약 이 작업을 몇 주 동안 기다려야 한다면 이 규칙이 적용될까요?
사람들이 "해결됨"이라고 적힌 큰 초록색 버튼을 어떻게 놓치는지 모르겠지만, 사이트를 깔끔하게 유지하기 위해 우리가 해야 할 일이라면, 최근에 작성된 답변이더라도 유효한 조치라고 생각합니다.
다음과 같은 조치를 취하는 것이 좋습니다:
대안으로, 최근 이 기능이 추가되었습니다: Notify OP and answerer if staff accepts an answer
이 기능을 켜는 것을 시도해 볼 수도/해야 할까요?
참고로, 여기서는 이미 오래전부터 이 기능이 활성화되어 있습니다:
제 생각에 그 옵션은 나쁘지 않은 것 같습니다. 지금까지 이 곳에서 실제로 사용되어 온 유일한 대안은 답변을 '해결됨’으로 표시하고 주제를 잠그는 것이었는데, 저는 후속 질문이나 문제가 생길 수 있으니 목적이 달성되었다는 이유로 주제를 바로 잠그는 것을 선호하지 않습니다. 완전한 답변을 남기는 것보다 잠금 메시지로 사용자에게 상황을 알려주는 것이 훨씬 낫다고 생각하지만, 가능하면 임의로 주제를 잠그는 것은 피해야 한다고 봅니다(특히 지원 관련 주제는 더욱이).
질문자(OP)에게 알려주는 것이 올바른 방법인 것 같지만, 관리진이나 스태프가 해결책으로 표시하고 주제가 자동으로 닫히도록 하는 것도 하나의 방법이 될 수 있습니다. 어딘가에서 해결책을 제안할 수 있는 기능 제안에 대해 본 기억이 나는데, 그건 당장 구현할 수 있는 수준은 아니죠.. 그 사이에 그 기능을 활성화하는 것이 더 나은 선택일 수 있습니다.
네, 이 부분도 이미 설정되어 있습니다:
꽤 관대하네요 (30일?).
따라서 다른 옵션을 켜는 경우, "해결로 표시"만으로도 충분하다고 생각합니다:
그리고 30일이 너무 길게 느껴진다면 줄일 수도 있습니다…
해당 토픽에 태그를 추가했습니다.
그 범주의 태그가 많이 누락된 이유가 그것일 수도 있습니다. GitHub에서도 태그가 추가되고 있나요?
네, 일단 #documentation:developer-guides는 조금 다른 성격의 항목이라고 보고, 나머지 항목부터 먼저 집중해 보겠습니다.
원문 작성자(OP)에게 보내지는 그 알림이 어떤 모습인지 궁금합니다. js.review.stale_help일까요..?
메시지에 "이것은 해결된 것으로 보이지만, 틀렸다면 알려주세요"라는 의미를 전달해야 한다고 생각합니다.
