Gracias por compartir ese contexto, James. 
Entonces, para resumir, parece que actualmente tenemos cinco formas de indicar cuándo un tema ha seguido su curso y necesita ser concluido. ¿Esto lo resume?
| qué | dónde | quién |
|---|---|---|
 Discourse Solved |
Support Installation Dev Data & reporting SSO | propietario del tema, @team, TL4 |
| fixed | Bug UX (funciona en todas partes) | @team |
| completed | Feature UX | @team |
| delivered | Marketplace | todos los miembros |
 cerrar tema |
en todas partes | @team y automático |
Esto me parece una gran variedad. No sé por qué las etiquetas son diferentes. Quizás sea útil/informativo para la gente poder desplazarse por esas listas de etiquetas individualmente. Sin embargo, estas etiquetas y su propósito no son muy fáciles de descubrir.
solved es fácil de descubrir y funciona bastante bien para el soporte. Creo que tiene sentido limitarlo a esa categoría. Es útil poder filtrar temas resueltos/no resueltos en esa categoría; a menudo olvido ese menú desplegable y desearía que fuera más fácil de descubrir en la interfaz de usuario. 
fixed solo se usa en Bug UX y significa que se corrigió un error o un error de UX.
completed se usa también en Support Feature UX. UX porque los temas de UX a menudo también son solicitudes de funciones. Hubo un tema, "Reader Mode" theme component feedback, que estaba en Site feedback pero ahora lo he movido a Theme component, donde parece pertenecer ahora que el componente ha sido lanzado.
delivered solo se usa en Marketplace.
Los temas se cierran por una variedad de razones diferentes:
- Los temas de Support se cierran un mes después de la última respuesta, una vez resueltos.
- Los temas de Marketplace se cierran un mes después de la última respuesta, independientemente de si están delivered o no.
- Los moderadores cierran temas
- cuando se resuelven
- para evitar respuestas (por ejemplo, documentación o release-notes)
- como táctica de moderación para finalizar discusiones en temas que se han vuelto improductivos o han seguido su curso.
Algunos posibles próximos pasos:
- agregar descripciones a las etiquetas fixed completed delivered que expliquen cómo las usamos.
- crear una consulta de explorador de datos con resultados como la tabla anterior, pero que liste el número real y actualizado de temas resueltos/no resueltos, corregidos/no corregidos, completados/no completados, entregados/no entregados.
- crear una consulta de explorador de datos que liste los temas que se han cerrado, corregido, completado, entregado en un período de tiempo determinado.
- crear un tema aquí en Site feedback para compartir los resultados de las consultas anteriores cada semana utilizando una automatización.
- crear un tema aquí con una pequeña guía sobre cómo concluir temas y reunir a un equipo para seguirla y comenzar a trabajar en la lista, en orden cronológico inverso.