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.
Je ne comprends pas vraiment ce que vous proposez. Pouvez-vous me montrer une maquette de l’interface montrant comment cela fonctionnerait, ce que l’utilisateur verrait, ce que le membre du personnel verrait ?
C’est pourquoi la modification est limitée par défaut en mode lent. Vous pouvez désactiver les limites de modification si vous faites confiance à votre communauté pour ne pas le faire.
Et considérez ce que @sam a dit. Rendez le sujet non répertorié. Veuillez utiliser pleinement les outils existants dans votre boîte à outils avant d’en proposer de nouveaux.
L’idée principale est assez simple : je l’appellerais quelque chose comme « Limiter les bumps de sujet… » dans le menu des sujets d’administration (probablement placé à côté de l’élément « Réinitialiser la date de bump »). Cela ouvrirait une boîte de dialogue qui vous inviterait à saisir la période. Le texte serait quelque chose comme : « Limiter la fréquence à laquelle ce sujet apparaît en haut des vues les plus récentes et des autres catégories à une fois toutes les X heures au maximum », avec une valeur par défaut d’environ 8 heures.
Je ne suis pas très attaché à la façon dont cela serait implémenté ; cela pourrait être avec état (garder une trace du dernier message qui a mis à jour l’heure de bump du sujet, et ne le mettre à jour que si l’heure d’un nouveau message est plus de X heures dans le futur) ou cela pourrait être sans état (toujours définir l’heure de mise à jour du sujet au multiple inférieur de X heures à partir de l’époque Unix ou du premier message). Ou autre chose, peu importe.
Quant à ce qui est affiché à l’utilisateur, je ne suis pas sûr à 100 % qu’il faille le lui communiquer, mais cela pourrait apparaître comme un élément de message « non répertorié », indiquant simplement : « ce sujet n’apparaîtra en haut des listes de sujets qu’une fois toutes les X heures. »
Quant aux autres outils, nous utilisons parfois le non-référencement de fils de discussion, mais tout cela concerne les nouveaux utilisateurs combatifs — souvent le genre de personne qui pourrait s’offusquer grandement de tout soupçon de censure. Et je ne veux vraiment pas censurer/cacher/supprimer des choses. Le but est une intervention plus douce qui, espérons-le, sera moins susceptible de causer plus d’agacement en soi, mais qui aidera à maintenir la température un peu plus basse.
Ceci est quelque peu inspiré par la façon dont Hacker News pénalise les sujets ayant beaucoup plus de commentaires que de votes positifs.
Qu’en pensez-vous @sam@eviltrout ? Nous pourrions avoir un entier ici représentant le temps, où 0 signifie « ne jamais autoriser le renvoi » et 1-6000 pourrait signifier « autoriser 1 renvoi toutes les {x} minutes » ou quelque chose de ce genre.
C’est une idée intéressante - quelque chose comme le “debouncing” pour les secousses.
Cela ressemble à un outil électrique, mais je vois son utilité. Je ne pense pas que ce soit quelque chose de facile à ajouter - probablement un effort de niveau moyen.
Je pense que cela pourrait être utile dans certains scénarios pour éviter qu’un sujet ne s’enflamme trop en premier lieu s’il est détecté tôt par la modération. Surtout dans les cas avec beaucoup d’utilisateurs.
Si le sujet est déjà en surchauffe et que la discussion s’auto-entretient, le mode lent fera probablement un meilleur travail car les notifications que les utilisateurs reçoivent des interactions dans le sujet le maintiendront (probablement) en cours.
Je vérifiais le code source et, outre la modification des modèles, bypass_bump? suffirait-il à les empêcher d’être promus ?
Peut-être ajouter un champ dans Topic, quelque chose comme min_seconds_between_bumps par exemple et une autre condition dans `bypass_bump? :
Je ne suis pas sûr que la valeur 0 indique que le sujet ne doit pas du tout être promu. Cela pourrait confondre certains utilisateurs. Si c’est fait ainsi, je pense que ce serait une meilleure expérience utilisateur si l’application web n’expose pas directement le zéro à l’utilisateur.
Si j’interprète correctement, la décision de remonter se produirait au moment où une réponse est publiée, mais si aucune réponse ultérieure n’est publiée après la période de non-remontée, le sujet ne remontera jamais.
Ce serait le comportement souhaité ou le sujet devrait-il toujours remonter à la fin de la période de non-remontée si une réponse a été publiée pendant la période ? S’il doit toujours remonter, doit-il remonter à “maintenant” ou à l’heure de la dernière réponse ?
Oui, dans cette approche, la décision se ferait au moment où la réponse est publiée et sans réponses ultérieures, le sujet ne serait jamais remonté. Si j’ai bien compris, et comme je ne suis en aucun cas un expert du code source de Discourse, ce serait la manière la plus simple de l’implémenter.
L’autre comportement possible, remonter après la période de refroidissement, nécessiterait probablement plus de travail, comme l’a dit @eviltrout, car il faudrait que l’application stocke le prochain remontage attendu et ait une sorte de planificateur ou de tâche sidekiq pour effectuer les remontages en attente périodiquement.
Les deux approches sont valides et si cela est un jour implémenté, je ne sais pas laquelle sera choisie.
Personnellement, cela ne me dérange pas qu’un sujet problématique ne soit plus jamais remonté s’il n’y a pas de réponses ultérieures. Mais ce n’est que mon opinion.
Ma réflexion est que la logique la plus simple est la suivante :
le sujet a un paramètre, « ne peut être remonté qu’une fois toutes les {x} minutes », où le nombre de minutes est un paramètre réglable, allant de zéro (par défaut, peut être remonté autant de fois qu’il y a de réponses) à environ 10 000 (ne peut être remonté qu’une fois par semaine). Supposons que quelqu’un ait entré 60 minutes, le sujet ne peut être remonté qu’une fois toutes les 60 minutes maximum.
lorsqu’une réponse est publiée, vérifiez la date du dernier remontage :
si la date du dernier remontage remonte à plus de 60 minutes, autorisez le sujet à être remonté par cette nouvelle réponse.
si la date du dernier remontage remonte à moins de 60 minutes, ne remontez pas le sujet lors de la publication de cette nouvelle réponse.
Oui, cela semble simple et réalisable… ajoutons-le à la prochaine version @sam@eviltrout ?
Est-ce que -1 (ne peut pas être relancé indéfiniment) pourrait également être utile ? Je pense que je penche plutôt vers le non, il serait difficile de retrouver de tels sujets plus tard (sans travail supplémentaire) et si un administrateur veut vraiment qu’un sujet ne soit jamais, jamais relancé, il serait probablement plus logique de le fermer.
Je pense en fait que le temps maximum défini devrait être un paramètre configurable sur la page d’administration. Quelque chose comme max_slowbump_time ou autre chose.
Aussi, pendant que nous y sommes. Serait-il possible d’appliquer également des “slow bumps” au niveau de la catégorie ?
Une fonctionnalité comme celle-ci a-t-elle déjà été implémentée ? Nous avons un autre fil de discussion de ce type qui a incité @mbauman à le demander initialement et si cette fonctionnalité existe maintenant, ce serait formidable de pouvoir l’utiliser.
Réinitialiser la date de bump »). Cela ouvrirait une boîte de dialogue qui vous inviterait à saisir la période. Le texte serait quelque chose comme : « Limiter la fréquence à laquelle ce sujet apparaît en haut des vues les plus récentes et des autres catégories à une fois toutes les X heures au maximum », avec une valeur par défaut d’environ 8 heures.