Grazie per aver condiviso quel contesto, James! 
Quindi, per riassumere, sembra che al momento abbiamo cinque modi per indicare quando un argomento ha seguito il suo corso e deve essere chiuso. Questo lo riassume correttamente?
| cosa | dove | chi |
|---|---|---|
 Discourse Solved |
Support #installation Development #data-reporting Support > SSO | proprietario dell’argomento, @team, TL4 |
| fixed | Contribute > Bug Contribute > UX (funziona ovunque) | @team |
| completed | Contribute > Feature Contribute > UX | @team |
| delivered | Marketplace | tutti i membri |
 chiudi argomento |
ovunque | @team e automatico |
Questo mi sembra davvero una varietà enorme. Non so perché i tag siano diversi. Forse è utile/informativo che le persone possano scorrere individualmente quelle liste di tag. Tuttavia, questi tag e il loro scopo non sono così facilmente individuabili.
solved è facilmente individuabile e funziona molto bene per il supporto. Credo abbia senso limitarlo a quella categoria. È utile poter filtrare gli argomenti risolti/non risolti in quella categoria — anche se spesso dimentico quel menu a tendina e vorrei fosse più evidente nell’interfaccia utente. 
fixed è usato solo in Contribute > Bug e Contribute > UX e indica che un bug o un problema UX è stato risolto.
completed è usato anche in Support, Contribute > Feature e Contribute > UX. Contribute > UX perché gli argomenti UX sono spesso anche richieste di funzionalità. C’è stato un argomento, "Reader Mode" theme component feedback, che era in Contribute > Site feedback, ma l’ho spostato in Customization > Theme component dove sembra appartenere ora che il componente è stato rilasciato.
delivered è usato solo in Marketplace.
Gli argomenti vengono chiusi per una varietà di motivi diversi:
- gli argomenti Support vengono chiusi un mese dopo l’ultima risposta, una volta risolti
- gli argomenti Marketplace vengono chiusi un mese dopo l’ultima risposta, indipendentemente dal fatto che siano delivered o meno
- i moderatori chiudono gli argomenti
- quando sono risolti
- per impedire risposte (ad esempio documentazione o release-notes)
- come tattica di moderazione per porre fine a discussioni in argomenti che sono diventati improduttivi o hanno seguito il loro corso
Alcuni possibili prossimi passi:
- aggiungere descrizioni ai tag fixed, completed e delivered che spiegano come li utilizziamo
- creare una query di Data Explorer con risultati simili alla tabella sopra, ma elencando il numero reale e aggiornato di argomenti risolti/non risolti, corretti/non corretti, completati/non completati, consegnati/non consegnati
- creare una query di Data Explorer che elenchi gli argomenti che sono stati chiusi, corretti, completati o consegnati in un determinato arco temporale
- creare un argomento qui in Contribute > Site feedback per condividere i risultati delle query sopra ogni settimana utilizzando un’automazione
- creare un argomento qui con una piccola guida su come chiudere gli argomenti e riunire un team per seguirlo, iniziando a lavorare sulla lista in ordine cronologico inverso