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 Bug, solo trabajamos con la etiqueta fixed. Una publicación que diga que algo es un duplicado no resuelve nada, a pesar de ser útil, así que tampoco creo que hubiera sido un buen uso allí.
Ahora, por qué usamos fixed en algunas categorías y el plugin solved en otras, creo que se debe probablemente 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á solucionado.
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? ¿Automatización que añade la etiqueta fixed inmediatamente si se cierra y cierra el tema (o lo programa para su cierre) si tiene la etiqueta fixed? Podríamos hacer lo mismo en UX con las etiquetas fixed y completed.
¿Alguna vez hay casos en los que cerramos temas de Bug sin querer añadir la etiqueta fixed? Veo que hay muchos temas de errores que están cerrados pero no tienen la etiqueta. Dedicaré un poco de tiempo hoy a explorar.
Una cosa que me gustó del comportamiento del 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 es abrupto y permite a las personas seguir participando si aún sienten la necesidad de hacerlo. También es probable que nos ahorre 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
Pasé tiempo con esto y veo que @chapoi tiene la idea correcta. Creo que lo que queremos hacer aquí es acostumbrarnos a etiquetar los elementos como fixed que se han corregido, y luego crear una automatización que establezca un temporizador para cerrar automáticamente, como el plugin solved. Todavía podemos cerrar el tema inmediatamente si está justificado, pero en algunos casos creo que es bueno mantenerlo abierto un poco más para dar a las personas la oportunidad de probar e informar si todavía experimentan un problema.
Hay temas como Rendering 'TypeError' with theme components after update que creo que no deberían tener la etiqueta fixed, porque el error reportado en el OP no se corrigió. En este ejemplo, no hubo repro del ingeniero que intentó solucionarlo.
También está After deleting a topic, the delete button shows up instead of the restore button que se cerró como duplicado. Supongo que cuando Deleting a topic cannot be undone se corrija, ¿ambos se pueden etiquetar como fixed y cerrar? ¿Pero cómo nos aseguramos de que eso suceda?
Hay muchos temas en Bug que están cerrados pero no tienen la etiqueta fixed. Querremos revisar y mirar estos retroactivamente.
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
¡Estoy contigo! También estaba pensando en la usabilidad cuando propuse “sí, y” arriba. Actualmente tenemos memoria muscular en torno a simplemente cerrar temas de Bug cuando se solucionan. Esto también coincide con la forma en que manejamos los “to-do” internamente.
Me gusta la idea de un botón de “solucionado” 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