Comme le montre l’exemple ci-dessous, cela serait utile ici :
3 « J'aime »
Je ne suis pas sûr que ce soit une bonne idée. En fin de compte, nous, en tant qu’utilisateurs, ne pouvons pas corriger les bugs. Cela ne peut être fait qu’en modifiant le code de Discourse, et cela nécessite l’implication d’un membre de l’équipe. Si ce n’est pas nécessaire, alors Bug n’est probablement pas la bonne catégorie.
Je crains que les utilisateurs ne marquent les solutions de contournement comme solution. Mais alors le bug ne serait toujours pas corrigé. Ce serait donc plus déroutant qu’utile. Dans votre exemple, le problème n’est pas non plus résolu, car il existe déjà un rapport de bug. Je pense que fusionner les sujets est le mieux dans ce cas. De cette façon, tous les utilisateurs seront informés lorsqu’il y aura une correction, quel que soit le sujet qu’ils ont initialement suivi. Parfois, il est logique de fermer un sujet en référence à l’autre, mais alors les likes qui ont soutenu le sujet fermé sont perdus, ce qui est dommage lorsque les utilisateurs concernés sont déterminés par les likes.
3 « J'aime »
Dans la catégorie Bug, nous travaillons uniquement avec la balise fixed. Une publication indiquant que quelque chose est un doublon ne résout rien, même si elle est utile, donc je ne pense pas qu’elle aurait été une bonne utilisation là non plus.
Maintenant, pourquoi nous utilisons fixed dans certaines catégories et le plugin solved dans d’autres, je pense que c’est probablement dû à ce que Moin a déjà dit. Les balises sont un peu plus strictes dans leur utilisation, donc seule l’équipe peut décider quand quelque chose est résolu.
5 « J'aime »
Merci pour la suggestion ! C’est toujours bien de vérifier la façon dont les catégories sont configurées, alors j’apprécie que vous y ayez réfléchi et que vous ayez lancé ce sujet.
Comme Moin et Charlie l’ont souligné, notre équipe s’appuie sur fixed et la clôture des sujets (actions qui ne sont disponibles que pour nous) pour communiquer avec la communauté qu’un bug a été, eh bien, corrigé ! Cela semble fonctionner assez bien et c’est un moyen pour nous de garder une liste de bogues assez évidente à corriger.
Il est vrai que dans la catégorie des bogues, une personne capable de fournir une solution n’obtient pas le même crédit que dans les catégories où le plugin de résolution est activé, ce qui est dommage. Dans la catégorie des bogues, la personne qui signale le bogue obtient un badge si elle est appréciée par un membre de l’équipe Discourse. Mais d’autres qui aident en cours de route en fournissant des étapes de reproduction, en signalant des doublons, en suggérant des solutions, etc., n’obtiendront pas de crédit. Quelque chose à considérer.
Dans ce cas, il aurait été agréable que vous puissiez créditer Moin pour avoir signalé que le rapport est un doublon, mais conserver le sujet crée également du bruit supplémentaire qui rendra l’analyse de tous les rapports de bogues ouverts un peu plus difficile pour l’équipe. J’espère donc que cela ne vous dérange pas, mais j’ai réglé une minuterie pour le supprimer.
1 « J'aime »
@tobiaseigen, n’est-ce pas à cela que sert la fonction de verrouillage ? La supprimer fera que certaines URI externes qui y pointent renverront une erreur 404, ce qui n’est pas idéal.
Nous ne gardons pas tout ! 
Je ne m’inquiéterais pas trop du 404.
Cependant, nous ne le faisons pas du tout de manière cohérente car cela représente un travail supplémentaire. Je pense qu’il y a un intérêt à marquer automatiquement avec « fixed » lorsque nous fermons, puis pour les cas exceptionnels où nous ne corrigeons pas, nous pouvons modifier avec une balise spéciale.
Cela nécessitera cependant une nouvelle automatisation.
4 « J'aime »
J’ai rencontré plusieurs fois des liens qui semblaient intéressants, mais qui menaient à une erreur 404 lors du clic, ce qui était assez désagréable.
Dans ce cas, je signalerais le message, qui serait modifié/supprimé par un modérateur.
Pour éviter cela, avant de supprimer un sujet, jetez un œil à la section des liens du premier message :
Et ensuite, en prenant des mesures préventives en supprimant ces références de liens serait le mieux, mais cela demanderait aussi plus de travail.
2 « J'aime »
J’ai proposé l’inverse à @tobiaseigen : lors de l’ajout de l’étiquette fixed, fermer automatiquement ; de même que pour solved.
Peut-être que la réponse est un oui, et ? Une automatisation qui ajoute le tag fixed immédiatement s’il est fermé et ferme le sujet (ou le planifie pour fermeture) s’il a le tag fixed ? Nous pourrions faire de même dans UX avec les tags fixed et completed.
Y a-t-il des cas où nous fermons des sujets Bug sans vouloir ajouter le tag fixed ? Je vois qu’il y a beaucoup de sujets de bugs qui sont fermés mais n’ont pas le tag. Je vais passer un peu de temps aujourd’hui à explorer.
Une chose que j’ai aimée dans le comportement du plugin solved est que lorsqu’une solution est sélectionnée, le sujet est programmé pour être automatiquement fermé 30 jours après la dernière réponse. C’est pratique car c’est abrupt et permet aux gens de donner suite s’ils en ressentent encore le besoin. Cela nous fait probablement gagner du travail car les gens ne signaleront pas le sujet pour demander sa réouverture.
1 « J'aime »
La raison pour laquelle je n’aime pas la fermeture automatique => ajout automatique du tag est due aux cas d’utilisation où ce n’était pas corrigé ou que cela ne sera jamais corrigé. Je pense que faire une seule action (« ajouter le tag ») qui déclenche automatiquement la fermeture du sujet après 30 jours est la meilleure solution.
2 « J'aime »
J’ai passé du temps sur ce sujet et je vois que @chapoi a la bonne idée. Je pense que ce que nous voulons faire ici, c’est prendre l’habitude de taguer les éléments fixed qui ont été corrigés, puis créer une automatisation qui définira un minuteur pour les fermer automatiquement, comme le plugin solved. Nous pouvons toujours fermer le sujet immédiatement si cela est justifié, mais dans certains cas, je pense qu’il est bon de le laisser ouvert un peu plus longtemps pour donner aux gens une chance de tester et de signaler s’ils rencontrent toujours un problème.
Il y a des sujets comme Rendering 'TypeError' with theme components after update qui, je pense, ne devraient pas recevoir le tag fixed, car le bug signalé dans le message d’origine n’a pas été corrigé. Dans cet exemple, il n’y a pas eu de reproduction de la part de l’ingénieur qui a essayé de le corriger.
Il y a aussi After deleting a topic, the delete button shows up instead of the restore button qui a été fermé comme doublon. Je suppose que lorsque Deleting a topic cannot be undone sera corrigé, les deux pourront être tagués fixed et fermés ? Mais comment s’assurer que cela se produise ?
Il y a beaucoup de sujets dans Bug qui sont fermés mais n’ont pas le tag fixed. Nous voudrons examiner ces sujets rétroactivement.
3 « J'aime »
Mon problème concerne l’utilisabilité. Je veux que les ingénieurs aient une solution en 1 clic ici.
- Cliquer sur « Corrigé » dans Actions du sujet ou Actions du sujet d’administration.
- La magie opère :
- Un minuteur de sujet est créé pour se fermer dans 1 jour ouvrable
- Le sujet est tagué avec « corrigé »
Je ne suis pas fan de l’expérience utilisateur pour simplement « taguer un sujet » car cela demande beaucoup d’efforts.
- Naviguer vers le haut du sujet
- Cliquer sur le titre
- Cliquer sur la boîte de tags
- Rechercher « corrigé »
- Ajouter « corrigé »
- Cliquer sur la case à cocher
Cela demande beaucoup d’efforts.
Je suis heureux que nous ajoutions ce flux, mais nous aurons besoin d’un composant de thème pour cela ou d’une sorte d’automatisation qui introduit cette interface utilisateur (ce qui peut également être utile).
4 « J'aime »
Je suis avec vous ! Je pensais aussi à l’utilisabilité lorsque j’ai proposé « oui, et » ci-dessus. Actuellement, nous avons une mémoire musculaire autour de la simple fermeture des sujets Bug lorsqu’ils sont corrigés. Cela correspond également à la façon dont nous gérons les todos en interne.
J’aime l’idée d’un bouton « corrigé » en un clic.
1 « J'aime »
Et la communauté a répondu 
6 « J'aime »
Génial ! J’ai essayé le composant de thème de Nate sur mon site personnel, et il fait ce qu’il promet. Très beau travail et implémenté rapidement aussi ! 
Pour pouvoir l’utiliser ici, nous devrions pouvoir le limiter à une catégorie. Si nous décidons que cette approche fonctionne bien, nous voudrions également pouvoir créer plus d’un bouton.
Pour information, Sam travaille également sur une implémentation expérimentale différente et beaucoup plus flexible, utilisant l’automatisation.
2 « J'aime »
Je pense que ce changement nous aiderait beaucoup ici sur meta. J’ai fait un suivi en interne pour voir s’il peut être implémenté soit en utilisant l’implémentation expérimentale de Sam avec l’automatisation, soit en forquant le composant de thème de Nate et en l’utilisant ici.
Le composant de Nate fait essentiellement la même chose et est assez agréable, mais nous devrions le forker car nous n’installons pas de composants ou de plugins tiers sur meta. 
1 « J'aime »
Si vous faites cela, la chose honorable à faire serait d’offrir à Nate un gage financier de remerciement - comme vous le faites pour les risques de cybersécurité identifiés via HackerOne.
2 « J'aime »
Gardons ce sujet centré sur les avantages que la communauté pourrait tirer de l’utilisation d’un composant thématique comme celui de Nate. Si c’est le cas, nous réglerons les détails avec Nate.
Je serais ravi de créer un autre sujet sur la manière dont les contributeurs open source sont récompensés pour leur travail en général, si vous le souhaitez.
2 « J'aime »