Gracias por interactuar conmigo en esto, @Stephen.
Creo que esto es muy específico de la comunidad
Estoy de acuerdo. Por eso propongo que se controle mediante una casilla de verificación en la configuración (ya sea reutilizando una de las existentes relacionadas con no permitir títulos duplicados o añadiendo una nueva).
¿Qué valor tiene tener un número menor de temas mucho más largos?
Como contexto, en nuestro sitio de Discourse, tenemos una categoría “Notificaciones”, cuyas subcategorías reciben correos enviados por scripts cuando ocurren ciertos eventos (por ejemplo, fallos en pruebas, nuevos informes de problemas, nuevas preguntas publicadas en Stack Overflow, nuevas menciones de nuestro proyecto en sitios de discusión, etc.). Estas categorías están diseñadas para permitir a los miembros de la comunidad rastrear y discutir tipos específicos de eventos que puedan interesarles.
En algunos casos, los correos generados por nuestros scripts tienen líneas de asunto predecibles y deterministas por diseño, como “linux64 testing”. Por ejemplo, si tenemos un nuevo fallo en nuestras pruebas de linux64 el 15 de agosto, eso genera un correo. Si aparecen más fallos el 16 de agosto, se genera un segundo correo con la misma línea de asunto. Luego, si todos los fallos se resuelven el 17 de agosto, se genera un tercer correo con la misma línea de asunto indicando la resolución. Después, si tenemos nuevos fallos el 31 de agosto, generamos un cuarto correo con la misma línea de asunto, y un quinto cuando se resuelve el fallo.
Con el comportamiento actual del sitio, cada uno de estos correos genera un tema completamente nuevo llamado “linux64 testing” sin ningún vínculo o relación entre ellos, lo que dificulta que las personas correlacionen los eventos o decidan de cuál de los cinco temas deben usar para continuar la discusión sobre los fallos. En cambio, lo que deseamos es que los cinco correos (y cualquier discusión de usuario que se produzca en ellos) aparezcan como publicaciones dentro de un solo tema, de modo que un desarrollador pueda ver todos los fallos de pruebas en una configuración determinada dentro de un único tema, organizados cronológicamente.
Otro impacto del comportamiento actual de Discourse es que alguien que recibe notificaciones por correo electrónico para la categoría o tema en cuestión ve cinco hilos sin relación en su bandeja de entrada llamados “linux64 testing”. En cambio, si Discourse fusionara estos en un solo tema, esa persona vería todas las publicaciones de “linux64 testing” asociadas como un único hilo en su lector de correo, lo que facilitaría mucho la navegación y sería mucho más parecido a cualquier conversación tradicional.
Ejecutamos varias decenas de configuraciones de pruebas cada noche, cada una de las cuales tiene una línea de asunto única cuando ocurren fallos, por lo que la situación actual resulta en un desorden extenso y difícil de navegar, con un tema distinto y superficial por correo, todos intercalados cronológicamente. En cambio, nuestro ideal sería que la categoría “Notifications.Tests” mostrara un único tema por configuración que almacene todas las publicaciones generadas por humanos o scripts sobre esa configuración de forma cronológica, según lo determine esa línea de asunto única.
[Esta categoría de pruebas no es actualmente visible públicamente en nuestro sitio @Stephen, pero si te gustaría ver cómo se ve y sentir el problema de primera mano, estaré encantado de concederte temporalmente acceso de lectura… solo avísame.]
Para comunidades como meta, esto significaría que cualquier usuario que envíe un correo con ‘problemas al configurar mailgun’ seguirá recibiendo notificaciones de actualizaciones meses o años después de resolver su problema.
Estoy de acuerdo en que esta opción puede no ser tan sensata para una comunidad tan grande y duradera como meta, que no tiene necesidad de agrupar publicaciones generadas por correo en un solo tema como nosotros. Por lo tanto, probablemente no querrías activar una función así si existiera. (Y quizás con el tiempo, un sitio como el nuestro tampoco la querría por las mismas razones; en ese caso, creo que lo ideal sería poder aplicar la casilla de verificación por categoría, pero no quise pedir demasiado cuando creo que una única configuración a nivel de sitio sería suficiente para nosotros por ahora).
Dicho esto, incluso si un sitio como el nuestro activara una función así, y el autor original del tema ‘problemas al configurar mailgun’ se molestara por publicaciones posteriores que compartieran la misma línea de asunto, presumiblemente podría darse de baja del tema para evitar seguir recibiendo actualizaciones si alguien más usa la misma línea de asunto (o simplemente añade otra publicación al tema dado a través de la interfaz web).
[Dicho esto, espero que la mayoría de los usuarios humanos publiquen a través del sitio web, así que imagino que esta función tendría un mayor impacto en las publicaciones generadas por scripts que en las generadas por humanos]