Sollten Support-Themen automatisch 30 Tage nach der letzten Antwort geschlossen werden? (Antwort: nein)

[tobiaseigen]

Ich wollte mich bei euch allen wegen eines Experiments melden, das ich gerade durchführe. Einige von euch haben wahrscheinlich ein besseres Gedächtnis für die Community als ich, also bitte helft mir auf den richtigen Weg!

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

In den letzten Monaten habe ich ältere, noch offene Themen in Support gesichtet und dabei diesen Filter in meiner Seitenleiste verwendet: dieser Filter. In vielen Fällen werden Themen dank sehr aufmerksamer und hilfsbereiter Mitglieder, die Fragen beantworten, tatsächlich recht schnell gelöst.

Manchmal ist jedoch ein kleiner Anstoß nach ein oder zwei Wochen nötig, um bei der fragenden Person nachzufragen, ob ihr Problem bereits gelöst ist, und um klärende Fragen zu stellen, die ihnen weiterhelfen könnten (Welche Schritte führen zur Reproduktion? Habt ihr die offiziellen Installationsanweisungen verwendet? Funktioniert es im abgesicherten Modus? usw.). Wenn ich das tue, füge ich in der Regel einen Zeitgeber für das Thema hinzu, der es automatisch 30 Tage nach der letzten Antwort schließt. Wenn die Person oder ein anderes Mitglied der Community innerhalb von 30 Tagen nicht antwortet, halte ich es für 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, was ich ebenfalls tue. Zum Beispiel:
→ Community Building = offene Fragen zur Gemeinschaftsbildung
→ Development = Anpassungen, Erstellung neuer Plugins usw.
→ Contribute > Feature oder Contribute > UX = Feature-Wünsche oder Verbesserungen/Behandlungen der Benutzeroberfläche
→ Contribute > Bug = Fehlerberichte

Indem ich Themen in Support automatisch nach einem Monat schließe, anstatt dies manuell zu tun, spare ich mir etwas Zeit, da das derzeitige manuelle Schließen mit dem Admin-Schlüssel etwas umständlich ist. Es sind mehrere Klicks nötig!

Ich werde in etwa einem Monat wieder nachhaken, um zu entscheiden, ob wir diese Einstellung beibehalten oder ob ein anderer Ansatz besser funktionieren könnte.

[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! Vielen Dank für alle Antworten hier. Ich bin froh, dass ich dieses Thema aufgeworfen habe, um zu erfahren, wie die Leute dazu stehen.

Ich könnte mich da irren, aber mein eigenes Gefühl aus den letzten Monaten war, dass die Kategorie Support sich von den anderen aktuellen Kategorien unterscheidet. Die Leute kommen hierher, um ein Problem sofort zu lösen, und fast immer ist das Problem sehr spezifisch für ihre eigene Situation. Wenn das Thema nicht relativ schnell gelöst wird, verlieren sie das Interesse und gehen weiter oder werden ungeduldig und fragen in anderen Themen erneut nach. In der Zwischenzeit kann die Support-Kategorie mit unbeantworteten Fragen zugemüllt werden. Andere spätere Reisende schieben diese dann nach oben, um ihre eigenen, leicht abweichenden Fragen zu stellen, die besser in einem neuen Thema aufgehoben wären.

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

Egal wie also Themen in Support, die unbeantwortet bleiben oder deren Diskussion verkümmert, müssen nachverfolgt werden, damit sie schließlich gelöst werden können. Ich denke, eine Antwort nach ein oder zwei Wochen hinzuzufügen und sie dann 30 Tage nach der letzten Antwort zum Schließen vorzusehen, scheint ein vernünftiger Weg zu sein, um sicherzustellen, dass das passiert.

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

Also schalte ich die automatische Einstellung vorerst aus, füge den Timer aber weiterhin in Fällen hinzu, in denen ich denke, dass er sinnvoll ist. Wenn Sie bemerken, dass ich einen Timer auf einem Thema gesetzt habe, bei dem Sie der Meinung sind, dass ich das nicht tun sollte, lassen Sie es mich wissen und begründen Sie dies.

[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]

Vielen Dank! Es ist behoben. Es ist in Stunden angegeben, nicht in Tagen oder Monaten, also musste ich den Taschenrechner zurate ziehen. 720 Stunden!

Edit: Außerdem ist mir gerade eingefallen, dass ich das Protokoll der Mitarbeiteraktionen einsehen kann. Es hat zwar aufgezeichnet, dass ich die 720 entfernt habe, als ich den automatischen Schließ-Timer hinzugefügt habe. Aber dass es mich beim Speichern der Änderungen nicht in der Benutzeroberfläche gewarnt hat, ist etwas seltsam. Ich habe dieses Problem in einem #contribute:ux-Thema aufgegriffen.

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