I really like the intention behind slow mode, but it doesn’t quite address the most common driver for flamewars on our discourse:
Someone comes in “hot” — often someone new, often someone from another community — and lists a bunch of grievances
Lots of existing members respond to talk to/at the original poster with varying motivations (but with the “I think someone is wrong on the internet” syndrome ranking high)
The original poster wants to respond to/at everyone
Even in the best of discussions, things snowball rapidly.
Slow mode doesn’t help here, because there’s a many-to-one problem. It often just further alienates the new member as they’re the one that feels the brunt of the limitation: many can respond to them while their cool down timer is burning and then they only get one post to respond.
One tool I wish I had in my toolbox for situations like these is to slow down the bumping of the topic. The default listings (both latest and top) prioritize these “hot” topics. I’d love to be able to limit the bumps to once-every-12-hours or some such. Then it’s not a complete de-listing, but it’s a significant de-emphasizing that could help limit the number of new entrants to the discussion (unless they actively seek it out, which is just fine).
Absolutely, but such monster posts that reply to many messages make the topic even harder to manage. Splits become impossible, and they tend to put the poster even more on a war-path (or at the very least, give the appearance of aggravation just by virtue of the large wall of text).
That’s actually another unintended consequence of slow mode that we’ve seen on Julia discourse, which is a paid hosted instance that’s quite active: slow mode gets turned on and some people start editing their posts instead of writing new ones. Similar problem with setting someone who’s being problematic to TL0: they can’t make new posts but they can still edit their old ones, so they’ll do that, which is especially bad if they’re written inflammatory stuff which people reply to and they then edit, making the response look out of line.
But yes, I definitely second @mbauman’s suggestion—being able to prevent a hot topic from getting bumped so often would be very helpful for cooling things down.
In addition to preventing the hot topic from getting bumped, it might be an idea to delay the notifications. That kind of solves the issue where someone replies to or mentions multiple users.
Realmente no entiendo lo que propones. ¿Puedes mostrarme una maqueta de interfaz de usuario de cómo funcionaría esto, qué vería el usuario, qué vería el miembro del personal?
Por eso la edición está limitada por defecto en el Modo Lento. Puedes desactivar los límites de edición si confías en que tu comunidad no hará esto.
Y considera lo que dijo @sam. Haz que el tema no aparezca en la lista. Por favor, utiliza todas las herramientas existentes en tu caja de herramientas antes de proponer más.
La idea principal es bastante simple: la llamaría algo así como “Limitar re-publicaciones de temas…” en el menú de temas del administrador (probablemente ubicada junto al elemento “ Restablecer fecha de re-publicación”). Aparecería un cuadro de diálogo que te pediría que ingresaras el período de tiempo. El texto sería algo como: “Limitar la frecuencia con la que este tema aparece en la parte superior de las vistas de Últimos y otras categorías a no más de una vez cada X horas”, con un valor predeterminado de aproximadamente 8 horas.
Realmente no tengo una opinión firme sobre cómo se implementaría; podría ser con estado (hacer un seguimiento de la última publicación que actualizó la fecha de re-publicación del tema, y solo actualizarla si la hora de una nueva publicación es más de X horas en el futuro) o podría ser sin estado (establecer siempre la fecha de actualización del tema al múltiplo de X horas redondeado hacia abajo a partir de la época Unix o la primera publicación). O algo más, lo que sea.
En cuanto a lo que se muestra al usuario, no estoy 100% convencido de que necesite comunicarse, pero podría aparecer como un elemento de publicación “no listado”, simplemente indicando: “este tema solo aparecerá en la parte superior de las listas de temas una vez cada X horas”.
En cuanto a otras herramientas, a veces usamos la no listación de hilos, pero esto se trata de nuevos usuarios combativos — a menudo el tipo de persona que puede ofenderse mucho ante cualquier indicio de censura. Y realmente no quiero censurar/ocultar/eliminar cosas. El objetivo es una intervención más suave que, con suerte, sea menos probable que cause más agravamiento en sí misma, pero que ayude a mantener la temperatura un poco más baja.
Esto está algo inspirado en la forma en que Hacker News penaliza los temas con significativamente más comentarios que votos positivos.
¿Qué opinan sobre esto @sam@eviltrout? Podríamos tener un entero aquí que represente el tiempo, donde 0 significa “nunca permitir que se promocione” y 1-6000 podría significar “permitir 1 promoción cada {x} minutos” o algo así.
Es una idea interesante, algo así como un debouncing para los baches.
Parece una herramienta potente, pero veo que podría ser útil. No creo que sea algo fácil de añadir, probablemente requeriría un esfuerzo de nivel medio.
Creo que puede ser útil en algunos escenarios para evitar que un tema genere demasiado revuelo en primer lugar si la moderación lo detecta a tiempo. Especialmente en instancias con muchos usuarios.
Si el tema ya está candente y la discusión se autogestiona, el modo lento probablemente hará un mejor trabajo, ya que las notificaciones que los usuarios reciben de las interacciones en el tema (probablemente) lo mantendrán en marcha.
Estuve revisando el código fuente y, aparte de cambiar los modelos, ¿sería suficiente cambiar bypass_bump? para evitar que se les dé un nuevo impulso?
Quizás añadir un campo en Topic, algo como min_seconds_between_bumps por ejemplo y otra condición en bypass_bump?:
No estoy seguro del valor 0 que indica que el tema no debe ser impulsado en absoluto. Puede confundir a algunos usuarios. Si se hace de esta manera, creo que sería una mejor experiencia de usuario si la aplicación web no expone el cero directamente al usuario.
Si lo interpreto correctamente, la decisión sobre si hacer un “bump” ocurriría en el momento en que se publica una respuesta, pero si no se publican respuestas posteriores después del período de no “bump”, el tema nunca se moverá.
¿Sería ese el comportamiento deseado o el tema debería moverse siempre al final del período de no “bump” si se ha publicado una respuesta durante el período? Si siempre debe moverse, ¿debería moverse a “ahora” o a la hora de la última respuesta?
Sí, en este enfoque la decisión ocurriría cuando se publica la respuesta y sin respuestas posteriores el tema nunca volvería a ser impulsado. Si estoy en lo correcto, ya que de ninguna manera soy un experto en el código fuente de Discourse, esta sería la forma fácil de implementarlo.
El otro comportamiento posible, impulsar después del período de enfriamiento, probablemente requeriría más trabajo como dijo @eviltrout, ya que requeriría que la aplicación almacene el próximo impulso esperado y tenga algún tipo de planificador o trabajo de sidekiq para realizar los impulsos pendientes periódicamente.
Ambos enfoques son válidos y si esto se implementa alguna vez, no sé cuál será elegido.
Personalmente, no me importa si un tema problemático nunca vuelve a ser impulsado si no hay respuestas posteriores. Pero esa es solo mi opinión.
El tema tiene una configuración, “solo se puede impulsar una vez cada {x} minutos”, donde el número de minutos es una configuración ajustable, que va desde cero (el valor predeterminado, se puede impulsar tantas veces como haya respuestas) hasta ~10,000 (solo se puede impulsar una vez por semana). Supongamos que alguien ha introducido 60 minutos, el tema solo se puede impulsar una vez cada 60 minutos como máximo.
Cuando se publica una respuesta, comprueba la fecha del último impulso:
Si la fecha del último impulso fue hace más de 60 minutos, permite que el tema se impulse con esta nueva respuesta.
Si la fecha del último impulso fue hace menos de 60 minutos, no impulses el tema al publicar esta nueva respuesta.
Sí, esto parece simple y factible. ¿Lo añadimos a la próxima versión @sam@eviltrout?
¿Sería valioso también -1 (no se puede incrementar indefinidamente)? Creo que me inclino por no, sería difícil encontrar dichos temas más tarde (sin trabajo adicional) y si un administrador realmente quiere que un tema nunca más se incremente, probablemente tenga más sentido simplemente cerrarlo.
En realidad, creo que el tiempo máximo establecido debería ser una configuración configurable en la página de administración. Algo como max_slowbump_time o algo así.
Además, ya que estamos. ¿Sería posible aplicar también incrementos lentos a nivel de categoría?
¿Se implementó alguna vez una función como esta? Tenemos otro hilo de este tipo que impulsó a @mbauman a solicitarla originalmente y, si esta función existe ahora, sería genial poder usarla.
Restablecer fecha de re-publicación”). Aparecería un cuadro de diálogo que te pediría que ingresaras el período de tiempo. El texto sería algo como: “Limitar la frecuencia con la que este tema aparece en la parte superior de las vistas de Últimos y otras categorías a no más de una vez cada X horas”, con un valor predeterminado de aproximadamente 8 horas.