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?
¡Gracias, Nathan! Te agradezco que hayas planteado esto. 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.
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?
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 BugUX y significa que se corrigió un error o un error de UX.
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 fixedcompleteddelivered 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.
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.
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)
y con UX siendo un punto intermedio entre los dos, se puede usar cualquiera dependiendo del ‘sabor’ del tema específico ↩︎
¡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.
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…
Vuelvo a este Tema ya que recientemente fui reprendido por marcar un Tema en Feature que creía que debería haber sido marcado como completed, pero no lo fue.
Lo que me gustaría haber hecho era simplemente etiquetarlo yo mismo. Sin embargo, como esa etiqueta está restringida a @staff, no pude. Oye, como TL4 puedo hacer un montón de cosas potencialmente destructivas, pero no eso. Ni siquiera puedo editar etiquetas en algunas Categorías (es decir, Plugin).
Entonces, ¿cómo se supone que uno debe señalar estas pequeñas cosas a los moderadores sin molestarlos y ser reprendido? ¿O el plan es dejarlo un poco desordenado?
Creo que está bien marcar el tema como otra cosa y decir que crees que debería marcarse como completado/resuelto, al menos para los temas “antiguos” (es decir: se completó/resolvió hace 6 meses pero el tema no se ha actualizado).
(Aunque otros no estén de acuerdo con eso)
Para cosas urgentes: sería una buena práctica que nuestro personal se asegure de dar seguimiento a las cosas que soluciona.
Creo que si ponemos etiquetas para marcar cada característica completada de los últimos 13 años que este foro ha estado activo porque la gente tiene TOC, sería una gran pérdida de tiempo para todos.
La etiqueta en sí es relativamente nueva, nunca fue ampliamente adoptada, y podríamos simplemente cerrar temas para las características completadas, permitiendo a todos crear nuevos temas y citar los antiguos según sea necesario.
Preferiría eliminar la etiqueta #completed (completado). Se aplicó 400 veces y solo se creó como una forma de ayudar a las personas a escribir registros de cambios, los cuales se manejan de manera diferente hoy en día.
No estoy seguro de reconocer esto como la razón. Inicialmente se implementó para proporcionar un indicador visual que separara las solicitudes de funciones completadas del resto de los temas cerrados. Hay una conversación en algún lugar por aquí entre yo, Sam y Dave con más información si buscas. (Creo que fue en algunos susurros, pero no recuerdo exactamente dónde)
Personalmente, no me resultó particularmente oneroso mantenerlo al día en ese momento. Me concentré más en la ventana ‘activa’ para asegurar que los temas en la parte superior de /latest fueran más consistentes, aunque también hice otros si se cruzaban en mi camino (temas relacionados, y demás). Realizar una auditoría completa de la categoría Feature sería un trabajo mucho mayor. (no es que no sería útil revisarlo y podar/fusionar/cerrar cualquiera de los que se hayan omitido a lo largo de los años, solo digo que consumiría mucho tiempo y tendrías que sopesar dónde se encuentra en la lista de prioridades).
¿Es este un miedo a lo que pueda ser, o esto está sucediendo realmente? Si fuera algo ocasional, no estoy seguro de que sea un gran problema, pero si se convirtiera en un patrón, estoy de acuerdo en que el sistema de indicadores no sería el mejor lugar para ello. Creo que un MP sería una forma menos intrusiva de recopilar la información.
Pero también entiendo que realmente no quieres que los desarrolladores y diseñadores, etc., se vean demasiado involucrados en esto, ya que tendrán otro trabajo importante que hacer en lugar de ordenar metadatos.
Quizás las cosas que requieren un moderador, pero no son urgentes, podrían reportarse mediante mensajes privados a una bandeja de entrada de grupo separada. Luego, dichos registros de limpieza no inundarían la cola de revisión, ocultando temas en los que alguien necesita actuar pronto, pero aún habría un lugar para recopilarlos, para que alguien pueda ocuparse de ellos si tiene unos minutos.
Esto podría funcionar para todo tipo de notas secundarias, como una etiqueta faltante, un enlace de vista previa roto en un tema de componente de tema o un tema de característica que podría cerrarse, para que los votos se devuelvan a los usuarios.
¡Oh! ¡Me estoy dando cuenta de que el grupo de moderadores no tiene a nadie! Ahora entiendo por qué un MP que escribí a @moderators hace un par de semanas nunca recibió respuesta…
Lo creé como parte de mi idea de tener un enfoque más suave y gentil para la moderación aquí. Es importante tener un único punto de contacto al que puedas dirigirte a un moderador y saber que vas a recibir una respuesta. Espero que se reconsidere la decisión de eliminar eso.
También, como parte de intentar ser más amable y gentil, hice todo lo posible para evitar usar “pérdida de tiempo” como razón para las decisiones de moderación. No creo que los líderes de la comunidad bienintencionados que intentan ayudar a mantener las discusiones ordenadas deban sentirse mal por eso.
Volviendo al OP… Tenía una tarea rutinaria para revisar y limpiar temas antiguos, y era una buena tarea manual porque a menudo había cabos sueltos que podía atar sobre la marcha. A veces los temas simplemente podían eliminarse o fusionarse, etc. Pero es una tarea gigantesca y solo llegué a revisar unos pocos años atrás.
Estaría a favor de permitir que veteranos de confianza como @nathank añadan las etiquetas en lugar de hacer que marquen los temas para su revisión por parte del personal, especialmente ahora que no hay un gerente de comunidad ni un equipo de moderación dedicado.
Edición: ¡Todavía tengo los enlaces en mi barra lateral! Esto era para ver temas que están abiertos, sin resolver y tienen más de una semana. Todavía me parecen útiles estos enlaces para ver qué tan bien estamos resolviendo los temas. Quizás más de nosotros podríamos ayudar con esto si el personal no tiene tiempo para hacerlo.
Estamos en un pequeño período de transición en lo que respecta a las moderaciones, por lo que algunas de las decisiones que tomemos en este preciso momento pueden no ser duraderas, pero aquí están mis 2 céntimos sobre este tema en particular:
Creo que deberíamos aspirar a llegar a un punto en el que:
Las banderas (flags) se utilicen para cosas más importantes
Tengamos una forma de gestionar otras cosas que son más triviales, o para jardinería general
Si queremos usar #completed (completado), entonces deberíamos dar poder a un grupo de personas para que lo gestionen sin usar banderas. Quizás:
Otorgar a los TL3 y TL4 el poder de etiquetar cosas como tales
Crear un tema de “jardinería” donde la gente pueda hacer sugerencias para cualquier tipo de jardinería de contenido
Agradezco mucho eso. Dado que solo se puede reportar una publicación una vez y nunca más, siempre me he mostrado reacio a usar banderas para problemas triviales, como un enlace de vista previa en un tema de componente de tema que ya no funciona.
Sugerí la bandeja de entrada porque pensé que archivar las solicitudes gestionadas podría ayudar a llevar un registro de lo que ya se ha resuelto. Esto podría ser más difícil en un tema con muchas respuestas.
No estoy seguro de cuán útil es agregar la etiqueta completed o fixed pero no poder cerrar el tema. Si alguien más todavía es necesario para cerrar el tema, esto no ayuda mucho.
Estábamos considerando automatizaciones para cerrar temas con esas etiquetas; no estoy seguro de lo difícil que sería llevar esos experimentos a buen término.
Leo cada publicación todos los días. De verdad. Mi última publicación sin ver fue en junio de 2024. Como tal, he visto innumerables informes de errores/experiencia de usuario (UX) corregidos o completados. Generalmente, simplemente los marcaría para cerrarlos. Menos veo la necesidad de las etiquetas fixed o completed, sino solo un cierre del tema. En mi opinión, eso solo significa que el tema ha sido resuelto.
Definitivamente queremos hacer más en este departamento.
cerrar tema
Me concentré más en la ventana ‘activa’ para asegurar que los temas en la parte superior de /latest fueran más consistentes, aunque también hice otros si se cruzaban en mi camino (temas relacionados, y demás). Realizar una auditoría completa de la categoría 
(no es que no sería útil revisarlo y podar/fusionar/cerrar cualquiera de los que se hayan omitido a lo largo de los años, solo digo que consumiría mucho tiempo y tendrías que sopesar dónde se encuentra en la lista de prioridades).
