J’apprécie vraiment l’intention derrière le mode lent, mais cela ne résout pas tout à fait le principal moteur des flammes sur notre Discourse :
Quelqu’un arrive « à chaud » — souvent un nouveau venu, ou venant d’une autre communauté — et énumère une série de griefs.
De nombreux membres existants répondent pour discuter avec/au poster original, avec des motivations variées (mais le syndrome « Je pense que quelqu’un a tort sur Internet » [xkcd: Duty Calls] arrive en tête).
Le poster original souhaite répondre à chacun.
Même dans les meilleures discussions, les choses s’emballent rapidement.
Le mode lent n’aide pas ici, car il s’agit d’un problème de type « plusieurs vers un ». Cela a souvent pour effet d’aliéner davantage le nouveau membre, car c’est lui qui subit le plus lourd le contrecoup de la limitation : beaucoup peuvent lui répondre pendant que son minuteur de récupération s’écoule, puis il n’obtient qu’un seul message pour répondre.
Un outil que j’aimerais avoir dans ma boîte à outils pour ce genre de situations serait de ralentir le remontage des sujets. Les listes par défaut (à la fois « Récent » et « Populaire ») privilégient ces sujets « chauds ». J’aimerais pouvoir limiter les remontages à une fois toutes les 12 heures ou quelque chose de similaire. Ce ne serait pas une désinscription complète, mais une déprioritisation significative qui pourrait aider à limiter le nombre de nouveaux participants à la discussion (sauf s’ils la recherchent activement, ce qui ne pose aucun problème).
Un utilisateur motivé pourrait tout de même écrire une seule réponse et en faire poster beaucoup d’autres, non ? … Cela resterait possible en mode lent.
Mais je suis d’accord pour dire qu’une réduction du « bumping » serait également utile en mode lent.
Tout à fait, mais de tels monstres de réponses qui répondent à de nombreux messages rendent le sujet encore plus difficile à gérer. Les scissions deviennent impossibles, et ils ont tendance à mettre l’auteur encore plus sur la défensive (ou du moins à donner l’apparence d’une aggravation, simplement en raison de ce mur de texte).
C’est en fait une autre conséquence involontaire du mode lent que nous avons observée sur Julia discourse, une instance hébergée payante très active : le mode lent est activé et certaines personnes commencent à modifier leurs messages plutôt que d’en écrire de nouveaux. Problème similaire lorsqu’on attribue le niveau TL0 à quelqu’un qui pose problème : il ne peut pas créer de nouveaux messages, mais peut toujours modifier ses anciens, ce qu’il fera donc, ce qui est particulièrement néfaste s’il a écrit des propos incendiaires auxquels des gens ont répondu, et qu’il les modifie ensuite, donnant l’impression que la réponse est hors de propos.
Mais oui, je soutiens pleinement la suggestion de @mbauman : pouvoir empêcher un sujet brûlant d’être reboosté aussi souvent serait très utile pour calmer les choses.
Outre le fait d’empêcher le sujet brûlant d’être remonté, il pourrait être judicieux de retarder les notifications. Cela résout en quelque sorte le problème où quelqu’un répond à ou mentionne plusieurs utilisateurs.
Une astuce que vous pouvez utiliser dès aujourd’hui consiste à rendre des sujets comme celui-ci non répertoriés. Nous prévoyons d’ajouter des minuteries pour les réafficher, mais vous pouvez aussi le faire manuellement.
« Enfoncer » un sujet a déjà été évoqué par le passé, et c’est quelque chose que nous avons envisagé.
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.