In den letzten Monaten haben wir beobachtet, wie Discourse Verbesserungen und neue Funktionen im Admin-Panel implementiert hat. Wie bei allen größeren Änderungen hat dies sowohl positives als auch negatives Feedback hervorgerufen.
Ich denke, wir alle schätzen das UI/UX der neuen Oberfläche, und falls wir Unstimmigkeiten feststellen, liegt es daran, dass wir unsere Foren unterschiedlich nutzen.
Ich bin gerade dabei, meine Community neu zu starten, und während ich die verschiedenen Optionen in meinem Admin-Panel analysiere, stelle ich fest, dass ich einen „Sub-Admin“ brauche, der auf bestimmte Funktionen zugreifen sollte – aber nicht auf die gesamte Palette, die unter /admin angeboten wird.
Moderatoren und TL3/TL4 kümmern sich um Inhalte und die Community. Die Werkzeuge, die dieser „Sub-Admin“ zur Verfügung hätte, sind breiter gefasst und wirken sich auf das interne Management von Discourse aus.
Diese Liste ist ein kurzer Entwurf und nicht erschöpfend. Sie soll einen allgemeinen Überblick darüber geben, was besprochen werden muss.
Erlaubte Sub-Admin-Berechtigungen:
- Zugriff auf Sentiment-/Emotionsmodelle.
- Aktualisierung von Übersetzungen (Texten) für benutzerdefinierte Übersetzungen, die besser zum Slang der Community passen.
- Benutzer, Gruppen, Abzeichen, kommende Funktionen.
- Permalinks, spezielle Wörter, Embeds.
- Statistiken, Moderation, Überprüfung und andere Funktionen, die der Seite keinen Schaden zufügen würden, wenn sie von einem vertrauenswürdigen Sub-Admin verwaltet werden.
- Plugin-Konfiguration (ggf. wählbar aus einer Liste, um die empfindlichsten zu vermeiden).
Berechtigungen, die dem „Sub-Admin“ NICHT gewährt werden:
- Zugriff auf alle Verwaltungsoptionen.
- Aktualisierung der Discourse-Instanz.
- Hinzufügen oder Entfernen von Theme-Komponenten.
- Zugriff auf bestimmte Einstellungen im Zusammenhang mit E-Mails, Sicherheit, Benutzeranmeldung usw.
- Zugriff auf API-Schlüssel, Webhooks und andere sensible Website-Informationen.
Diese neue, bereichsbezogene Berechtigung im Admin-Bereich sollte mit zwei separaten Admin-Panelen verknüpft sein, basierend auf den Funktionen, die jede Administratorgruppe bereitstellt.
Wir hätten also einerseits (i) ein technisches Dashboard und andererseits (ii) ein funktionales Dashboard, das auf PMs, CMs und ähnliche Rollen in verschiedenen Organisationen anwendbar ist, nach deren Ermessen.
Das aktuelle modulare Design des Admin-Panel würde es den Hauptadministratoren ermöglichen, zwischen den verschiedenen Optionen zu wählen, falls sie auch auf dem Laufenden bleiben wollen, was auf der funktionalen Ebene im Community-Management geschieht.
Ich weiß, dass dies Zeit in Anspruch nehmen könnte und es möglicherweise nicht etwas ist, das das Team sofort angehen möchte, aber ich denke, es wäre großartig, dies mit der Meta-Community zu besprechen, damit sie unsere Gedanken dazu lesen können.
In meinem besonderen Fall, in einer Nischen-Community, die über keine Organisationsstruktur verfügt (abgesehen von dem, was sich natürlich ergibt), bin ich derzeit nicht in der Lage, bestimmte Zugriffsrechte zu erteilen, da die Übergabe des gesamten Admin-Panel für das, was wir derzeit tun, nicht von Vorteil wäre.
Das hält mich buchstäblich an der gesamten Verwaltung von Discourse fest, obwohl ich einen großen Teil der Aufgaben an das natürlich entstandene Team delegieren könnte – da es sich um Personen handelt, denen ich vertraue –, aber sie haben noch nicht die notwendige Erfahrung, damit ich einfach delegieren oder Zugriff auf alles erlauben kann.
Eure Gedanken dazu?