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 Contribute > Bug, nous utilisons simplement le tag fixed à la place. Un message indiquant qu’un sujet est un doublon ne résout vraiment rien, même si cela peut être utile, donc je ne pense pas que ce serait non plus un bon usage ici.
Maintenant, pourquoi nous utilisons fixed dans certaines catégories et solved-plugin dans d’autres, je pense que cela est probablement dû à ce que Moin a déjà dit. Les tags sont un peu plus stricts dans leur utilisation, donc seule l’équipe peut décider quand quelque chose est corrigé.
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 oui, et ? Une automatisation qui ajoute automatiquement le tag fixed si le sujet est fermé, et qui ferme le sujet (ou programme sa fermeture) s’il possède le tag fixed ? Nous pourrions faire de même dans Contribute > UX avec les tags fixed et completed.
Y a-t-il des cas où nous fermons des sujets Contribute > Bug sans vouloir ajouter le tag fixed ? Je vois qu’il y a beaucoup de sujets de bugs fermés qui n’ont pas ce tag. Je vais passer un peu de temps aujourd’hui à explorer cela.
Une chose que j’aimais dans le comportement du plugin “solved” est que lorsqu’une solution est sélectionnée, le sujet est programmé pour être fermé automatiquement 30 jours après le dernier message. C’est pratique car cela évite une fermeture brutale et permet aux gens de continuer à suivre le sujet s’ils ressentent toujours le besoin de le faire. Cela nous fait également 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é un peu de temps à examiner cela et je constate que @chapoi a la bonne idée. Je pense que ce que nous voulons faire ici, c’est prendre l’habitude de baliser les éléments avec fixed lorsqu’ils sont résolus, puis de créer une automatisation qui définira un minuteur pour les fermer automatiquement, à l’instar du plugin « solved ». Nous pouvons toujours fermer le sujet immédiatement si nécessaire, mais dans certains cas, je pense qu’il est bon de le laisser ouvert un peu plus longtemps pour donner aux gens la possibilité de tester et de faire un retour s’ils rencontrent toujours un problème.
Il existe des sujets comme Rendering 'TypeError' with theme components after update que je pense ne pas devoir recevoir le tag fixed, car le bug signalé dans le message d’origine n’a pas été corrigé. Dans cet exemple, l’ingénieur qui a tenté de le corriger n’a pas pu reproduire le problème.
Il y a aussi After deleting a topic, the delete button shows up instead of the restore button qui a été fermé en tant que doublon. Je suppose que lorsque Deleting a topic cannot be undone sera corrigé, les deux pourront être balisés fixed et fermés ? Mais comment nous assurer que cela se produise ?
Il y a beaucoup de sujets dans Contribute > Bug qui sont fermés mais qui n’ont pas le tag fixed. Nous devrons les examiner rétrospectivement.
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 de ton avis ! J’avais aussi en tête la question de l’utilisabilité lorsque j’ai proposé « oui, et » plus haut. Actuellement, on a pris l’habitude de clôturer simplement les sujets Contribute > Bug une fois qu’ils sont résolus. Cela correspond également à la façon dont nous gérons les tâches internes.
J’aime bien l’idée d’un bouton « Résolu » 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 »