Como se demuestra en el ejemplo que se menciona a continuación, sería útil allí:
3 Me gusta
No estoy seguro de si es una buena idea. Al final, nosotros, como usuarios, no podemos solucionar errores. Eso solo se puede hacer cambiando el código de Discourse, y eso requiere la participación de un miembro del equipo. Si eso no es necesario, entonces “Bug” probablemente no sea la categoría correcta.
Me preocupa que los usuarios marquen las soluciones temporales como la solución. Pero entonces el error seguiría sin solucionarse. Sería más confuso que útil. En tu ejemplo, el problema tampoco se resuelve, porque ya existe un informe de error. Creo que fusionar los temas es lo mejor en este caso. De esa manera, todos los usuarios serán notificados cuando haya una solución, independientemente del tema que siguieron originalmente. A veces tiene sentido cerrar un tema con una referencia al otro, pero entonces se pierden los “me gusta” que apoyaron al tema cerrado, lo cual es triste cuando los usuarios afectados se determinan por los “me gusta”.
3 Me gusta
En la categoría Contribute > Bug, simplemente trabajamos con la etiqueta fixed en su lugar. Un post que dice que algo es un duplicado no resuelve realmente nada, a pesar de ser útil, así que no creo que tampoco hubiera sido un buen uso ahí.
Ahora, por qué usamos fixed en algunas categorías y solved-plugin en otras, creo que eso probablemente se deba a lo que Moin ya dijo. Las etiquetas son un poco más estrictas en su uso, por lo que solo el equipo puede decidir cuándo algo está resuelto.
5 Me gusta
¡Gracias por la sugerencia! Siempre es bueno verificar la forma en que se configuran las categorías, así que aprecio que lo hayas pensado y hayas iniciado este tema.
Como Moin y Charlie han señalado, nuestro equipo confía en fixed y en cerrar temas (acciones solo disponibles para nosotros) para comunicarnos con la comunidad que un error ha sido, bueno, ¡corregido! Esto parece estar funcionando bastante bien y es una forma para que mantengamos un registro bastante obvio de los errores que necesitan ser corregidos.
Es cierto que en la categoría de errores, una persona que puede proporcionar una solución no recibe crédito por ello de la misma manera que lo haría en categorías con el plugin de resuelto habilitado, lo cual es una lástima. En la categoría de errores, la persona que informa el error recibe una insignia si es del agrado de un miembro del equipo de Discourse. Pero otros que ayudan en el camino al proporcionar pasos de reproducción, señalar duplicados, sugerir soluciones, etc., no recibirán crédito. Algo en lo que pensar.
En este caso, habría sido bueno que pudieras darle crédito a Moin por señalar que el informe es un duplicado, pero mantener el tema también crea algo de ruido adicional que hará que el análisis de todos los informes de errores abiertos sea un poco más complicado para el equipo. Así que espero que no te importe, pero puse un temporizador para eliminarlo.
1 me gusta
@tobiaseigen, ¿no es para eso la función de bloqueo? Eliminarlo hará que algunas URI externas que apuntan a él devuelvan 404, lo cual no es ideal.
¡No lo guardamos todo! 
No te preocupes demasiado por el 404.
Sin embargo, no practicamos esto de manera consistente porque es trabajo adicional. Creo que tiene mérito etiquetar automáticamente como fijo cuando cerramos, y luego, para casos atípicos en los que no lo arreglamos, podemos editar con una etiqueta especial.
Sin embargo, requerirá algo de automatización nueva.
4 Me gusta
He experimentado varias veces que busco información, veo un enlace que parece interesante, pero al hacer clic me lleva a un 404, lo cual fue bastante desagradable.
En este caso, marcaría la publicación, que sería editada/eliminada por un moderador.
Para evitar esto, antes de eliminar un tema, echa un vistazo a la sección de enlaces de la primera publicación:
Y luego, tomando medidas preventivas para eliminar esas referencias de enlaces sería lo mejor, pero también requeriría más trabajo.
2 Me gusta
Propuse lo contrario a @tobiaseigen: al agregar la etiqueta fixed, también cerrar automáticamente; lo mismo que para solved.
Quizás la respuesta sea un sí, y. ¿Una automatización que añada la etiqueta fixed de inmediato si se cierra y cierre el tema (o lo programe para su cierre) si tiene la etiqueta fixed? Podríamos hacer lo mismo en Contribute > UX con las etiquetas fixed y completed.
¿Existen casos en los que cerramos temas de Contribute > Bug sin querer añadir la etiqueta fixed? Veo que hay muchos temas de errores cerrados que no tienen la etiqueta. Hoy dedicaré un poco de tiempo a explorarlo.
Una cosa que me gustó de cómo se comporta el plugin “solved” es que, cuando se selecciona una solución, el tema se programa para cerrarse automáticamente 30 días después de la última respuesta. Eso es útil porque no es abrupto y permite que la gente aún pueda seguir participando si aún siente la necesidad de hacerlo. También probablemente nos ahorra trabajo, porque la gente no marcará el tema para pedir que se reabra.
1 me gusta
La razón por la que no me gusta que el estado cerrado => añadir etiqueta automáticamente es por los casos de uso en los que no se arregló o es algo que nunca se arreglará. Creo que realizar 1 acción (“añadir etiqueta”) que luego establece automáticamente el temporizador del tema para que se cierre después de 30 días es la forma óptima.
2 Me gusta
He dedicado un tiempo a esto y veo que @chapoi tiene la idea correcta. Creo que lo que queremos hacer aquí es acostumbrarnos a etiquetar como fixed los elementos que han sido solucionados y luego crear una automatización que establezca un temporizador para cerrarlos automáticamente, como hace el plugin solved. Todavía podemos cerrar el tema de inmediato si es necesario, pero en algunos casos creo que es bueno mantenerlo abierto un poco más para dar a las personas la oportunidad de probar y reportar si aún experimentan el problema.
Hay temas como Rendering 'TypeError' with theme components after update que, en mi opinión, no deberían recibir la etiqueta fixed, porque el error reportado en el OP no fue solucionado. En este ejemplo, no hubo una reproducción del error por parte del ingeniero que intentó solucionarlo.
También está After deleting a topic, the delete button shows up instead of the restore button, que fue cerrado como duplicado. Supongo que cuando se solucione Deleting a topic cannot be undone, ambos podrán etiquetarse como fixed y cerrarse. ¿Pero cómo nos aseguramos de que eso ocurra?
Hay muchos temas en Contribute > Bug que están cerrados pero no tienen la etiqueta fixed. Queremos revisar estos de manera retroactiva y analizarlos.
3 Me gusta
Mi problema es la usabilidad aquí. Quiero que los ingenieros tengan una solución de un clic aquí.
- Haz clic en “Fixed” (Corregido) en Topic Actions (Acciones del tema) o Admin Topic actions (Acciones del tema de administración).
- Sucede la magia:
- Se crea un temporizador de tema para que se cierre en 1 día hábil
- El tema se etiqueta como “fixed” (corregido)
No soy un fan de la experiencia de usuario solo para “etiquetar un tema” porque tiene mucha fricción.
- Navega a la parte superior del tema
- Haz clic en el título
- Haz clic en el cuadro de etiquetas
- Busca “fixed” (corregido)
- Añade “fixed” (corregido)
- Haz clic en la casilla de verificación
Esto es mucha fricción.
Estaría contento de que añadiéramos este flujo, pero necesitaremos un componente de tema para ello o algún tipo de automatización que introduzca esta interfaz de usuario (que también puede ser útil).
4 Me gusta
¡Yo también estoy de acuerdo! También estaba pensando en la usabilidad cuando propuse «sí, y» más arriba. Actualmente, tenemos el hábito de cerrar simplemente los temas Contribute > Bug cuando se resuelven. Esto también coincide con la forma en que manejamos las tareas pendientes internamente.
Me gusta la idea de un botón «Resuelto» con un solo clic.
1 me gusta
Y la comunidad entregó 
6 Me gusta
¡Genial! Probé el componente temático de Nate en mi sitio personal y hace lo que promete. ¡Muy buen trabajo y además implementado rápidamente! 
Para poder usarlo aquí, tendríamos que poder limitarlo a una categoría. Si decidimos que este enfoque funciona bien, también querríamos poder crear más de un botón.
Para tu información, Sam también está trabajando en una implementación experimental que es diferente y mucho más flexible, utilizando automatización.
2 Me gusta
Creo que este cambio nos ayudaría bastante aquí en meta. He hecho un seguimiento interno para ver si se puede implementar utilizando la implementación experimental de Sam con automatización o bifurcando el componente temático de Nate y usándolo aquí.
El componente de Nate hace efectivamente lo mismo y es bastante bueno, pero tendríamos que bifurcarlo porque no instalamos componentes o complementos de terceros en meta. 
1 me gusta
Si haces eso, lo honorable sería ofrecerle a Nate un token financiero de agradecimiento, como lo haces por los riesgos de ciberseguridad identificados a través de HackerOne.
2 Me gusta
Mantengamos este tema centrado en si la comunidad se beneficiaría de usar algo como el componente temático de Nate. Si es así, resolveremos la mecánica con Nate.
Estaré encantado de abrir otro tema sobre cómo se recompensa a los contribuyentes de código abierto por su trabajo en general si lo deseas.
2 Me gusta