Ich mag die Absicht hinter dem Slow Mode sehr, aber er adressiert nicht ganz den häufigsten Auslöser für Flammenkriege in unserem Discourse:
- Jemand kommt „heiß
Ein motivierter Nutzer könnte zwar eine einzelne Antwort und ziemlich viele andere Poster schreiben, oder? … Das wäre im Slow-Modus immer noch möglich.
Aber ich stimme zu, dass ein reduziertes Aufwärmen auch im Slow-Modus nützlich wäre. 
2 „Gefällt mir“
Absolut, aber solche Monstroposts, die auf viele Nachrichten antworten, machen das Thema noch schwieriger zu verwalten. Aufteilungen werden unmöglich, und sie neigen dazu, den Poster noch mehr in eine Konfrontation zu treiben (oder zumindest den Anschein von Verärgerung zu erwecken, allein durch die große Textwand).
5 „Gefällt mir“
Das ist tatsächlich eine weitere unbeabsichtigte Folge des Slow-Modus, die wir auf Julia discourse beobachtet haben, einer kostenpflichtigen gehosteten Instanz, die sehr aktiv ist: Der Slow-Modus wird aktiviert, und einige Nutzer beginnen, ihre Beiträge zu bearbeiten, anstatt neue zu schreiben. Ein ähnliches Problem tritt auf, wenn jemand, der Probleme verursacht, auf TL0 gesetzt wird: Sie können keine neuen Beiträge verfassen, aber immer noch ihre alten bearbeiten. Das führt dazu, dass sie das tun – was besonders problematisch ist, wenn sie provokante Inhalte geschrieben haben, auf die andere antworten, und diese Inhalte dann bearbeiten, wodurch die Antworten plötzlich unpassend wirken.
Aber ja, ich unterstütze @mbaumans Vorschlag ausdrücklich – die Möglichkeit zu haben, zu verhindern, dass ein heißes Thema so häufig nach oben gerückt wird, wäre sehr hilfreich, um die Situation zu beruhigen.
3 „Gefällt mir“
Zusätzlich dazu, dass verhindert wird, dass das Hot-Topic nach oben gerückt wird, könnte es eine gute Idee sein, die Benachrichtigungen zu verzögern. Das löst gewissermaßen das Problem, wenn jemand mehreren Nutzern antwortet oder sie erwähnt.
4 „Gefällt mir“
Ein Trick, den du heute anwenden kannst, besteht darin, Themen wie dieses als nicht gelistet zu markieren. Wir planen zwar, Timer hinzuzufügen, die eine erneute Veröffentlichung automatisch vornehmen, aber du könntest das auch manuell erledigen.
Die Option „Thema begraben“ wurde in der Vergangenheit bereits vorgeschlagen und ist etwas, das wir in Betracht gezogen haben.
5 „Gefällt mir“
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.
Die Kernidee ist recht einfach: Ich würde sie im Admin-Themenmenü als „Topic Bumps begrenzen…“ bezeichnen (wahrscheinlich neben dem Eintrag „
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“
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“
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“
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“
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“
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“
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“
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.
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?
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.