Automatische Schließung von Support-Themen 30 Tage nach letzter Antwort

[tobiaseigen]

Ich wollte mich bei Ihnen allen über ein Experiment informieren, das ich gerade ausprobiere. Einige von Ihnen haben wahrscheinlich ein besseres Community-Gedächtnis als ich, also klären Sie mich bitte auf!

Ich habe die Kategorie Support so eingestellt, dass Themen 30 Tage nach der letzten Antwort automatisch geschlossen werden. Das erscheint mir angesichts meiner jüngsten Erfahrungen in der Kategorie angemessen. Bis dahin sind die Themen gelöst oder die fragende Person ist weitergezogen. Andere mit ähnlichen Fragen können neue Themen eröffnen, die sich auf ihre spezielle Situation beziehen.

In den letzten Monaten habe ich ältere #support-Themen, die ungelöst geblieben sind, mit Hilfe dieses Filters in meiner Seitenleiste bearbeitet. In vielen Fällen werden die Themen tatsächlich recht schnell gelöst, dank sehr aufmerksamer und hilfsbereiter Mitglieder, die Fragen beantworten. Manchmal benötigen Themen nach ein oder zwei Wochen einen Anstoß, um die fragende Person zu kontaktieren und zu sehen, ob ihr Problem gelöst wurde, und um klärende Fragen zu stellen, die ihr weiterhelfen könnten (Was sind die Schritte zur Reproduktion? Haben Sie die offiziellen Installationsanweisungen verwendet? Funktioniert es im abgesicherten Modus? usw.). Wenn ich dies tue, setze ich normalerweise einen Thema-Timer, der 30 Tage nach der letzten Antwort automatisch schließt. Wenn die Person oder ein anderes Mitglied der Community nicht innerhalb von 30 Tagen antwortet, dann ist es meiner Meinung nach völlig in Ordnung, das Thema automatisch schließen zu lassen.

Es gibt jedoch auch Fälle, in denen es sinnvoll ist, Themen von Support in eine andere Kategorie zu verschieben, und das habe ich auch getan. Zum Beispiel:
→ Community = offene Community-Aufbaufragen
→ Dev = Anpassung, Erstellung neuer Plugins usw.
→ Feature oder UX = Funktionsanfragen oder Verbesserungen/Korrekturen der Benutzeroberfläche
→ Bug = Fehlermeldungen

Indem ich die Themen in Support nach einem Monat automatisch schließen lasse, anstatt dies manuell zu tun, spare ich mir etwas Zeit, da die Verwendung des Admin-Schraubenschlüssels derzeit etwas umständlich ist. Es sind mehrere Klicks entfernt!

[Moin]

Haben Sie darüber nachgedacht, wie Sie die Themen finden, die in Support gepostet wurden, da diese vorausgewählt und dann von Community-Mitgliedern in eine andere Kategorie verschoben werden? Ich kann Themen verschieben, aber ich kann den Timer nicht entfernen. Jemand anderes muss also den Timer entfernen, nachdem ich ein Thema verschoben habe.

Es ist ähnlich wie Themen, die in Community-Wiki verschoben wurden, aber keine Wikis wurden, und Themen, die von dort verschoben wurden, immer noch Wikis sind. Aber es werden weniger Themen von oder in diese Kategorie verschoben als Themen, die von Support verschoben werden.

[tobiaseigen]

Danke, dass Sie diesen Punkt angesprochen haben. Es könnte ausreichen, wenn Sie es den Moderatoren melden, damit diese die Änderung vornehmen können, es sei denn, Sie denken, dass Sie dies ständig tun werden. Wie oft verschieben Sie Themen zwischen Kategorien?

[Moin]

Wir werden sehen

Oder Sie können den Daten-Explorer bitten, herauszufinden, wie viele Themen in einem bestimmten Zeitraum verschoben wurden

Beispielabfrage

-- [params]
-- date :start_date
-- date :end_date

SELECT
  pr.user_id,
  (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int AS old_category_id,
  (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[2]::int AS new_category_id,
  COUNT(*) AS change_count
FROM post_revisions pr
WHERE pr.modifications LIKE '%category_id:%'
  AND pr.modifications ~ 'category_id:\s*-\s*[0-9]+\s*-\s*[0-9]+'
  AND pr.updated_at::date BETWEEN :start_date::date AND :end_date::date
GROUP BY pr.user_id, old_category_id, new_category_id
ORDER BY pr.user_id, change_count DESC

[ToddZ]

Danke für die Anfrage, Moin!

Dieses Mod bietet eine Startkategorieauswahl und listet einzelne Themen auf, die aus dieser Kategorie nach Datum verschoben wurden:

-- TOPICS MOVED LIST
-- [params]
-- date :start_date
-- date :end_date
-- category_id :cat_id

SELECT
  pr.user_id, pr.post_id, pr.updated_at,
  (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int AS old_category_id,
  (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[2]::int AS new_category_id
FROM post_revisions pr
WHERE (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int = :cat_id::int
  AND pr.updated_at::date BETWEEN :start_date::date AND :end_date::date
ORDER BY pr.updated_at DESC

[ToddZ]

Ich bin niemand, der ein „besseres Community-Gedächtnis“ hätte als du, aber FWIW klingt dein Ansatz vernünftig. Ich bin froh, dass jemand ungelöste Themen überprüft – und wenn ich dich richtig verstehe, werden Themen ohne Antwortbeitrag nicht automatisch geschlossen, ohne dass sie hochgeschoben werden (ich habe selbst ein paar davon, die dort hängen…).

[NateDhaliwal]

@tobiaseigen Ich bin der Meinung, dass Themen typischerweise (und am häufigsten) innerhalb von 1-3 Tagen nach ihrer Erstellung verschoben werden. Vielleicht sollte der Themen-Timer ab dem dritten Tag hinzugefügt werden, um etwas Pufferzeit zu ermöglichen, während Themen verschoben werden? Ich bezweifle jedoch, ob das ohne ein Plugin möglich ist.

[Falco]

Welchen Vorteil hat es, alle Themen zu schließen? Warum ist es ein Problem für Leute, die mit denselben Problemen wie der OP konfrontiert sind, auf ein bereits bestehendes Thema zu antworten, auch wenn dieses Thema alt ist?

Discourse macht es so nahtlos, themenfremde Antworten mit wenigen Klicks in ein neues Thema aufzuteilen, und dank AI Helper haben Sie nicht einmal Analyse-Paralyse bei der Entscheidung über Titel, Kategorie und Tags, dass meiner Meinung nach eine strenge Regel zum Schließen aller Support-Themen veraltet ist und etwas, das bei alter Forensoftware notwendig wäre.

[tobiaseigen]

Großartig! Danke für all die Antworten hier. Ich bin froh, dass ich dieses Thema begonnen habe, um herauszufinden, wie die Leute darüber denken.

Ich irre mich vielleicht, aber mein eigenes Gefühl aus meiner Erfahrung in den letzten Monaten war, dass die Kategorie Support anders ist als die anderen Kategorien, die wir derzeit haben. Die Leute kommen, um ein Problem sofort zu lösen, und fast immer ist das Problem sehr spezifisch für ihre eigenen Umstände. Wenn das Thema nicht einigermaßen schnell gelöst wird, verlieren sie das Interesse und gehen weiter, oder sie werden ungeduldig und fragen erneut in anderen Themen. In der Zwischenzeit kann die Support-Kategorie mit unbeantworteten Fragen übersät sein. Andere spätere Nutzer stoßen sie dann an, um ihre eigenen, leicht unterschiedlichen Fragen zu stellen, die besser in einem neuen Thema aufgehoben wären.

Dies unterscheidet sich von den anderen Kategorien, in denen wir offene Themen zulassen und fördern. Wenn Leute Themen in Support posten, die in andere Kategorien gehören, z. B. weil es sich tatsächlich um eine Feature request handelt, können wir sie verschieben. Oder wenn jemand Hilfe bei der Erstellung eines Plugins sucht, verschieben wir es nach Dev.

So oder so müssen #support-Themen, die unbeantwortet bleiben oder bei denen die Diskussion einschläft, nachverfolgt werden, damit sie schließlich zu einer Lösung gebracht werden können. Ich denke, eine Antwort ein paar Wochen später hinzuzufügen und sie dann 30 Tage nach der letzten Antwort zu schließen, scheint ein vernünftiger Weg zu sein, um sicherzustellen, dass dies geschieht.

Was ich hier höre, ist, dass das automatische Schließen aller #support-Themen 30 Tage später wahrscheinlich doch nicht der richtige Ansatz ist, da wir sie oft verschieben, was dann bedeutet, dass wir den Timer entfernen müssen. Aber ich denke immer noch, dass wir darauf abzielen sollten, alle #support-Themen schließlich zu schließen.

Ich werde die automatische Einstellung vorerst deaktivieren, aber den Timer weiterhin in Fällen hinzufügen, in denen ich denke, dass er sinnvoll ist. Wenn Sie bemerken, dass ich einen Timer für ein Thema gesetzt habe, bei dem Sie der Meinung sind, dass ich ihn nicht hätte setzen sollen, lassen Sie es mich wissen und den Grund dafür.

[tobiaseigen]

Ich habe die Daten-Explorer-Abfrage ausprobiert und festgestellt, dass wir in den letzten vier Wochen gemeinsam 53 Themen aus Support in andere Kategorien verschoben haben. Das ist genug, dass es definitiv unpraktisch wäre, einen Moderator bitten zu müssen, den automatischen Timer zu entfernen.

Also zurück auf Anfang, um herauszufinden, wie wir sicherstellen können, dass jeder, der in Support postet, eine zeitnahe Antwort erhält!

Es sieht so aus, als ob das Hinzufügen des Timers die Kategorieeinstellung gelöscht hat, wenn Themen, die als gelöst markiert wurden, automatisch geschlossen werden. Ich habe das jetzt auf 72 Stunden eingestellt, da ich mich nicht mehr genau daran erinnere, wie es vorher eingestellt war.

[Canapin (Coin-coin le Canapin)]

Als Benutzer bin ich immer frustriert, wenn ich auf ein Problem stoße, das ich habe, ein verwandtes Thema finde, in das ich posten möchte, und dann feststelle, dass es geschlossen ist (ich spreche nicht von gelösten Themen).

Dann muss ich entweder den Staff kontaktieren und sie bitten, das Thema zu öffnen, oder ein neues erstellen, wenn das ursprüngliche Thema die richtige Stelle zum Antworten gewesen wäre.

Ich spreche nicht speziell über Meta, sondern über meine Benutzererfahrung in anderen Foren, in denen ich das erlebt habe.

[Moin]

@tobiaseigen

Ich erinnere mich nicht mehr genau, was es vorher eingestellt war.

Es waren 30 Tage. Sie können es zum Beispiel hier sehen Passkey as (mandatory) 2FA

[tobiaseigen]

Danke! Habe es behoben. Es ist in Stunden angegeben, nicht in Tagen oder Monaten, also musste ich den Taschenrechner herausholen. 720 Stunden!

Bearbeiten: Außerdem erinnere ich mich gerade, dass ich das Mitarbeiteraktionsprotokoll überprüfen kann. Es hat aufgezeichnet, dass ich die 720 entfernt habe, als ich den automatischen Schließungs-Timer hinzugefügt habe. Aber dass es mich im UI nicht gewarnt hat, als ich die Änderungen gespeichert habe, ist etwas seltsam. Ich habe dieses Problem in einem #ux-Thema angesprochen.

[ToddZ]

Das ist mir auch passiert. Ich beginne normalerweise ein neues Thema mit „Fortsetzung des Gesprächs von [geschlossenes Thema]…“.

Manchmal habe ich nur einen Gedanken oder einen Vorschlag hinzuzufügen, anstatt weitere Fragen – aber ich stelle mir vor, dass die Priorität des Supportpersonals darin liegen muss, neue Fragen sichtbar zu machen. Es scheint, dass dies schwer zu gewährleisten sein könnte, wenn gelöste Themen für zusätzliche Beiträge dauerhaft offen gelassen würden.

[Canapin (Coin-coin le Canapin)]

Virtualmin - Virtualmin Community ist ein Beispiel: Alle Themen werden automatisch nach zwei Monaten geschlossen, unabhängig von ihrem Inhalt und ob sie gelöst wurden oder nicht.

[tobiaseigen]

Um dieses Gespräch abzuschließen… vielen Dank für all die Beiträge und die Hilfe beim Durchdenken.

Bei #support-Themen bin ich weiterhin davon überzeugt, dass das Ziel darin besteht, diese in fast allen Fällen innerhalb weniger Wochen abzuschließen. Nur so kann sichergestellt werden, dass jeder, der Hilfe sucht, zeitnah eine Antwort erhält. Andernfalls werden die Leute das Vertrauen verlieren und woanders nach Antworten suchen.

Mir ist aufgefallen, dass, wenn es einen Grund gibt, ein Thema offen zu lassen, dies in der Regel auch für die Verschiebung in eine andere Kategorie geeignet ist.

Aber ich stimme zu, dass die Idee, #support-Themen 30 Tage nach der letzten Antwort automatisch zu schließen, für uns nicht funktionieren wird. Wir wollen sicherstellen, dass sie tatsächlich gelöst werden und vermeiden, dass die Kategorie voller unbeantworteter oder nur halb beantworteter Fragen ist.