Ein sanfterer Slow Mode: langsame Stöße?

Merkmal
1

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).

16 „Gefällt mir“
2

A motivated user could write a single reply and quite many other posters though, right? ….that still would be possible in slow mode.

But I do agree that a reduced-bumping would also be useful in slow-mode. :slight_smile:

2 „Gefällt mir“
3

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).

5 „Gefällt mir“
4

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.

3 „Gefällt mir“
5

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.

4 „Gefällt mir“
6

A trick you can use today is to make topics like this unlisted, we do plan to add timers that can relist, but you could do that by hand

“Bury” topic has popped up in the past, and something we have thought about

5 „Gefällt mir“
7

Ich verstehe nicht wirklich, was Sie vorschlagen. Können Sie mir eine UI-Mockup zeigen, wie das funktionieren würde, was der Benutzer sehen würde, was der Mitarbeiter sehen würde?

Deshalb ist die Bearbeitung im Langsammodus standardmäßig eingeschränkt. Sie können die Bearbeitungslimits deaktivieren, wenn Sie Ihrer Community vertrauen, dies nicht zu tun.

Und bedenken Sie, was @sam gesagt hat. Machen Sie das Thema unsichtbar. Bitte nutzen Sie die vorhandenen Werkzeuge in Ihrem Werkzeugkasten vollständig, bevor Sie weitere vorschlagen.

8

Die Kernidee ist recht einfach: Ich würde sie im Admin-Themenmenü als „Topic Bumps begrenzen…“ bezeichnen (wahrscheinlich neben dem Eintrag „:anchor: Bump-Datum zurücksetzen“). Sie würde ein modales Fenster öffnen, das Sie auffordert, den Zeitraum einzugeben. Der Text wäre in etwa: „Begrenzen Sie die Häufigkeit, mit der dieses Thema am Anfang der neuesten und anderer Kategorieansichten erscheint, auf höchstens einmal alle X Stunden“, mit einem Standardwert von etwa 8 Stunden.

Ich bin mir nicht sicher, wie es implementiert werden soll; es könnte zustandsbehaftet sein (Verfolgung des letzten Beitrags, der die Themenaktualisierungszeit geändert hat, und Aktualisierung nur, wenn die Zeit eines neuen Beitrags mehr als X Stunden in der Zukunft liegt) oder zustandslos sein (immer die Themenaktualisierungszeit auf das abgerundete Vielfache von X Stunden vom Unix-Epoch oder dem ersten Beitrag setzen). Oder etwas anderes, egal.

Was die Anzeige für den Benutzer betrifft, bin ich mir nicht zu 100 % sicher, ob es ihnen mitgeteilt werden muss, aber es könnte als „nicht gelisteter“ Beitragsartikel erscheinen, der einfach besagt: „Dieses Thema erscheint nur einmal alle X Stunden am Anfang der Themenlisten.“

Was andere Werkzeuge betrifft, verwenden wir manchmal das Auslisten von Threads, aber hier geht es um streitsüchtige neue Benutzer – oft die Art von Person, die jeden Hinweis auf Zensur sehr übel nehmen könnte. Und ich möchte Dinge wirklich nicht zensieren/verstecken/löschen. Der ganze Punkt ist eine sanftere Intervention, die hoffentlich weniger Ärger verursacht, aber hoffentlich dazu beiträgt, die Gemüter etwas zu beruhigen.

Dies ist teilweise inspiriert von der Art und Weise, wie Hacker News Themen mit deutlich mehr Kommentaren als Upvotes bestraft.

2 „Gefällt mir“
9

Was ist Ihre Meinung dazu, @sam @eviltrout? Wir könnten hier eine Ganzzahl haben, die die Zeit darstellt, wobei 0 „niemals zulassen, dass es nach oben verschoben wird“ bedeutet und 1-6000 „erlaube 1 Verschiebung alle {x} Minuten“ oder so etwas bedeuten könnte.

1 „Gefällt mir“
10

Das ist eine interessante Idee – so etwas wie Debouncing für Stöße.

Es scheint ein Werkzeug zu sein, aber ich kann mir vorstellen, dass es nützlich ist. Ich glaube nicht, dass es einfach hinzuzufügen ist – wahrscheinlich etwas mit mittlerem Aufwand.

1 „Gefällt mir“
11

Ich denke, es kann in einigen Szenarien nützlich sein, zu verhindern, dass ein Thema von vornherein zu viel Aufmerksamkeit erhält, wenn es frühzeitig von der Moderation erkannt wird. Besonders in Instanzen mit vielen Benutzern.

Wenn das Thema bereits heiß diskutiert wird und die Diskussion sich selbst erhält, wird der langsame Modus wahrscheinlich eine bessere Arbeit leisten, da die Benachrichtigungen, die die Benutzer von Interaktionen im Thema erhalten, es (wahrscheinlich) am Laufen halten werden.

Ich habe mir den Quellcode angesehen und abgesehen von der Änderung der Modelle, würde die Änderung von bypass_bump? ausreichen, um zu verhindern, dass sie hochgestuft werden?

Vielleicht ein Feld in Topic hinzufügen, wie zum Beispiel min_seconds_between_bumps und eine weitere Bedingung in bypass_bump?:

def bypass_bump?
  !@post_successfully_saved ||
    @topic_changes.errored? ||
    @opts[:bypass_bump] == true ||
    @post.whisper? ||
    only_hidden_tags_changed? ||
    @topic.min_seconds_between_bumps == 0 ||
    (@topic.min_seconds_between_bumps > 0 &&
      (Time.now - @topic.bumped_at) / 60 < @topic.min_seconds_between_bumps)
end

Ich bin mir nicht sicher, ob der Wert 0 angibt, dass das Thema überhaupt nicht hochgestuft werden soll. Das kann einige Benutzer verwirren. Wenn es auf diese Weise gemacht wird, denke ich, dass es eine bessere Benutzererfahrung wäre, wenn die Webanwendung die Null nicht direkt dem Benutzer anzeigt.

3 „Gefällt mir“
12

Wenn ich das richtig interpretiere, würde die Entscheidung, ob ein Thema hochgeschoben wird, zum Zeitpunkt der Antwort getroffen, aber wenn nach Ablauf der Wartezeit keine weiteren Antworten gepostet werden, wird das Thema nie hochgeschoben.

Wäre das das gewünschte Verhalten oder sollte ein Thema am Ende der Wartezeit immer hochgeschoben werden, wenn während dieser Zeit eine Antwort gepostet wurde? Wenn es immer hochgeschoben werden soll, sollte es auf “jetzt” oder auf den Zeitpunkt der letzten Antwort hochgeschoben werden?

2 „Gefällt mir“
13

Ja, bei diesem Ansatz würde die Entscheidung getroffen, wenn die Antwort veröffentlicht wird, und ohne nachfolgende Antworten würde das Thema nie wieder hochgestuft. Wenn ich richtig liege, da ich keineswegs ein Experte für den Quellcode von Discourse bin, wäre dies der einfachste Weg, dies zu implementieren.

Das andere mögliche Verhalten, das Hochstufen nach der Abkühlzeit, würde wahrscheinlich mehr Arbeit erfordern, wie @eviltrout sagte, da die Anwendung den nächsten erwarteten Hochstufungstermin speichern und eine Art Zeitplaner oder Sidekiq-Job durchführen müsste, um die ausstehenden Hochstufungen periodisch durchzuführen.

Beide Ansätze sind gültig und wenn dies jemals implementiert wird, weiß ich nicht, welcher gewählt wird.

Ich persönlich habe nichts dagegen, wenn ein problematisches Thema nie wieder hochgestuft wird, wenn es keine nachfolgenden Antworten gibt. Aber das ist nur meine Meinung.

2 „Gefällt mir“
14

Meine Überlegung ist, dass die einfachste Logik Folgendes ist:

  • Ein Thema hat eine Einstellung „Kann nur alle {x} Minuten erneut verschoben werden“, wobei die Anzahl der Minuten eine einstellbare Einstellung ist, die von null (Standard, kann beliebig oft verschoben werden, solange es Antworten gibt) bis zu etwa 10.000 (kann nur einmal pro Woche verschoben werden) reicht. Nehmen wir an, jemand hat 60 Minuten eingegeben, das Thema kann maximal nur alle 60 Minuten erneut verschoben werden.

  • Wenn eine Antwort gepostet wird, überprüfen Sie das letzte Datum der erneuten Verschiebung:

    • Wenn das letzte Datum der erneuten Verschiebung mehr als 60 Minuten zurückliegt, erlauben Sie, dass das Thema mit dieser neuen Antwort erneut verschoben wird.

    • Wenn das letzte Datum der erneuten Verschiebung weniger als 60 Minuten zurückliegt, verschieben Sie das Thema nicht erneut, wenn Sie diese neue Antwort posten.

Ja, das scheint einfach und machbar zu sein. Fügen wir es zur nächsten Version hinzu, @sam @eviltrout?

6 „Gefällt mir“
15

Wäre -1 (kann nicht unbegrenzt hochgestuft werden) auch wertvoll? Ich neige eher zu nein, es wäre schwierig, solche Themen später zu finden (ohne zusätzliche Arbeit) und wenn ein Administrator ein Thema wirklich nie wieder hochgestuft haben möchte, ist es wahrscheinlich sinnvoller, es einfach zu schließen.

16

Ich denke eigentlich, dass die maximale Zeit eine konfigurierbare Einstellung auf der Admin-Seite sein sollte. Etwas wie max_slowbump_time oder so.

Auch, während wir schon dabei sind. Könnte es möglich sein, langsame Erhöhungen auch auf Kategorieebene anzuwenden?

17

Wurde eine Funktion wie diese jemals implementiert? Wir haben einen weiteren Thread dieser Art, der @mbauman ursprünglich dazu veranlasste, ihn anzufordern, und wenn diese Funktion jetzt existiert, wäre es großartig, sie nutzen zu können.