¡Gracias por compartir ese contexto, James! ![]()
Para resumir, parece que actualmente tenemos cinco formas de indicar cuándo un tema ha llegado a su fin y necesita ser cerrado. ¿Captura esto todo?
| qué | dónde | quién |
|---|---|---|
| Support #installation Development #data-reporting Support > SSO | propietario del tema, @team, TL4 |
|
| fixed | Contribute > Bug Contribute > UX (funciona en todas partes) | @team |
| completed | Contribute > Feature Contribute > UX | @team |
| delivered | Marketplace | todos los miembros |
| en todas partes | @team y automático |
Esto me parece una variedad enorme. No sé por qué las etiquetas son diferentes. Quizás sea útil/informativo que la gente pueda desplazarse por esas listas de etiquetas individualmente. Sin embargo, estas etiquetas y su propósito no son muy fáciles de descubrir.
«solved» (resuelto) es fácil de descubrir y funciona bastante bien para soporte. Creo que tiene sentido limitarlo a esa categoría. Es útil poder filtrar temas resueltos/no resueltos en esa categoría; aunque a menudo olvido ese menú desplegable y desearía que fuera más visible en la interfaz de usuario. ![]()
fixed solo se usa en Contribute > Bug y Contribute > UX, e indica que se ha corregido un error o un problema de experiencia de usuario (UX).
completed se usa en Support, Contribute > Feature y Contribute > UX. En Contribute > 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 Contribute > Site feedback, pero ahora lo he movido a Customization > Theme component, donde parece pertenecer ahora que el componente ha sido lanzado.
delivered solo se usa en Marketplace.
Los temas se
cierran por diversas razones:
- 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, estén o no delivered.
- Los moderadores cierran temas:
- cuando están resueltos,
- 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 llegado a su fin.
Algunos siguientes pasos potenciales:
- añadir descripciones a las etiquetas fixed, completed y delivered que expliquen cómo las usamos,
- crear una consulta en Data Explorer con resultados como la tabla anterior, pero listando el número real y actualizado de temas resueltos/no resueltos, corregidos/no corregidos, completados/no completados, entregados/no entregados,
- crear una consulta en Data Explorer que liste los temas que han sido cerrados, corregidos, completados o entregados en un período determinado,
- crear un tema aquí en Contribute > Site feedback para compartir los resultados de las consultas anteriores cada semana mediante una automatización,
- crear un tema aquí con una pequeña guía sobre cómo cerrar temas y reunir a un equipo para seguirla y comenzar a trabajar en la lista, en orden cronológico inverso.