아래에 제시된 예에서 보듯, 해당 부분에서 유용하게 사용할 수 있습니다:
3개의 좋아요
그것이 좋은 아이디어인지 확신하지 못하겠습니다. 결국, 우리는 사용자로서 버그를 수정할 수 없습니다. 버그 수정은 Discourse 코드를 변경해야만 가능하며, 이를 위해서는 팀원의 개입이 필요합니다. 만약 그것이 필요하지 않다면, ‘버그’ 카테고리는 아마도 적절하지 않을 것입니다.
사용자들이 우회책을 해결책으로 표시할까 봐 우려됩니다. 하지만 그렇게 되면 버그는 여전히 수정되지 않습니다. 따라서 도움이 되기보다 더 혼란을 야기할 수 있습니다. 예시에서와 같이, 이미 버그 리포트가 존재하므로 문제도 해결되지 않습니다. 이 경우 주제를 병합하는 것이 가장 좋다고 생각합니다. 그러면 어떤 주제를 처음에 추적했든, 수정이 이루어졌을 때 모든 사용자에게 알림이 전송됩니다. 때로는 다른 주제에 대한 참조를 포함하여 한 주제를 닫는 것이 의미 있을 수 있지만, 그렇게 하면 폐쇄된 주제를 지지했던 좋아요가 사라지게 되며, 이는 영향받은 사용자가 좋아요와 답변 수로 결정되는 상황에서 아쉬운 부분입니다.
3개의 좋아요
Contribute > Bug 카테고리에서는 대신 fixed 태그를 사용합니다. 중복이라는 게시글은 유용한 정보이긴 하지만, 실제로 문제를 해결하는 것은 아니므로, 그 카테고리에서도 좋은 선택은 아니었을 것입니다.
일부 카테고리에서는 fixed 태그를 사용하고, 다른 카테고리에서는 solved 플러그인을 사용하는 이유는 아마도 Moin이 이미 말한 것과 관련이 있을 것입니다. 태그는 사용이 좀 더 엄격하므로, 어떤 것이 수정되었는지 결정할 권한은 팀에게만 있습니다.
5개의 좋아요
제안해 주셔서 감사합니다! 카테고리 구성 방식을 sanity check(일관성 검증)하는 것은 항상 좋은 일이므로, 이 부분을 고민해 주시고 이 주제를 시작해 주신 데 감사드립니다.
Moin과 Charlie가 지적했듯이, 저희 팀은 fixed 태그와 토픽 닫기(저희에게만 제공되는 작업)를 사용하여 버그가 수정되었음을 커뮤니티에 알리고 있습니다! 이 방식이 꽤 잘 작동하고 있으며, 수정이 필요한 버그 목록을 비교적 명확하게 유지하는 데 도움이 됩니다.
버그 카테고리에서는 해결책을 제공할 수 있는 사람이 solved 플러그인이 활성화된 카테고리에서와 같은 방식으로 공로를 인정받지 못한다는 점은 사실입니다. 이는 다소 아쉬운 부분입니다. 버그 카테고리에서는 버그를 보고한 사람이 Discourse 팀 구성원에게 '좋아요’를 받으면 배지를 받을 수 있습니다. 그러나 재현 단계를 제공하거나, 중복임을 지적하거나, 해결책을 제안하는 등 중간에 도움을 준 다른 사용자들은 공로를 인정받지 못합니다. 고민해 볼 만한 부분입니다.
이 경우 Moin이 보고서가 중복임을 지적한 데 대해 공로를 인정할 수 있었으면 좋았을 텐데, 토픽을 유지하면 팀이 모든 열린 버그 보고서를 분석하는 일이 조금 더 어려워지는 추가적인 노이즈가 발생합니다. 따라서 양해 부탁드리며, 삭제 타이머를 설정해 두었습니다.
1개의 좋아요
@tobiaseigen, 잠금 기능이 바로 그런 용도가 아닌가요? 삭제하면 해당 토픽을 가리키는 외부 URI가 404 오류를 일으키게 되는데, 이는 이상적이지 않습니다.
모든 것을 보관하지는 않아요! 
404 에러는 너무 걱정하지 마세요.
하지만 이는 추가적인 작업이 필요하기 때문에 일관되게 적용하지는 않습니다. 이슈를 닫을 때 자동으로 fixed 태그를 붙이는 것이 유용하다고 생각하며, 수정하지 않는 예외적인 경우에는 특수 태그로 수정할 수 있습니다.
다만 이를 위해 새로운 자동화가 필요합니다.
4개의 좋아요
저도 여러 번 정보를 찾다가 흥미로운 링크를 보았지만, 클릭했을 때 404 오류가 나와 매우 불쾌한 경험을 했습니다.
이런 경우, 게시물을 신고하면 관리자가 수정하거나 삭제할 것입니다.
이를 방지하기 위해, 주제를 삭제하기 전에 첫 번째 게시물의 링크 섹션을 확인해 보세요:
그리고 예방 차원에서 해당 링크 참조를 미리 제거하는 것이 최상이지만, 더 많은 노력이 필요할 것입니다.
2개의 좋아요
저는 @tobiaseigen에게 그 반대 방식을 제안했습니다. fixed 태그를 추가할 때 자동으로 닫는 것입니다. solved(해결됨) 태그와 동일한 방식이죠.
아마도 답은 '예, 그리고?'일 수 있습니다. fixed 태그가 붙어 있고 닫힌 상태라면 자동으로 fixed 태그를 추가하고, fixed 태그가 있는 경우 주제를 닫거나(또는 폐쇄를 예약하는) 자동화 기능은 어떨까요? Contribute > UX 채널에서도 #fixed와 completed 태그를 사용하여 동일한 방식을 적용할 수 있습니다.
fixed 태그를 추가하지 않고 Contribute > Bug 주제를 닫아야 하는 경우가 있을까요? 태그 없이 닫힌 버그 주제들이 많이 있는 것을 볼 수 있습니다. 오늘 좀 시간을 들여 이 부분을 조사해 보겠습니다.
해결책(solved) 플러그인의 동작 방식 중 좋았던 점은 해결책이 선택되면 마지막 답변 후 30일 후 자동으로 주제가 폐쇄되도록 예약된다는 것입니다. 이는 갑작스럽지만, 필요하다고 느끼는 사람들이 여전히 후속 조치를 취할 수 있게 해주므로 편리합니다. 또한 사람들이 주제를 다시 열라고 플래깅하는 일이 줄어들어 우리의 업무를 절약해 줄 가능성이 높습니다.
1개의 좋아요
폐쇄 시 태그를 자동으로 추가하는 방식을 선호하지 않는 이유는, 실제로 수정되지 않았거나 영원히 수정되지 않을(wont-ever-fix) 경우와 같은 사용 사례가 있기 때문입니다. 한 가지 동작(„태그 추가“)을 수행하면 토픽이 30일 후 자동으로 폐쇄되도록 타이머가 설정되는 방식이 최적이라고 생각합니다.
2개의 좋아요
이 문제에 대해 시간을 들여 살펴보니 @chapoi 님의 아이디어가 적중이라고 생각합니다. 여기서 우리가 해야 할 일은 수정된 항목에 fixed 태그를 붙이는 것을 습관화한 후, solved 플러그인처럼 자동으로 닫히도록 타이머를 설정하는 자동화를 만드는 것입니다. 필요한 경우 즉시 주제를 닫을 수도 있지만, 일부 경우에는 사람들이 문제를 여전히 겪고 있는지 테스트하고 보고할 수 있도록 조금 더 열어두는 것이 좋다고 생각합니다.
Rendering 'TypeError' with theme components after update 와 같은 주제는 OP에서 보고된 버그가 수정되지 않았으므로 fixed 태그를 붙여서는 안 된다고 생각합니다. 이 예시에서는 수정을 시도한 엔지니어가 재현할 수 없었습니다.
또한 After deleting a topic, the delete button shows up instead of the restore button 은 중복으로 닫힌 주제입니다. Deleting a topic cannot be undone 이 수정되면, 둘 다에 fixed 태그를 붙이고 닫을 수 있을까요? 하지만 이것이 일어나도록 어떻게 확인할 수 있을까요?
Contribute > Bug 에는 닫혀 있지만 fixed 태그가 없는 많은 주제들이 있습니다. 우리는 나중에 이 주제들을 되돌아가서 검토해 보아야 할 것입니다.
3개의 좋아요
여기서 제가 주목하는 부분은 사용성입니다. 엔지니어들이 1클릭으로 해결할 수 있는 방법을 원합니다.
- 토픽 액션 또는 관리자 토픽 액션에서 "Fixed"를 클릭합니다.
- 마법이 일어납니다:
- 1영업일 후 토픽을 닫기 위한 타이머가 생성됩니다.
- 토픽에 “fixed” 태그가 붙습니다.
단순히 “토픽에 태그를 붙이는” UX는 마찰이 매우 크므로 선호하지 않습니다.
- 토픽 상단으로 이동
- 제목 클릭
- 태그 상자 클릭
- fixed 검색
- fixed 추가
- 체크박스 클릭
이것은 상당한 마찰입니다.
이 플로우를 추가하는 데 동의하지만, 이를 위해 테마 컴포넌트나 이 UI를 도입하는某种의 자동화가 필요합니다(이것은 다른 용도로도 유용할 수 있습니다).
4개의 좋아요
나도 동의해! 위에서 "예, 그리고"를 제안할 때도 사용성을 고려하고 있었어. 현재는 Contribute > Bug 토픽이 수정되면 단순히 닫는 것에 대한 습관이 형성되어 있어. 이건 내부적으로 할 일을 처리하는 방식과도 일치해.
“수정됨” 버튼을 한 번에 클릭할 수 있다는 아이디어는 좋아.
1개의 좋아요
커뮤니티가 바로 만들어 주었습니다 
6개의 좋아요
멋지네요! 내 개인 사이트에서 네이트의 테마 컴포넌트를 시험해 봤는데, 광고된 대로 정확히 동작하네요. 정말 잘 만들었고, 구현 속도도 빠르네요! 
여기서 사용하려면 카테고리로 범위를 제한할 수 있어야 합니다. 이 방식이 효과적이라는 결론이 나면, 버튼도 하나 이상 만들 수 있어야 합니다.
참고로, 샘은 자동화를 활용한 실험적 구현을 진행 중인데, 이 방식은 기존과 다르고 훨씬 더 유연합니다.
2개의 좋아요
이 변경 사항이 메타에서 꽤 큰 도움이 될 것 같다고 생각합니다. Sam의 자동화 기반 실험적 구현을 사용하거나, Nate의 테마 컴포넌트를 포크하여 여기서 사용하는 방식으로 구현이 가능한지 확인하기 위해 내부적으로 후속 조치를 취했습니다.
Nate의 컴포넌트는 사실상 동일한 기능을 수행하며 꽤 훌륭하지만, 메타에서는 서드파티 컴포넌트나 플러그인을 설치하지 않으므로 포킹이 필요합니다. 
1개의 좋아요
그렇게 한다면, HackerOne을 통해 식별된 사이버 보안 위험에 대해 보상하는 것처럼 네이트에게 감사의 뜻을 담은 금전적 보상을 제안하는 것이 도덕적인 일일 것입니다.
2개의 좋아요
이 주제는 네이트의 테마 컴포넌트와 같은 도구를 사용하는 것이 커뮤니티에 도움이 될지에 대한 내용으로만 집중합시다. 도움이 된다면, 구체적인 메커니즘은 네이트와 함께 정리하겠습니다.
원하시면 오픈소스 기여자들이 그들의 작업에 대해 어떻게 보상받아야 하는지에 대한 일반적인 내용을 다룬 별도의 주제를 개설할 수도 있습니다.
2개의 좋아요