Como dije antes, también echo de menos que los temas se “empujen” hacia arriba cuando hay una edición significativa.
Uso el sondeo RSS (#rss-polling) para ser notificado sobre el mantenimiento de mi foro mediante la fuente RSS de https://status.discourse.org/. El tema se crea cuando comienza el mantenimiento y se “empujaba” hacia arriba con la edición que anunciaba que había terminado. Ahora falta este “empuje”, y no quiero que los temas sean wikis, ya que ningún usuario debe editarlos, ni quiero que sean documentos. Por lo tanto, las soluciones alternativas actuales no ayudan.
En un foro, tenemos un tema de galería que muestra los proyectos de los usuarios además de los temas individuales en los que los usuarios presentan sus proyectos. Este tema es muy útil para reunir inspiración. Añadimos una imagen del tema de presentación y un enlace a él en este tema de galería. Demasiadas imágenes en una publicación han provocado problemas de rendimiento y también dificultan la edición. Por lo tanto, creamos una nueva publicación por cada 10 proyectos. El “empuje” al editar cuando se añadía el segundo o noveno proyecto era útil. Es útil para que los usuarios noten la actualización, y fue especialmente útil para aquellos que añaden proyectos manualmente al tema. Gracias a la fecha de actividad, podía ver inmediatamente si alguien más ya había añadido el proyecto. Ahora, cada uno de nosotros necesita abrir el tema para comprobarlo.
También hay otros temas que funcionan de manera similar: temas que sirven como una visión general retrospectiva de los cambios/actividad dentro de un mes y donde la última publicación sobre el mes actual se actualiza varias veces. Esto funcionaba muy bien porque los cambios en la última publicación “empujaban” el tema hacia arriba. Publicar cada cambio individualmente restaría claridad a las entradas agrupadas mensualmente y aún significaría que las actualizaciones de las entradas existentes se pierden fácilmente. Un nuevo tema cada mes para unas pocas entradas parece demasiado, y también significaría que los usuarios tendrían que configurar sus notificaciones cada mes, o necesitaríamos una subcategoría completa que les permita configurar su estado de notificación predeterminado.
También me gustaba que los cambios de categoría y etiqueta en los temas sin respuesta los “empujaran” hacia arriba. La mayoría de las veces utilizo una lista (filtrada) de los temas más recientes. Y si un tema tenía un título mal elegido o estaba en la categoría equivocada, podría no hacer clic en él. Si alguien mejora esta información, podría darme cuenta de que puedo ayudar después de todo. Por eso era útil cuando un cambio de este tipo hacía que el tema volviera a subir por encima de mi línea de lectura.
Además, fue útil conocer las categorías y las etiquetas. A menudo me he enterado de nuevas etiquetas porque se añadieron en un tema nuevo o sobre la diferencia detallada entre categorías basándome en temas que fueron movidos por un moderador. A veces incluso preguntaba por qué, porque creo que la capacidad de mover temas a otras categorías también conlleva la responsabilidad de conocer la diferencia entre ellas.
También me gusta el enfoque de que la configuración de Discourse te obliga a añadir información en lugar de escribir otra publicación.
Para citar el mensaje emergente:
Sin embargo, esto solo tiene sentido si los demás notan que has editado tu publicación para añadir más información. Un ejemplo que he encontrado varias veces en Meta son las actualizaciones de una publicación después de que se haya fusionado una solicitud de extracción (pull request). Añadir esa información a la publicación no notifica a quienes ya la leyeron, y aquellos que no lo han hecho pueden notarlo fácilmente por la insignia en el onebox.
Para mí, no tiene sentido que la configuración que bloquea más de tres respuestas consecutivas de un usuario siga activa y sugiera ediciones como solución, cuando estas ediciones lamentablemente ya no tienen el efecto que solían tener.