Eine kürzlich durchgeführte Änderung an Discourse hat das „Anstoßen“ (Bump) beim Bearbeiten des letzten (oder ersten Beitrags) in einem Thread entfernt.
Dies war eine Funktion, auf die wir uns verlassen hatten, und es gibt keine praktikable Methode, dies für Mitglieder ohne Mitarbeiter-Rang zu imitieren.
Wir profitierten von dieser Funktionalität hauptsächlich, um Beiträge im Stil von Ankündigungen oder Beiträge, die absichtlich keine oder nur wenige Antworten erhielten, nach oben zu bringen.
Dies waren echte Aktualisierungen eines Themas, bei denen durch eine Bearbeitung nun veraltete Informationen entfernt wurden. Dass der Beitrag wieder an die Spitze des „Neueste“-Feeds rückte, war sehr wünschenswert, da es alle Mitglieder darüber informierte, dass eine Änderung vorgenommen worden war.
Ja, dies könnte bis zu einem gewissen Grad durch eine Kette von Antworten imitiert werden, aber mit der Zeit wird dies für den Benutzer umständlich, um nachzuvollziehen, was kommuniziert wurde (stellen Sie sich zum Beispiel 10 Antworten mit Änderungen vor). Es war viel sauberer, den ursprünglichen Beitrag / den letzten Beitrag zu bearbeiten und den Thread im neuesten Feed nach oben steigen zu lassen.
Ich weiß, dass es auf beiden Seiten Befürworter für diese Änderung geben wird, aber dies war über viele Jahre ein langjähriger Präzedenzfall in Discourse, und das Hinzufügen einer Option, die vorherige Funktionalität für Discourse wiederherzustellen, wird alle zufriedenstellen. Vielleicht kann die Optionalität im Laufe der Zeit erweitert werden, um genau zu steuern, welche Aktivität bei einem Beitrag dazu führt, dass er im neuesten Feed nach oben rückt.
Ein Link zum Bug-Thread, in dem diese Änderung diskutiert wurde, ist unten aufgeführt:
Ich kann hier nicht abstimmen, da ich das erforderliche Vertrauenslevel noch nicht erreicht habe, aber ich möchte meine Zustimmung zu dieser Änderung ebenfalls bekräftigen, falls dies möglich ist.
Wie ich bereits sagte, vermisse ich auch das Hochstufen von Themen, wenn eine sinnvolle Bearbeitung stattfindet.
Ich verwende rss-polling, um über Wartungsarbeiten an meinem Forum durch den RSS-Feed von https://status.discourse.org/ benachrichtigt zu werden. Das Thema wird erstellt, wenn die Wartung beginnt, und es wurde bei der Bearbeitung, die ankündigt, dass sie beendet ist, hochgestuft. Dieses Hochstufen fehlt nun, und ich möchte nicht, dass die Themen Wikis sind, da kein Benutzer sie bearbeiten sollte, noch möchte ich, dass sie als Dokumente (docs) gelten. Die aktuellen Workarounds helfen also nicht.
In einem Forum haben wir ein Galerie-Thema, das die Projekte der Benutzer zusätzlich zu den einzelnen Themen präsentiert, in denen Benutzer ihre Projekte vorstellen. Dieses Thema ist sehr hilfreich, um Inspiration zu sammeln. Wir fügen ein Bild aus dem Präsentationsthema und einen Link dazu in dieses Galerie-Thema ein. Zu viele Bilder in einem Beitrag haben zu Leistungsproblemen geführt und erschweren auch die Bearbeitung. Daher erstellen wir für jeweils 10 Projekte einen neuen Beitrag. Das Hochstufen beim Bearbeiten, wenn das 2. oder 9. Projekt hinzugefügt wurde, war hilfreich. Es hilft den Benutzern, die Aktualisierung zu bemerken, und war besonders hilfreich für diejenigen, die manuell Projekte zum Thema hinzufügen. Dank des Aktivitätsdatums konnte ich sofort sehen, ob jemand anderes das Projekt bereits hinzugefügt hatte. Jetzt muss jeder von uns das Thema öffnen, um dies zu überprüfen.
Es gibt auch andere Themen, die ähnlich funktionieren: Themen, die als retrospektiver Überblick über Änderungen/Aktivitäten innerhalb eines Monats dienen und bei denen der letzte Beitrag über den aktuellen Monat mehrmals aktualisiert wird. Dies funktionierte sehr gut, weil Änderungen am letzten Beitrag das Thema hochstufen. Das Posten jeder Änderung einzeln würde die Übersichtlichkeit der monatlich gebündelten Einträge beeinträchtigen und würde immer noch bedeuten, dass Aktualisierungen bestehender Einträge leicht übersehen werden. Ein neues Thema jeden Monat für ein paar Einträge fühlt sich nach zu viel an, und es würde auch bedeuten, dass Benutzer ihre Benachrichtigungen jeden Monat neu einrichten müssten, oder wir bräuchten eine ganze Unterkategorie, die es ihnen ermöglicht, ihren Standard-Benachrichtigungsstatus einzurichten.
Mir hat es auch gefallen, dass Kategorien- und Tag-Änderungen bei unbeantworteten Themen diese hochgestuft haben. Am häufigsten verwende ich eine (gefilterte) Liste der neuesten Themen. Und wenn ein Thema einen schlecht gewählten Titel hatte oder in der falschen Kategorie war, habe ich es möglicherweise nicht angeklickt. Wenn jemand diese Informationen verbessert, könnte ich erkennen, dass ich doch helfen kann. Deshalb war es hilfreich, wenn eine solche Änderung dazu führte, dass das Thema wieder über meine Leselinie rückte.
Außerdem war es hilfreich, etwas über Kategorien und Tags zu erfahren. Ich habe oft von neuen Tags erfahren, weil sie einem neuen Thema hinzugefügt wurden, oder vom detaillierten Unterschied zwischen Kategorien anhand von Themen, die von einem Moderator verschoben wurden. Ich habe manchmal sogar gefragt, warum, weil ich denke, dass die Möglichkeit, Themen in andere Kategorien zu verschieben, auch mit der Verantwortung einhergeht, den Unterschied zwischen ihnen zu kennen.
Mir gefällt auch der Ansatz, dass die Einstellungen von Discourse einen zwingen, Informationen hinzuzufügen, anstatt einen weiteren Beitrag zu schreiben.
Um die Meldung im Pop-up zu zitieren:
Dies ergibt jedoch nur Sinn, wenn andere bemerken, dass Sie Ihren Beitrag bearbeitet haben, um weitere Informationen hinzuzufügen. Ein Beispiel, dem ich auf Meta schon mehrmals begegnet bin, sind Aktualisierungen eines Beitrags, nachdem eine Pull-Anfrage zusammengeführt wurde. Das Hinzufügen dieser Informationen zum Beitrag benachrichtigt diejenigen nicht, die den Beitrag bereits gelesen haben, und diejenigen, die dies nicht getan haben, können dies leicht anhand des Abzeichens in der Onebox erkennen.
Für mich ergibt es keinen Sinn, dass die Einstellung, die mehr als drei aufeinanderfolgende Antworten eines Benutzers blockiert, immer noch aktiv ist und Bearbeitungen als Lösung vorschlägt, wenn diese Bearbeitungen leider nicht mehr die Wirkung haben, die sie einst hatten.
Ich habe keine starke Meinung zu dieser Funktion, aber ein verwandtes Problem ist, dass ich Beiträge gerne automatisch nach oben verschiebe und dann die Nachricht darüber entferne, dass sie verschoben wurde, was aber nicht mehr möglich ist. Wenn ich die Bump-Nachricht lösche, sinkt die Nachricht wieder an ihre ursprüngliche Position zurück. Wenn das Bearbeiten einer Nachricht diese nach oben verschieben würde, ohne dass „zuletzt vor 1 Tag verschoben“ erstellt wird, wäre das nützlich.
(Ich würde es vorziehen, den Beitrag nach oben verschieben, die Bump-Nachricht löschen und den Beitrag trotzdem auf der Startseite belassen zu können, es sei denn, ich führe manuell „Bump-Datum zurücksetzen“ aus.)
Interessante Idee, alles, was die Funktionalität wiederherstellt, bei der Bearbeitungen den Beitrag im Aktivitäts-Feed nach oben verschoben haben, wäre willkommen
@lindsey kann irgendetwas getan werden, um einen Teil dieser Funktionalität wiederherzustellen, oder ist es jetzt zu lange her und das ist die neue Normalität?
Ich fürchte, wir haben derzeit keine Pläne, die Änderung rückgängig zu machen / das Hochstufen von Bearbeitungen bei allen Änderungen wiederherzustellen. Ich verstehe, dass das nicht die Antwort ist, die Sie hören möchten, aber wir werden dieses Thema weiterhin beobachten und überlegen, wie wir Ihre Anwendungsfälle in Zukunft besser unterstützen können.
Die Tatsache, dass etwas nicht mehr passiert, ist es auch nicht. Gibt es Daten darüber, wie viele Administratoren bemerkt haben, dass sich das Verhalten von Discourse geändert hat? Ich verstehe Ihr Argument, dass es wiederholte Anfragen gab, wie man ein Hochschieben verhindern kann. Es liegt auf der Hand, dass Admins ein Hochschieben bemerken, das sie nicht wollen. Aber wenn ein Thema nicht hochgeschoben wird, bemerkt man nicht einmal, dass es nicht hochgeschoben wurde, obwohl man es sich gewünscht hätte. Es scheint also weniger wahrscheinlich, dass Leute danach fragen.
Außerdem kam kürzlich wieder zur Sprache, dass Spam leichter bemerkt wird, wenn das Thema hochgeschoben wird hier. Ich frage mich, warum dies in dem jetzt eher begrenzten Fall relevant ist, in dem ein Beitrag beim Bearbeiten hochgeschoben werden sollte. Aber es spielte keine Rolle, als die Standardeinstellung für die meisten Beiträge geändert wurde. Warum benötigt ein erster Beitrag, der ein Wiki ist, mehr Spamschutz als ein letzter Beitrag in einem Thema, der ein Wiki ist?
Wie ich schon oft gesagt habe, verstehe ich die Vorteile, aber es scheint nicht viel Interesse daran zu geben, Lösungen für die Nachteile zu finden. Es nützt nichts, wenn es nach einem Jahr oder so einen Ersatz für die aktuellen Arbeitsabläufe gibt. Ich muss mir jetzt eine neue Lösung suchen, da nicht mehr viel Zeit bleibt, in der es eine unterstützte Version von Discourse gibt, bei der eine Bearbeitung des letzten Beitrags das Thema an die Spitze verschiebt.
Dies ist überhaupt nicht durch die Aufdeckung von Spam motiviert.
Wiki- und Dokumentenbeiträge werden nach der Theorie hochgeschoben, dass Bearbeitungen dieser Beiträge im Allgemeinen von Interesse sind.
Was den Spamschutz betrifft, so lautet die Theorie jetzt, dass diese Hochstufungen nie wirklich viel zusätzliche Reichweite gebracht haben. Die meisten Beiträge sind nicht der letzte Beitrag, und Bearbeitungen daran wurden ohnehin nie durch Hochstufungen angezeigt. Wenn also Spam durch Bearbeitungen ein Problem ist, benötigt er ohnehin eine andere Lösung. Dies war nie wirklich eine effektive Lösung für dieses Problem.
Ich glaube, es liegt ein Missverständnis vor. Mein Punkt bezog sich nicht darauf, warum Wiki-Beiträge im ersten Beitrag hochgeschoben werden. Ich sprach über die Gründe für die Einschränkung des API-Parameters no-bump, wie im GitHub-Kommentar erwähnt:
Sollte dies auf API-Schlüssel des Personals beschränkt werden? Ich denke nicht, dass wir möchten, dass normale Benutzer das Hochschieben umgehen können (es würde ihnen ermöglichen, Spam in Themen einzuschleusen, ohne ihn in die Aufmerksamkeit der Leute zu rücken).
Wenn Spam wirklich das Problem wäre, dann sollte diese Einschränkung konsistent angewendet werden, nicht nur in den wenigen verbleibenden Fällen, in denen ein Hochschieben stattfindet. Das hat mich überrascht: Die Begründung nennt Spam hier als Problem, aber das Hochschieben soll beispielsweise bei Wikis, die der letzte Beitrag in einem Thema sind, kein Spam-Schutzmechanismus sein.
Ich weiß es zu schätzen, dass Wiki-Beiträge bei Aktualisierungen hochgeschoben werden (obwohl die Benutzererfahrung, an das Ende des Themas gebracht zu werden, während der Grund für das Hochschieben der erste Beitrag ist, immer noch verwirrend ist). Mein Punkt ist nur, auf diese scheinbare Inkonsistenz in Bezug auf Spam hinzuweisen.
Ein weiterer Fall, in dem ich gerne über die Bearbeitung des letzten Beitrags informiert worden wäre, es aber verpasst habe, weil das Thema nicht nach oben verschoben wurde: Restrict uploads - #30 by Arkshine