As demonstrated by the undermentioned example, it would have use there:
3 likes
Ik weet niet zeker of dat een goed idee is. Uiteindelijk kunnen wij als gebruikers geen bugs oplossen. Dat kan alleen door de Discourse-code te wijzigen, en daarvoor moet een teamlid betrokken zijn. Als dat niet nodig is, is Bug waarschijnlijk niet de juiste categorie.
Ik ben bang dat gebruikers workarounds als oplossing zullen markeren. Maar dan zou de bug nog steeds niet zijn opgelost. Het zou dus verwarrender dan nuttig zijn. In uw voorbeeld is het probleem ook niet opgelost, omdat er al een bugrapport is. Ik denk dat het samenvoegen van de onderwerpen in dit geval het beste is. Zo worden alle gebruikers op de hoogte gebracht wanneer er een oplossing is, ongeacht welk onderwerp ze oorspronkelijk volgden. Soms is het zinvol om het ene onderwerp te sluiten met een verwijzing naar het andere, maar dan gaan de likes die het gesloten onderwerp ondersteunden verloren, wat jammer is wanneer getroffen gebruikers worden bepaald door likes.
3 likes
In de Bug categorie werken we gewoon met de fixed tag. Een bericht waarin staat dat iets een duplicaat is, lost niets op, ondanks dat het nuttig is, dus ik denk niet dat het daar ook een goede toepassing zou zijn geweest.
Nu, waarom we fixed in sommige categorieën gebruiken en de solved-plugin in andere, denk ik dat dat waarschijnlijk te maken heeft met wat Moin al zei. Tags zijn wat strikter in gebruik, dus alleen het team kan beslissen wanneer iets is opgelost.
5 likes
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 like
@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 likes
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 likes
I proposed the reverse to @tobiaseigen : on adding the fixed tag, also auto-close; same as for solved.
Misschien is het antwoord een ja, en? Automatisering die de tag fixed onmiddellijk toevoegt als deze gesloten is en het onderwerp sluit (of sluiting plant) als het de tag fixed heeft? We zouden hetzelfde kunnen doen in UX met de tags fixed en completed.
Zijn er ooit gevallen waarin we #bug-onderwerpen sluiten zonder de tag fixed te willen toevoegen? Ik zie dat er veel bug-onderwerpen zijn die gesloten zijn, maar de tag niet hebben. Ik zal vandaag wat tijd besteden aan het verkennen.
EĂ©n ding dat ik goed vond aan hoe de solved-plugin werkt, is dat wanneer een oplossing is geselecteerd, het onderwerp 30 dagen na het laatste antwoord automatisch wordt gesloten. Dat is handig omdat het direct is en mensen nog steeds kunnen reageren als ze dat nog steeds nodig achten. Het bespaart ons waarschijnlijk ook werk omdat mensen het onderwerp niet zullen markeren om te vragen om het heropend te worden.
1 like
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 likes
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 likes
Mijn probleem hier is bruikbaarheid. Ik wil dat engineers hier een 1-klik oplossing hebben.
- Klik op âFixedâ in Topic Actions of Admin Topic actions.
- Magie gebeurt:
- Topic timer aangemaakt om te sluiten na 1 werkdag
- Topic getagd met âfixedâ
Ik ben geen fan van de UX voor alleen âtopic taggenâ omdat het erg veel frictie geeft.
- Navigeer naar de bovenkant van het topic
- Klik op de titel
- Klik op het tags-vak
- Zoek naar fixed
- voeg fixed toe
- klik op het selectievakje
Dit is veel frictie.
Graag voegen we deze flow toe, maar we hebben hiervoor een themacomponent nodig of een soort automatisering die deze UI introduceert (wat ook handig kan zijn).
4 likes
Ik ga met je mee! Ik dacht ook aan bruikbaarheid toen ik hierboven âja, enâ voorstelde. Momenteel hebben we spiergeheugen rond het simpelweg sluiten van #bug-onderwerpen wanneer ze zijn opgelost. Dit komt ook overeen met hoe we intern met todoâs omgaan.
Ik vind het idee van een âopgelostâ-knop met Ă©Ă©n klik goed.
1 like
And the community delivered 
6 likes
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 likes
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 like
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 likes
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 likes