Aktualisierung der Kategorienorganisation auf Meta

[mcwumbly (Dave McClure)]

Im Rahmen des Updates des Themas und der Struktur von Meta planen wir einige Änderungen an der Organisation der Kategorien hier vorzunehmen.

Wir haben bisher einige verschiedene Ideen geprüft, und wir erwarten, dass dies noch einige zusätzliche Überarbeitungen durchlaufen wird, während wir Feedback von der Community einholen. Die Idee, zu der wir derzeit tendieren, ist unten dargestellt:

Die Grundidee besteht darin, zusammengehörige Kategorien in einer kleineren Anzahl von Top-Level-Kategorien zu gruppieren, von denen jede standardmäßig in der Seitenleiste für neue Benutzer angezeigt wird.

• Nachrichten und Veranstaltungen (News and Events)
• Support
• Community-Erfolg (Community Success)
• Beitrag leisten (Contribute)
• Anpassung (Customization)
• Dokumentation (Documentation)
• Community-Wiki (Community wiki)
• Marktplatz (Marketplace)

Wir erwarten, dass Support weiterhin eine der aktivsten Kategorien sein wird, und denken, dass es die Auswahlparalyse verringern könnte, andere Support-bezogene Kategorien darunter zusammenzufassen. Wahrscheinlich gibt es hier noch weitere Verfeinerungen vorzunehmen (sollte SSO eine Kategorie oder ein Tag sein? Was ist der praktische Unterschied zwischen Installation und Hosting? Sollten diese in einer einzigen Unterkategorie für Selbst-Hosting zusammengefasst werden?). Wir werden diese Fragen im Laufe der Zeit klären, aber die allgemeine Struktur sieht vor, alle Support-Themen an einem Ort zu bündeln.

Community-Erfolg ist eine Kategorie, in die wir gerne mehr investieren möchten, aufbauend auf der bestehenden Community-Kategorie. Wir sehen dies als einen Ort, an dem jeder, der an der Leitung einer erfolgreichen Discourse-Community beteiligt ist, sich gegenseitig unterstützen kann, nicht mit technischem Support, sondern mit den unübersichtlichen weichen Aspekten dessen, was es braucht, um eine erfolgreiche Community aufzubauen. Wir werden wahrscheinlich auch die zugrunde liegende Struktur hier neu gestalten, aber für den Anfang denken wir, dass die bestehenden Kategorien Community sowie Daten und Berichterstattung (Data and Reporting) die Hauptpfeiler hier sind.

Beitrag leisten (Contribute) ist die Kategorie, die wir uns als Zentrum für Diskussionen darüber vorstellen, wie das Produkt selbst und diese Community verbessert werden können.

Anpassung (Customization) wäre ein Ort, um alle Themen zu finden, die sich auf die Erweiterung von Discourse mit Plugins, Themes, Komponenten und anderen Erweiterungen beziehen.

Wenn Sie einen genaueren Blick darauf werfen möchten, haben wir diese Struktur derzeit auf einer Staging-Site implementiert, wo Sie sich umsehen können.

Zugriff auf die Staging-Site

1. Besuchen Sie https://meta-redesign-2026.discourse.group/
2. Geben Sie diesen Benutzer und dieses Passwort für die HTTP-Basisauthentifizierung ein
   • Benutzer: meta2026bsbx
   • Passwort: Q0U1ppbVbd2MVttuYOl+M8SYEOUqGLGjzl5sr1C9XwE=
3. Geben Sie Ihre E-Mail/Ihren Benutzernamen und Ihr Passwort für Meta ein
   (die Staging-Site unterstützt keine anderen Anmeldemethoden).

Nachdem Sie Gelegenheit dazu hatten, teilen Sie uns bitte hier mit, was Sie davon halten.

[pfaffman (Jay Pfaffman)]

Ich denke, eine Kategorie wie „Self-Hosting“ würde helfen, klarzustellen, was dorthin gehört. Es ist immer noch kein großartiger Name, aber besser als Installation, was impliziert, dass Discourse noch nie funktioniert hat; ich war ziemlich verwirrt, als eines meiner Themen dorthin verschoben wurde. Vielleicht würde „Backend“ funktionieren?

Wenn Sie auf eine Shell zugreifen, um Ihr Problem zu verursachen oder zu beobachten, gehört es dorthin. Wenn Discourse „funktioniert“ und es um UX oder Themes oder irgendetwas anderes geht, gehört es zu Support.

[mcwumbly (Dave McClure)]

@pfaffman

Ich denke, eine Kategorie namens Self-Hosting würde helfen, klarzustellen, was dorthin gehört. Es ist immer noch kein großartiger Name, aber besser als Installation,

Ich bin dafür.

Ich würde sogar so weit gehen zu sagen, dass wir Installation und Installation > Hosting in dieser neuen Kategorie „Self-Hosting“ zusammenfassen sollten.

Ich denke, das könnten wir unabhängig davon tun, wie sich der Rest entwickelt. Wenn wir in die von mir oben skizzierte Richtung gehen, wäre diese neue Kategorie eine Unterkategorie von Support.

Wenn wir uns enger an das aktuelle flache Modell halten, wäre es eine Kategorie der obersten Ebene.

[mcwumbly (Dave McClure)]

Ich habe gerade die folgende Änderung vorgenommen, die zu einer neuen Top-Level-Kategorie #self-hosting-support geführt hat:

• Alle Themen, die sich zuvor unter Installation > Hosting befanden, wurden mit dem Tag #hosting versehen
• Alle Themen von Installation > Hosting wurden mit dem zusammengeführt, was früher Installation war
• Installation wurde in #self-hosting-support umbenannt

Vielleicht ist „Self-hosting“ besser als „Self-hosting support“ (besonders wenn wir es unter Support verschieben), aber als ersten Schritt habe ich mich für etwas etwas ausführlicheres entschieden, das das Wort „support“ enthält.

[JammyDodger]

FWIW habe ich „Self-Hosting-Support“ bisher vermieden, da es den Anschein erweckte, dass dies der Bereich speziell für Self-Hoster sei, um jegliche Unterstützung zu erhalten, und ich dies nicht als ersten Eindruck vermitteln wollte.

Es ist auch der Dokumentationskategorie sehr ähnlich, und man möchte keine Duplizierung, wenn man vereinfachen möchte.

Konfiguration wurde ebenfalls verworfen, da alle Funktionen/Einstellungen/Plugins/usw. „konfiguriert“ werden müssen, war also nicht aussagekräftig genug. Systemadministration wurde als zu technisch erachtet (da wir herunterspielen wollten, wie technisch man sein muss, um eine Discourse-Seite zu betreiben).

Obwohl ich zustimme, dass Installation mehrdeutig war, verursachte es in der Praxis nicht allzu viele Verwirrungen. Ein besserer Name existiert jedoch…

Bei Hosting ging es darum, die zugrunde liegenden Dienste (Digital Ocean, Mailgun, usw., usw.) zu besprechen. Ich denke, es hatte eine deutliche Note, die sich von der Serveradministration unterschied, und bei über 500 Themen wäre es sinnvoll, eine Unterhaltung auszulagern (wenn sie nicht schon existiert hätte ).

[stephtara (Stephanie Booth)]

Für mich würde ich erwarten:

• Hosting: über die Auswahl und Verwaltung des Hosts (Servers)
• Installation: bis zu dem Punkt, an dem „Discourse existiert und ich mich als Administrator anmelden und Dinge tun kann“
• Konfiguration: all die Feinheiten bezüglich der verschiedenen Einstellungen

Ich denke, für jemanden, der anfängt, ist die Unterscheidung zwischen Core und „mitgeliefertem Plugin“ nicht sehr offensichtlich. Daher würde ich diese in die Konfiguration aufnehmen – oder zumindest sehr klare Hinweise geben.

[mcwumbly (Dave McClure)]

@stephtara

Für mich würde ich Folgendes erwarten:

• Hosting: Auswahl und Verwaltung des Hosts (Servers)
• Installation: Erreichen des Zustands „Discourse existiert und ich kann mich als Administrator anmelden und Dinge tun“
• Konfiguration: all die Feinheiten bezüglich der verschiedenen Einstellungen

Welche davon würden Sie als unterschiedliche Kategorien im Gegensatz zu unterschiedlichen Tags erwarten?

Und wie würden Sie erwarten, dass diese sich auf die Kategorie Support beziehen?

[stephtara (Stephanie Booth)]

@mcwumbly

Welche dieser Kategorien würden Sie eher als unterschiedliche Kategorien oder als unterschiedliche Tags erwarten?

Also, ich denke, Installation und Hosting wären für mich in Ordnung als Tags. Aber ich frage mich (auch für meine Community), ob es eine Möglichkeit gibt, bestimmte Schlüssel-Tags in einer Kategorie „anzupinnen“ oder „hervorzuheben“. Es könnten auch Kategorien sein (wenn wir in Richtung „die Geschichte erzählen“ denken).

Konfiguration: Wird das für Self-Hosters oder gehostete Administratoren sehr unterschiedlich sein? Ich habe den Eindruck, dass es sich überschneiden wird, daher bin ich mir nicht sicher, ob ich es in Self-hosting einsperren würde (was ich eher umbenennen würde als Self-hosting Support). Vielleicht ist Support eher wie „Allgemeiner Support“? Denn fast alles in Meta ist in irgendeiner Weise Support, nicht wahr?

Übrigens: Migration ist für mich verwirrend, weil ich als „People First“-Mensch sofort denke: „Oh, wie manage ich die Migration als Ganzes“, und wenn ich mir die Kategorie ansehe, scheint es nur um „technische Migration“, Skripte und Exporte und so etwas zu gehen.

Wir hatten kürzlich einige Gespräche über facebook-migration, bei denen es mehr um Strategie, Menschen und spezifische Herausforderungen ging. Auf eine Weise habe ich das Gefühl, dass Migration als böser Anziehungspunkt für Leute wirken könnte, die sich um die allgemeineren oder menschlichen Aspekte der Migration kümmern. Verstehen Sie, was ich meine?

[mcwumbly (Dave McClure)]

@stephtara

Ich frage mich (auch für meine Community), ob es eine Möglichkeit gibt, bestimmte Schlüssel-Tags in einer Kategorie „anzupinnen“ oder „hervorzuheben“. Es könnten auch Kategorien sein (wenn wir in Richtung „die Geschichte erzählen“ denken).

Eine größere Möglichkeit dafür in der App zu haben, ist etwas, das es wert sein könnte, erkundet zu werden, aber ich bin mir nicht sicher, wie es funktionieren sollte.

Im Moment denke ich, dass dies sehr organisch geschieht – eine kritische Masse bestimmter Tags sammelt sich in einer bestimmten Kategorie an, und die Leute beginnen, das Muster zu sehen und ermutigen es, sich zu verbreiten.

Es gibt eingebaute Funktionen, um Tags auf bestimmte Kategorien zu beschränken oder eine Anzahl von Tags in einer bestimmten Kategorie zu verlangen, insbesondere von einer bestimmten Tag-Gruppe, aber ich habe das Gefühl, dass sie oft zu mühsam sein können.

@stephtara

Konfiguration: wird dies für Self-Hosters oder gehostete Administratoren sehr unterschiedlich sein? Ich habe den Eindruck, dass es sich überschneiden wird, daher bin ich mir nicht sicher, ob ich es in Self-hosting einsperren würde

stimme zu. Ich denke bei Konfiguration eher an „allgemeine Unterstützung“ (es sei denn, es geht um die Konfiguration von Dingen auf Sysadmin-Ebene, wie dem Port, auf dem man lauscht, usw.).

@stephtara

Self-hosting (was ich eher so umbenennen würde als Self-hosting Support

Ja, das hatte ich zuerst auch im Sinn … Ich lasse es einen Tag ruhen, werde mir dieses Detail aber morgen noch einmal ansehen.

@stephtara

Vielleicht ist Support eher wie „Allgemeiner Support“? Weil fast alles in Meta in irgendeiner Weise Support ist, oder?

Das stimmt, aber ich bin mir nicht sicher, wie sehr dieses zusätzliche Wort hilft. Ich verstehe, was du meinst, aber.

@stephtara

Migration ist für mich verwirrend, weil ich als „People First“-Person sofort denke: „Oh, wie verwalte ich die Migration als Ganzes“, und wenn ich mir die Kategorie ansehe, scheint es nur um „technische Migration“, Skripte und Exporte und so etwas zu gehen.

Ja, es ist möglich, dass sich hier zwei Kategorien verstecken. Wenn wir dies durch die Linse der vorgeschlagenen verschachtelten Struktur betrachten würden, sollte dies vielleicht in etwas wie support/migration und etwas wie dev/migration aufgeteilt werden.

Ich könnte mir vorstellen, dass wir das im Laufe der Zeit stärker gestalten, während wir hier zunächst einen kleineren Schritt machen.

[stephtara (Stephanie Booth)]

@mcwumbly

Ich denke, dass dies im Moment sehr organisch geschieht – eine kritische Masse bestimmter Tags sammelt sich in einer bestimmten Kategorie an, und die Leute beginnen, das Muster zu erkennen und ermutigen es, sich zu entfalten.

Ich verstehe, was Sie meinen – obwohl die Tatsache, dass sie in einem Dropdown-Menü versteckt sind, sie viel weniger sichtbar macht als Unterkategorien, die man prominent anzeigen kann.

@mcwumbly

Es gibt eingebaute Funktionen, um Tags auf bestimmte Kategorien zu beschränken oder eine bestimmte Anzahl von Tags in einer bestimmten Kategorie zu verlangen, insbesondere aus einer bestimmten Tag-Gruppe, aber ich habe das Gefühl, dass diese oft zu mühsam sein können.

Dazu komme ich später noch einmal, denn das ist etwas, was ich ziemlich ausgiebig nutzen möchte (mindestens ein Tag aus einer bestimmten Tag-Gruppe in einer bestimmten Kategorie zu verlangen), um die Vervielfachung von Unterkategorien zu vermeiden…

@mcwumbly

Ich betrachte Konfiguration eher als „allgemeine Unterstützung“

Ich denke, ein Teil davon ist das, aber ein anderer Teil ist die Fortsetzung der „Installation“, all das Setup-Zeug. Nun, ich habe Discourse installiert, es verfügt über all diese unglaublich coolen Funktionalitäten, ich habe die Kontrolle über so viele Dinge, aber wie „forme“ ich es nach den Bedürfnissen meiner Community? Dieser Teil hat mich vor einiger Zeit extrem entmutigt, denn obwohl alle Einstellungen und so dokumentiert sind, hatte ich Schwierigkeiten a) zu verstehen, wo ich anfangen soll, und b) zu verstehen, wie ich meine „Vision“ für meine Community in Einstellungen und Konfiguration umsetzen kann.

Vielleicht denke ich also an eine zusätzliche Ebene rund um den Weg der ersten Konfiguration. Ich sehe Support (ich würde es nicht in „Allgemeine Unterstützung“ umbenennen, ich habe das nur gesagt, um meine Wahrnehmung zu verdeutlichen) eher für „Ich bin startklar, oder ich habe ein spezifisches Problem, das ich lösen muss“, anstatt für „Ich habe meine Standardinstallation und was muss ich jetzt tun, um sie für eine Art Launch vorzubereiten“.

All das soll heißen, ich denke tatsächlich, dass „Konfiguration“ im Rahmen der Admin-Reise sinnvoll ist und nicht genau dasselbe wie „Support“.

Eine Parallele zu meiner Community – erinnert mich daran, dass ich in der richtigen Diskussion Neuigkeiten dazu geben muss – ist folgende: Angenommen, der Besitzer einer diabetischen Katze, die gerade eine Diagnose erhalten hat und unserer Community beitritt, wie organisieren wir Kategorien? Was ich jetzt entschieden habe, ist, sehr „mitgliedszentriert“ zu sein und mit „Ich bin gerade angekommen, was zum Teufel“ (ein höflicheres französisches Äquivalent) zu beginnen, dann „Ich besorge mir die nötige Ausrüstung“, „Ich lerne“ – und dann sind sie bereit für den eigentlichen „Support“, der das Herzstück der Community ist.

Wenn ich in dieser Hinsicht mit Discourse denke, als jemand, der völlig neu in all dem ist, wie ich es war, gibt es definitiv: 1) herauszufinden, ob ich selbst hosten werde oder nicht, und mein Hosting auszuwählen; 2) die eigentliche Installation durchzuführen; 3) meine Community zu gestalten und das in die Discourse-Konfiguration zu übersetzen. Und in diesem Fall muss zwischen a) ich baue von Grund auf neu und b) die Community existiert und ich möchte sie migrieren – wie in meinem Thema zu den Herausforderungen bei der Facebook-Migration besprochen, denke ich wirklich, dass sich der Ansatz zur Einrichtung ändert.

Was uns zu der Frage bringt, wo die Migrationsinhalte platziert werden sollen.

@mcwumbly

Ja, es ist möglich, dass sich hier zwei Kategorien verstecken. Wenn wir dies durch die Linse der vorgeschlagenen verschachtelten Struktur betrachten würden, sollte dies vielleicht in etwas wie support/migration und etwas wie dev/migration aufgeteilt werden.

Ich würde sagen, auch hier kommt es darauf an, welche Geschichte wir erzählen wollen. Möchte Discourse die Migration bestehender Communities zu Discourse fördern und erleichtern, oder liegt der Fokus mehr auf Leuten, die mit Discourse von Grund auf neu aufbauen werden?

Keine Überraschung, ich würde argumentieren, dass es sinnvoll ist, sich auf die Migration von Kunden zu konzentrieren, da ich überzeugt bin, dass es dort einen riesigen unerschlossenen Markt gibt.

In diesem Fall möchte ich, dass „Migration“ nicht zu tief vergraben ist. Ich würde es persönlich als einen Aspekt des Community Managements beibehalten (und die aktuelle Community-Kategorie umbenennen, weil „Community“ allein mehrdeutig ist; ich dachte zuerst, es ginge um „die Discourse-Community“ und nicht um „die Gestaltung/den Aufbau/die Verwaltung von Communities“). Tag oder Unterkategorie? Würde es zumindest eine Unterkategorie verdienen. Würden Migrationsskripte und technisches Zeug rund um die Migration in eine andere übergeordnete Kategorie gehören?

Oder vielleicht ist Migration eine eigene Kategorie, die Diskussionen darüber enthält, wie man bestehende Aspekte der Community an Discourse anpasst und übersetzt, wie man den eigentlichen Migrationsprozess angeht (Implementierung) und auch die „Datenmigration“.

[pfaffman (Jay Pfaffman)]

Warten Sie. Was wäre, wenn es eine Möglichkeit gäbe, Benutzer dazu zu ermutigen, Themen mit #standard-install zu kennzeichnen, so wie wir es mit unsupported-install tun?

Ich bin mir allerdings nicht ganz sicher, wie ich das bewerkstelligen soll.

[mcwumbly (Dave McClure)]

@stephtara

Ich persönlich würde es als einen Aspekt des Community Managements beibehalten (und die aktuelle Kategorie „Community“ umbenennen, da „Community“ allein mehrdeutig ist; ich dachte zunächst, es ginge um „die Discourse-Community“ und nicht um „das Entwerfen/Bauen/Managen von Communities“).

Im aktuellen Vorschlag stellen wir uns „Community Success“ als die oberste Kategorie vor, wobei „Community Management“ eine Unterkategorie davon ist – wie passt das zu Ihrer Überlegung hier?

@mcwumbly

---

@stephtara

Was ich im Sinn habe, ist eine zusätzliche Ebene um die Reise der ersten Konfiguration herum. Ich sehe Support (ich würde es nicht „Allgemeiner Support“ umbenennen, ich habe das nur gesagt, um zu verdeutlichen, wie ich es wahrgenommen habe) eher für „Ich bin einsatzbereit, oder ich habe ein spezifisches Problem, das gelöst werden muss“, anstatt für „Ich habe meine Standardinstallation und was muss ich jetzt tun, um sie für eine Art Launch vorzubereiten“.

Mir gefällt die Idee, eine Art Wegweiser zu definieren, der unser Verständnis davon widerspiegelt, wie die typischen Schritte dieser Reise aussehen könnten …

[stephtara (Stephanie Booth)]

@mcwumbly

Im aktuellen Vorschlag stellen wir uns „Community Success“ als oberste Kategorie vor, wobei „Community Management“ eine Unterkategorie davon ist – wie passt das zu Ihren Überlegungen hier?

Ich verstehe den Unterschied zwischen diesen beiden nicht. Was würde unter Community Success fallen, das nicht unter Community Management fällt? Wenn ich über die Dinge nachdenke, die ich bisher hier in Community gepostet habe, packe ich sie in Community Management oder Success?

Ich muss morgen oder Freitag darüber nachdenken, mein Gehirn meldet sich für heute ab, sorry!

[mcwumbly (Dave McClure)]

@stephtara

Was würde in Community Success fallen, das nicht in Community Management fällt?

Nun, abgesehen von den Unterkategorien, die Sie in der dortigen Skizze sehen, haben Sie neben dem Verwalten von Communities (dem Entwerfen und Erstellen davon) zwei weitere Aktivitäten erwähnt:

@stephtara

anstatt „über das Entwerfen/Erstellen/Verwalten von Communities“

Aber vielleicht fällt das für die meisten Leute immer noch alles unter „Management“.

[hellekin]

@mcwumbly

wie man auf die Staging-Site zugreift

Klicken zum Öffnen

One-Click-Staging-Site inklusive Anmeldedaten

→ Wird ausgeblendet, falls Sie nicht möchten, dass Roboter dorthin gelangen.

Hier wäre meine Neuordnung der Kategorien:

• Neuigkeiten & Veranstaltungen
  • Ankündigungen
  • Blog
  • Zusammenfassungen
• Community
  • Agora (war: Allgemein)
  • Seitenfeedback
  • Lob
  • Vergleich
  • Community Management
  • Marktplatz
  • Benutzer-Wiki
  • Admin-Wiki
  • Entwickler-Wiki
  • Sysadmin-Wiki
• Dokumentation
  • Discourse verwenden
  • Seitenverwaltung
  • Integrationen
  • Discourse-Hosting (war: Gehostete Kunden)
  • Self-Hosting
  • Migration zu Discourse
  • Entwicklerhandbücher
  • Mitwirken
• Hilfe
  • Installation
  • Hosting
  • Migration
• Integrieren
  • WordPress
  • SSO
• Mitwirken
  • Fehler
  • Funktion
  • Entwicklung
  • Übersetzungen
  • UX
• Anpassen
  • Plugin
  • Extras
  • Thema
  • Themenkomponente
  • Daten & Berichterstattung

Begründung:

• Community wäre der lebhafte Ort für Diskussionen zu allem, was nirgendwo anders hingehört, und bringt die größere Discourse-Community zusammen, einschließlich Wikis, allgemeine Diskussionen (#agora), Seitenfeedback, Lob und Vergleiche mit anderer Software, aber auch Diskussionen über Community-Management und den Marktplatz.
• #news-events wäre für die normale CDCK-Kommunikation
• #help wäre, um Unterstützung zu erhalten
• #integrate wäre, um spezifische Integrationen zu diskutieren
• Documentation würde die offizielle Wissensdatenbank beherbergen
• #contribute würde den gesamten Entwicklungsprozess beherbergen
• #customize würde alles beherbergen, was jede Discourse-Instanz zu einer besonderen Community macht, einschließlich Datenberichterstattung und -erkundung.

Wenn jemand Neues kommt, würde er entweder zur (offiziellen) Dokumentation oder zu den Community-Diskussionen gehen…

[manuel (Manuel Kostka)]

@hellekin

Ich würde ein #welcome-Tag vorschlagen, das auf eine Handvoll Einführungsthemen verweist, um neuen Benutzern die Navigation und das Onboarding zu erleichtern, z. B. für den Übergang von tl0 zu tl1, um die Stimmung und die Bereiche zu erfassen.

Ja, das habe ich schon einmal in einer Community gemacht, und ich denke auch, dass es eine nette und flexible Möglichkeit ist, einen Onboarding-Pfad anzuzeigen, abgesehen von der Verwendung einer Kategorie. So etwas wie

[philh]

Ich begrüße diese Initiative und freue mich, dass wir in den Prozess einbezogen werden.

Nachdem ich die Discourse-Entwicklung von @stephtara verfolgt habe, ist mir klar, dass Meta einen dedizierten Ort für neue Community-Aufbauer benötigt. Ich habe keine Ahnung, wie man ihn nennen soll, aber ein warmer und gemütlicher Ort für diejenigen, die zum ersten Mal mit Discourse aufbauen, würde helfen, die Überforderung durch die Fülle an Konfigurationsoptionen zu verringern. Leute, die hier Hilfe anbieten, wüssten, dass zusätzliche Anstrengungen und Geduld erforderlich sein könnten, um mit Hilfe in diesem Bereich zu antworten.

Vielleicht habe ich es übersehen, aber eine Dokumentationskategorie für Konfigurationsoptionen mit einem Index, der den „aktuellen“ Admin-Bereich widerspiegelt, wäre großartig. Discourse entwickelt sich ständig weiter. Die Dokumentation sollte dasselbe tun, indem sie Schritt hält.

Zusätzlich zu dieser Kategorie-/Tag-Überarbeitung hoffe ich, dass nach der Reorganisation eine „frische Sortierung“ der bestehenden Themen folgen wird. Die meiste Zeit, die ich auf Meta mit der Suche nach Antworten verbringe, verbringe ich damit, herauszufinden, welche Informationen für den aktuellen Status von Discourse relevant sind und welche alt und nicht mehr anwendbar sind. Ich gebe zu, dass mein BBS Teil des Problems ist, aber viele der Dokumentationen sind sehr schwer zu sortieren. Ich weiß die Arbeit zu schätzen, die die Mitarbeiter geleistet haben und immer noch leisten, um die Dokumentation zu verbessern, aber viele/die meisten scheinen überarbeitungsbedürftig zu sein.
Zu diesem Zweck schlage ich vor, die meisten Dokumente oder Themen, die Dokumente zu sein scheinen, mit einem Tag „Überprüfung erforderlich“ (Needs Review) zu versehen. Ja, das wären sehr viele Tags, aber sobald der Überprüfungsprozess abgeschlossen ist, würde sich die Benutzererfahrung enorm verbessern. Ich und vielleicht auch andere wären bereit, bei dieser Anstrengung zu helfen. Eine Bearbeitungs-Tagging-Sequenz könnte helfen, den Prozess zu verwalten.

Ich verwende dies auf einer Seite:

Zusammenfassung

Überprüfung-erforderlich Text-erforderlich Zitat-erforderlich Arbeit-erforderlich Veröffentlichungsbereit

Vielleicht wäre ein Tag „Veraltet“ (Out of Date) hilfreich.

@mcwumbly Nochmals vielen Dank für die Initiierung dieser Reorganisation und dafür, dass wir in den Prozess einbezogen wurden.

[mcwumbly (Dave McClure)]

Hier ist mein Plan für die nächsten Schritte:

• Woche vom 23. Februar
  • Die Kategorieorganisation hier aktualisieren, um sie an den ersten Beitrag anzupassen, eventuell mit einigen kleinen Freiheiten basierend auf dem bisherigen Feedback
  • Erwarten Sie hier noch viel mehr Diskussionsfeedback darüber, wie es sich in der Praxis anfühlt
  • Kleinere Anpassungen basierend auf dem Feedback vornehmen
• Woche vom 2. März
  • Weiter verfeinern, wenn sich die Dinge im Allgemeinen gut anfühlen. ODER
  • Zurücksetzen, wenn sich die Dinge stark falsch anfühlen

[mcwumbly (Dave McClure)]

Diese Idee halte ich hier fest:

@stephtara

Ich persönlich denke, es wäre wirklich schön, einen Bereich „pro Sprache“ oder zumindest ein Tag für Übersetzungen zu haben, die sich auf eine bestimmte Sprache beziehen.

Es verdient wahrscheinlich ein eigenes Thema, aber wir können dies zunächst hier als Teil dieser größeren Umstrukturierung diskutieren.

[mcwumbly (Dave McClure)]

@mcwumbly

• Woche vom 23. Feb.
  • Aktualisieren Sie die Kategorieorganisation hier, um sie an die im ersten Beitrag genannten anzugleichen, wobei Sie möglicherweise einige kleine Freiheiten basierend auf dem bisherigen Feedback nehmen.
  • Erwarten Sie hier noch viel mehr Diskussionsfeedback darüber, wie es sich in der Praxis anfühlt.
  • Nehmen Sie einige kleine Anpassungen basierend auf dem Feedback vor.

Ich habe bereits eine erste Runde von Änderungen vorgenommen, damit wir gemeinsam ein Gefühl dafür bekommen können, wie es sich in der Praxis anfühlt.

Ich habe auch die Standard-Seitenleistenkategorien aktualisiert, sie aber noch nicht für alle angewendet. Wenn Sie also versuchen möchten, Ihre Seitenleiste auf die neuen Standardeinstellungen umzustellen, können Sie dies tun:

1. Klicken Sie in Ihrer Seitenleiste auf den Bearbeitungsstift neben „Kategorien“
2. Wählen Sie unten rechts im Modal „Auf Standardeinstellungen zurücksetzen“
3. Passen Sie nach Wunsch an
4. Klicken Sie auf „Änderungen speichern“

Bitte teilen Sie uns in der kommenden Woche oder so Ihr Feedback hier mit:

@mcwumbly

• Woche vom 2. März
  • Weiter verfeinern, wenn sich die Dinge im Allgemeinen gut anfühlen. ODER
  • Zurücksetzen, wenn sich die Dinge völlig falsch anfühlen