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.
Non capisco bene cosa stai proponendo. Puoi mostrarmi un mockup dell’interfaccia utente di come funzionerebbe, cosa vedrebbe l’utente, cosa vedrebbe il membro dello staff?
Ecco perché la modifica è limitata per impostazione predefinita in Modalità Lenta. Puoi disattivare i limiti di modifica se ti fidi della tua community a non farlo.
E considera ciò che ha detto @sam. Rendi l’argomento non elencato. Per favore, utilizza pienamente gli strumenti esistenti nel tuo kit prima di proporne altri.
L’idea di base è piuttosto semplice: la chiamerei qualcosa come “Limita Bump Argomenti…” nel menu degli argomenti dell’amministratore (probabilmente posizionata accanto all’elemento “ Reimposta Data Bump”). Aprirebbe una finestra modale che ti chiederebbe di inserire il periodo di tempo. Il testo sarebbe qualcosa del tipo: “Limita la frequenza con cui questo argomento appare in cima alle viste più recenti e ad altre categorie a non più di una volta ogni X ore”, con un valore predefinito di circa 8 ore.
Non ho una forte preferenza su come verrebbe implementato; potrebbe essere stateful (tenere traccia dell’ultimo post che ha aggiornato l’ora dell’argomento e aggiornarla solo se l’ora di un nuovo post è più di X ore nel futuro) o stateless (impostare sempre l’ora di aggiornamento dell’argomento al piano inferiore multiplo di X ore dall’epoca Unix o dal primo post). O qualcos’altro, quello che sia.
Per quanto riguarda ciò che viene visualizzato all’utente, non sono sicuro al 100% che debba essere comunicato loro, ma potrebbe apparire come un elemento di post “non elencato”, affermando semplicemente: “questo argomento apparirà in cima alle liste degli argomenti solo una volta ogni X ore”.
Per quanto riguarda altri strumenti, a volte utilizziamo la non elencazione dei thread, ma questo riguarda principalmente i nuovi utenti combattivi, spesso il tipo di persona che potrebbe offendersi molto per qualsiasi accenno di censura. E io davvero non voglio censurare/nascondere/eliminare cose. L’intero punto è un intervento più morbido che si spera sia meno probabile che causi ulteriore aggravamento di per sé, ma che speriamo aiuti a mantenere la temperatura un po’ più bassa.
Questo è in parte ispirato al modo in cui Hacker News penalizza gli argomenti con molti più commenti che voti positivi.
Cosa ne pensate @sam@eviltrout? Potremmo avere un numero intero qui che rappresenta il tempo, dove 0 significa “non consentire mai il ripristino” e 1-6000 potrebbe significare “consenti 1 ripristino ogni {x} minuti” o qualcosa del genere.
È un’idea interessante, qualcosa come il debouncing per i bump.
Sembra uno strumento potente, ma capisco che possa essere utile. Non credo sia una cosa facile da aggiungere, probabilmente richiederebbe uno sforzo di livello medio.
Penso che possa essere utile in alcuni scenari per evitare che un argomento si surriscaldi troppo in primo luogo, se viene intercettato precocemente dalla moderazione. Specialmente in istanze con molti utenti.
Se l’argomento è già acceso e la discussione si auto-sostiene, la modalità lenta probabilmente farà un lavoro migliore poiché le notifiche che gli utenti ricevono dalle interazioni nell’argomento lo manterranno (probabilmente) in corso.
Stavo controllando il codice sorgente e, a parte la modifica dei modelli, la modifica di bypass_bump? sarebbe sufficiente per impedirne il bump?
Forse aggiungere un campo in Topic, qualcosa come min_seconds_between_bumps ad esempio e un’altra condizione in bypass_bump?:
Non sono sicuro che il valore 0 indichi che l’argomento non debba essere bumpato affatto. Può confondere alcuni utenti. Se fatto in questo modo, penso che sarebbe una migliore UX se la webapp non espone direttamente lo zero all’utente.
Se interpreto correttamente, la decisione se fare un bump avverrà al momento in cui viene pubblicato un reply ma se non vengono pubblicati ulteriori reply dopo il periodo di no-bump, l’argomento non verrà mai più bumpato.
Sarebbe questo il comportamento desiderato o l’argomento dovrebbe sempre fare un bump alla fine del periodo di no-bump se è stato pubblicato un reply durante il periodo? Se dovrebbe sempre fare un bump, dovrebbe fare un bump a “ora” o all’ora dell’ultimo reply?
Sì, in questo approccio la decisione avverrebbe al momento della pubblicazione della risposta e senza risposte successive l’argomento non verrebbe mai più effettuato il bump. Se ho capito bene, dato che non sono assolutamente un esperto del codice sorgente di Discourse, questo sarebbe il modo più semplice per implementarlo.
L’altro comportamento possibile, il bump dopo il periodo di raffreddamento, richiederebbe probabilmente più lavoro come ha detto @eviltrout, poiché richiederebbe all’applicazione di memorizzare il prossimo bump previsto e di avere una sorta di pianificatore o processo sidekiq per eseguire periodicamente i bump in sospeso.
Entrambi gli approcci sono validi e se mai venissero implementati non so quale verrebbe scelto.
Personalmente, non mi dispiace se un argomento problematico non viene mai più effettuato il bump se non ci sono risposte successive. Ma questa è solo la mia opinione.
Il mio pensiero è che la logica più semplice sia questa:
L’argomento ha un’impostazione, “può essere aggiornato solo una volta ogni {x} minuti” dove il numero di minuti è un’impostazione regolabile, che va da zero (l’impostazione predefinita, può essere aggiornato tante volte quante sono le risposte) a circa 10.000 (può essere aggiornato solo una volta alla settimana). Supponiamo che qualcuno abbia inserito 60 minuti, l’argomento può essere aggiornato solo una volta ogni 60 minuti al massimo.
quando viene pubblicata una risposta, controlla la data dell’ultimo aggiornamento:
se l’ultimo aggiornamento è stato più di 60 minuti fa, consenti l’aggiornamento dell’argomento da parte di questa nuova risposta.
se l’ultimo aggiornamento è stato meno di 60 minuti fa, non aggiornare l’argomento durante la pubblicazione di questa nuova risposta.
Sì, questo sembra semplice e fattibile… aggiungiamolo alla prossima release @sam@eviltrout?
Potrebbe essere utile anche -1 (non si può incrementare indefinitamente)? Penso di essere più propenso al no, sarebbe difficile trovare tali argomenti in seguito (senza lavoro extra) e se un amministratore vuole davvero che un argomento non venga mai più incrementato, probabilmente ha più senso chiuderlo.
In realtà penso che il tempo massimo impostato dovrebbe essere un’impostazione configurabile nella pagina di amministrazione. Qualcosa come max_slowbump_time o qualcosa di simile.
Inoltre, visto che ci siamo. Sarebbe possibile applicare i slow bump anche a livello di categoria?
Una funzionalità del genere è mai stata implementata? Abbiamo un altro thread simile che ha spinto @mbauman a richiederla originariamente e se questa funzionalità esiste ora, sarebbe fantastico poterla utilizzare.
Reimposta Data Bump”). Aprirebbe una finestra modale che ti chiederebbe di inserire il periodo di tempo. Il testo sarebbe qualcosa del tipo: “Limita la frequenza con cui questo argomento appare in cima alle viste più recenti e ad altre categorie a non più di una volta ogni X ore”, con un valore predefinito di circa 8 ore.