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 个赞
In the Bug category, we just work with the fixed tag instead. A post saying something is a duplicate isn’t really solving anything, despite being useful, so I don’t think it would have been a good use there either.
Now, why we use fixed in some categories, and the solved-plugin in others, I think that’s probably due to what Moin already said. Tags are a bit more strict in use, so only the team can decide when something is fixed.
4 个赞
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.
Maybe the answer is a yes, and? Automation that adds the fixed tag immediately if it’s closed and closes the topic (or schedules it for closure) if it has the fixed tag? We could do the same in UX with the fixed and completed tags.
Are there ever cases when we close Bug topics without wanting to add the fixed tag? I see there area lot of bug topics that are closed but don’t have the tag. I will spend a bit of time today exploring.
One thing I liked about how the solved plugin behaves is that when a solution is selected, the topic is scheduled to be automatically closed 30 days after the last reply. That is handy because it is abrupt and allows people to still follow up should they still feel the need to do so. It also likely saves us work because people won’t be flagging the topic to ask for it to be reopened.
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 个赞
I spent some time with this and see that @chapoi has the right idea. I think what we want to do here is get in the habit of tagging items fixed that have been fixed, and then create an automation that will set a timer to automatically close, like the solved plugin. We can still close the topic immediately if it is warranted but in some cases I think it’s good to keep it open for a bit longer to give people a chance to test and report back if they are still experiencing a problem.
There are topics like Rendering 'TypeError' with theme components after update which I think should not get the fixed tag, because the bug reported in the OP was not fixed. In this example there was no repro from the engineer who tried to fix it.
Threre is also After deleting a topic, the delete button shows up instead of the restore button which was closed as duplicate. I guess when Deleting a topic cannot be undone is fixed, both can be tagged fixed and closed? But how do we make sure that happens?
There are alot of topics in Bug that are closed but do not have the fixed tag. We will want to retroactively go through and look at these.
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)
3 个赞
I’m with you! I was also thinking about usability when I proposed “yes, and” above. Currently we have muscle memory around simply closing Bug topics when they are fixed. This also matches how we handle todos internally.
I like the idea of a one-click “fixed” button.
1 个赞
And the community delivered 
5 个赞
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.
1 个赞