Merci de partager ce contexte, James ! 
Pour résumer, il semble qu’à l’heure actuelle, nous ayons cinq façons d’indiquer qu’un sujet a atteint son terme et doit être clôturé. Est-ce que cela le résume bien ?
| quoi | où | qui |
|---|---|---|
 Discourse Solved |
Support #installation Development #data-reporting Support > SSO | propriétaire du sujet, @team, TL4 |
| fixed | Contribute > Bug Contribute > UX (fonctionne partout) | @team |
| completed | Contribute > Feature Contribute > UX | @team |
| delivered | Marketplace | tous les membres |
 fermer le sujet |
partout | @team et automatique |
Cela me semble être une grande variété. Je ne sais pas pourquoi les balises sont différentes. Peut-être que cela aide les utilisateurs à parcourir individuellement ces listes de balises. Cependant, ces balises et leur objectif ne sont pas très faciles à découvrir.
« solved » est facilement découvrable et fonctionne très bien pour le support. Je pense qu’il est logique de le limiter à cette catégorie. Il est utile de pouvoir filtrer les sujets résolus/non résolus dans cette catégorie — j’oublie souvent ce menu déroulant et j’aimerais qu’il soit plus visible dans l’interface. 
fixed n’est utilisé que dans Contribute > Bug et Contribute > UX et signifie qu’un bug ou un problème d’expérience utilisateur a été corrigé.
completed est utilisé dans Support, Contribute > Feature et Contribute > UX. Contribute > UX car les sujets liés à l’expérience utilisateur sont souvent aussi des demandes de fonctionnalités. Il y avait un sujet, "Reader Mode" theme component feedback, qui se trouvait dans Contribute > Site feedback, mais je l’ai maintenant déplacé vers Customization > Theme component où il semble appartenir maintenant que le composant a été publié.
delivered n’est utilisé que dans Marketplace.
Les sujets sont fermés pour diverses raisons :
- les sujets Support sont fermés un mois après le dernier message, une fois résolus
- les sujets Marketplace sont fermés un mois après le dernier message, qu’ils soient delivered ou non
- les modérateurs ferment les sujets
- lorsqu’ils sont résolus
- pour empêcher les réponses (par exemple, documentation ou release-notes)
- comme tactique de modération pour mettre fin aux discussions dans les sujets devenus improductifs ou ayant atteint leur terme
Quelques prochaines étapes potentielles :
- ajouter des descriptions aux balises fixed, completed et delivered expliquant comment nous les utilisons
- créer une requête Data Explorer avec des résultats similaires au tableau ci-dessus, mais listant le nombre réel et à jour de sujets résolus/non résolus, corrigés/non corrigés, terminés/non terminés, livrés/non livrés
- créer une requête Data Explorer listant les sujets qui ont été fermés, corrigés, terminés ou livrés dans un délai donné
- créer un sujet ici dans Contribute > Site feedback pour partager les résultats des requêtes ci-dessus chaque semaine via une automatisation
- créer un sujet ici avec un petit guide pratique pour clôturer les sujets et réunir une équipe pour le suivre, en commençant par traiter la liste dans l’ordre chronologique inverse