Marcación inconsistente de Temas como ☑️ Resuelto, Completado o Arreglado aquí en meta.discourse.org

Hola, maravilloso personal de Discourse que dirige y mantiene con amor este increíble foro en línea con su propio producto.

Observo que tenemos activo el Plugin Solved para Support. ¡Genial ver este increíble dogfooding en práctica! Lo mismo ocurre con el uso de las etiquetas fixed y completed.

Desafortunadamente, hay una gran cantidad de Temas en Support, Bug, Feature y UX que no han sido marcados con estas. Esto es bastante confuso para los usuarios de este foro y dificulta la búsqueda efectiva de soluciones existentes. Básicamente, si no se van a utilizar de manera consistente, probablemente no deberían usarse en absoluto.

¿Puedo solicitar que esto se priorice en el futuro y que alguien (?becario, ??IA) se encargue de marcar correctamente los antiguos?

8 Me gusta

¡Gracias, Nathan! Te agradezco que hayas planteado esto. :sunflower: Definitivamente queremos hacer más en este departamento.

Parece que habilitar soluciones para la categoría Support ha funcionado bastante bien para esa categoría. Las etiquetas fixed y completed también son bastante útiles, y se pueden usar en todas las categorías.

3 Me gusta

No veo la etiqueta completed en Marketplace.

Creo que estas son solo para el personal.

¿Quizás sería útil ampliar esto a trust_level_3? Esto también podría ayudar con Marketplace según el punto de Jay anterior.

2 Me gusta

Para Marketplace, existe #entregado, que no está restringido al equipo.

4 Me gusta

Gracias por compartir ese contexto, James. :hugs:

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
:check_box_with_check: 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
:locked: 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.

:check_box_with_check: 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. :blush:

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 :locked: 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.
3 Me gusta

Añadí descripciones como las siguientes, para que aparezcan al pasar el ratón por encima de la etiqueta o al ir a la página de la etiqueta. Házmelo saber si tienes sugerencias. Dudo entre mantenerlo corto y conciso, y proporcionar un contexto más detallado. Las propias categorías también tienen descripciones más detalladas.

fixed

Priorizamos la corrección de errores en nuestro software reportados en las categorías Bug y UX. Una vez corregidos los errores, se les da esta etiqueta.

completed

Cuando se implementan las funciones sugeridas en las categorías Feature y UX, se les da esta etiqueta.

delivered

Cuando un tema en Marketplace es confirmado como entregado por el proveedor o el destinatario, se le da esta etiqueta.

3 Me gusta

Vaya. Eso sonó complicado. :slight_smile:

Ostensiblemente, pones la etiqueta fixed en los errores que se han corregido y completed en las solicitudes de funciones que se han implementado. [1] Es parte del proceso para cerrar los temas (y mantener a las partes interesadas actualizadas con la información relevante). Inicialmente se implementaron para proporcionar alguna indicación visual de que “ha sucedido algo bueno” en comparación con el símbolo de bloqueo de un tema cerrado. Cuando estas etiquetas se aplican de manera consistente, obtienes una agradable ola de verde al desplazarte por las listas de temas de su categoría.

(Y delivered era una etiqueta separada pero similar que no estaba controlada por el equipo, por lo que podría usarse en Marketplace)

Para Solved, hay bastantes categorías donde está activo en lugar de solo la categoría genérica Support. Prácticamente cualquier categoría donde la mayoría de los temas serán preguntas que puedan tener una solución. Support, Installation, Dev, Data & reporting, SSO

Idealmente, la mejor práctica es que el OP marque la solución, pero sabemos que esto a veces no sucede (por una variedad de razones), por lo que a menudo revisaba las listas de temas y limpiaba algunas pendientes después de un par de semanas o así (una vez que se consideraban ‘abandonadas’).

Para que lo sepas, el tema Theme component para eso es Reader Mode, así que en realidad ese tema feedback que enlazaste no debería estar en Theme component (ya que no es un tema de componente temático). Probablemente debería estar en Feature o UX, ya que creo que es donde han llegado a vivir ahora que existen más de ellos.

(Creo que estaba en Site feedback ya que fue un experimento aquí en meta)


  1. y con UX siendo un punto intermedio entre los dos, se puede usar cualquiera dependiendo del ‘sabor’ del tema específico ↩︎

6 Me gusta

¡Genial! Gracias por completar algunas lagunas. Actualicé mi tabla anterior.

Eso no se ha hecho sistemáticamente desde que te fuiste, por eso ahora tenemos este tema para hablar de ponernos al día y tener un sistema implementado para no volver a quedarnos atrás.

¡Buena observación! Lo moví a Feature.

1 me gusta

Sí, supongo que a eso me refería con el OP. @JammyDodger, ¡te echamos de menos a ti y a tu dedicación para que Meta funcionara tan bien! Personalmente, espero que te hagan una oferta que no puedas rechazar…

4 Me gusta