As demonstrated by the undermentioned example, it would have use there:
3개의 좋아요
I’m not sure if that’s a good idea. Ultimately, we as users can’t fix bugs. That can only be done by changing the Discourse code, and that requires a team member to be involved. If that’s not necessary, then Bug is probably not the right category.
I’m concerned that users will mark workarounds as the solution. But then the bug still wouldn’t be fixed. So it would be more confusing than helpful. In your example, the problem isn’t solved either, because there’s already a bug report. I think merging the topics is best in this case. That way, all users will be notified when there’s a fix, regardless of which topic they originally followed. Sometimes it makes sense to close one topic with a reference to the other, but then the likes that supported the closed topic are lost which is sad when affected users are determined by likes and replies.
3개의 좋아요
Contribute > Bug 카테고리에서는 대신 fixed 태그를 사용합니다. 중복이라는 게시글은 유용한 정보이긴 하지만, 실제로 문제를 해결하는 것은 아니므로, 그 카테고리에서도 좋은 선택은 아니었을 것입니다.
일부 카테고리에서는 fixed 태그를 사용하고, 다른 카테고리에서는 solved 플러그인을 사용하는 이유는 아마도 Moin이 이미 말한 것과 관련이 있을 것입니다. 태그는 사용이 좀 더 엄격하므로, 어떤 것이 수정되었는지 결정할 권한은 팀에게만 있습니다.
5개의 좋아요
Thanks for the suggestion! It’s always good to sanity check the way categories are set up so I appreciate you thinking about it and starting this topic.
As Moin and Charlie have pointed out, our team rely on fixed and closing topics (actions only available to us) to communicate with the community that a bug has been, well, fixed! This seems to be working pretty well and is a way for us to keep a fairly obvious backlog of bugs that need fixing.
It’s true that in the bug category a person who is able to provide a solution doesn’t get credit for it in the same way that they would in categories with the solved plugin enabled, which is a pity. In the bug category, the person reporting the bug does get a badge for it if it is liked by a member of the Discourse team. But others helping along the way by providing repro steps, pointing out dupes, suggesting solutions and so on will not get credit. Something to think about.
In this case it would have been nice for you to have been able to credit Moin with pointing out that the report is a dupe, but keeping the topic also creates some extra noise that will make parsing all the open bug reports a bit tricker for the team. So hope you don’t mind but I set a timer to delete it.
1개의 좋아요
@tobiaseigen, isn’t that what the lock feature is for? Deleting it shall make some external URIs that point to it 404, which isn’t ideal.
We don’t keep everything! 
I wouldn’t worry about the 404 too much.
We don’t practice this consistently at all though cause it is extra work. I think there is merit in auto tagging with fixed as we close, then for outlier cases where we do not fix we can edit with a special tag.
Will require some new automation though.
4개의 좋아요
I’ve been experiencing multiple times looking for some info, seeing a link that seemed interesting, but led to a 404 when clicked, which was quite displeasing.
In this case, I would flag the post, which would be edited/removed by a moderator.
To prevent this, before deleting a topic, having a look at the first post links section:
And then preventively taking action by removing those link references would be the best, but it would also require more work.
2개의 좋아요
I proposed the reverse to @tobiaseigen : on adding the fixed tag, also auto-close; same as for solved.
아마도 답은 '예, 그리고?'일 수 있습니다. fixed 태그가 붙어 있고 닫힌 상태라면 자동으로 fixed 태그를 추가하고, fixed 태그가 있는 경우 주제를 닫거나(또는 폐쇄를 예약하는) 자동화 기능은 어떨까요? Contribute > UX 채널에서도 #fixed와 completed 태그를 사용하여 동일한 방식을 적용할 수 있습니다.
fixed 태그를 추가하지 않고 Contribute > Bug 주제를 닫아야 하는 경우가 있을까요? 태그 없이 닫힌 버그 주제들이 많이 있는 것을 볼 수 있습니다. 오늘 좀 시간을 들여 이 부분을 조사해 보겠습니다.
해결책(solved) 플러그인의 동작 방식 중 좋았던 점은 해결책이 선택되면 마지막 답변 후 30일 후 자동으로 주제가 폐쇄되도록 예약된다는 것입니다. 이는 갑작스럽지만, 필요하다고 느끼는 사람들이 여전히 후속 조치를 취할 수 있게 해주므로 편리합니다. 또한 사람들이 주제를 다시 열라고 플래깅하는 일이 줄어들어 우리의 업무를 절약해 줄 가능성이 높습니다.
1개의 좋아요
The reason why I don’t like the closed => add tag automatically is because of the usecases where it wasn’t fixed or it’s a wont-ever-fix. I feel doing 1 action (“add tag”) which then automatically sets the topic timer to close after 30 days is the optimum way.
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개의 좋아요
My issue is usability here. I want engineers to have a 1 click solution here.
- Click “Fixed” in Topic Actions or Admin Topic actions.
- Magic happens:
- Topic timer created to close in 1 business day
- Topic tagged with “fixed”
I am not a fan of the UX for just “tagging topic” cause it is very high friction
- Navigate to top of topic
- Click title
- Click tags box
- search for fixed
- add fixed
- click checkbox
This is a lot of friction.
Happy for us to add this flow, but we will need a theme component for it or some sort of automation that introduces this UI (which can also be handy)
4개의 좋아요
나도 동의해! 위에서 "예, 그리고"를 제안할 때도 사용성을 고려하고 있었어. 현재는 Contribute > Bug 토픽이 수정되면 단순히 닫는 것에 대한 습관이 형성되어 있어. 이건 내부적으로 할 일을 처리하는 방식과도 일치해.
“수정됨” 버튼을 한 번에 클릭할 수 있다는 아이디어는 좋아.
1개의 좋아요
And the community delivered 
6개의 좋아요
Cool! I tried Nate’s theme component on my personal site, and it does what is on the tin. Very nice job and implemented quickly too! 
To be able to use it here, we’d have to be able to limit it to a category. If we decide this approach works well, we’d also want to be able to create more than one button.
FYI, Sam is also working on an experimental implementation that is different and much more flexible, using automation.
2개의 좋아요
I think this change would help us quite a bit here on meta. I have followed up internally to see if it can be implemented either using Sam’s experimental implementation using automation or by forking Nate’s theme component and using that here.
Nate’s component effectively does the same thing and is quite nice, but we’d have to fork it because we don’t install third party components or plugins on meta. 
1개의 좋아요
If you do that, the honourable thing to do would be to offer Nate a financial token of thanks - as you do for identified cybersecurity risks via HackerOne.
2개의 좋아요
Let’s keep this topic focused on whether the community would benefit from using something like Nate’s theme component. If so, we’ll sort out the mechanics with Nate.
Happy to spin out another topic about how open source contributors are rewarded for their work more generally if you’d like.
2개의 좋아요