Kategorie-Tag-Regeln / -Beschränkungen auch für Moderatoren gelten lassen

[mattdm (Matthew Miller)]

Problem:

1. Wir haben Moderatoren, die auch sehr aktive Nutzer der Website sind.
2. Wir nutzen Tag-Gruppen und Tag-Anforderungen intensiv – dies ist grundlegend für die Struktur der Website. ^[1]
3. Moderatoren-Befugnisse sind immer aktiv, auch wenn jemand mit Moderatorstatus gerade postet.

Zusammenfassend lässt sich sagen, dass es leicht ist, versehentlich etwas zu vermasseln.

Anfrage

Bitte sorgen Sie dafür, dass Tag-Anforderungen für Kategorien auch für Moderatoren und Administratoren gelten. ^[2]

---

1. Siehe Navigating Fedora Discussion — Tags, Categories, and Concepts - Fedora Discussion, wie dies eingerichtet ist – und wir planen, Ask Fedora ebenfalls in die Website zu integrieren, was dies noch wichtiger macht. ↩︎

2. Mein Vorschlag für einen Sudo-ähnlichen Ansatz für Website-Berechtigungen stieß nicht auf viel Begeisterung, aber dies würde eines der größten Probleme abdecken! ↩︎

[mattdm (Matthew Miller)]

Ich schätze, eine andere Formulierung wäre: Bitte invertieren Sie den Sinn von diesem Test!

  test("Mitarbeiter umgehen Tag-Validierungsregel", async function (assert) {
    await visit("/");
    await click("#create-topic");

    await fillIn("#reply-title", "dies ist mein neuer Thema-Titel");
    await fillIn(".d-editor-input", "dies ist der *Inhalt* eines Beitrags");

    Category.findById(2).set("minimum_required_tags", 1);

    const categoryChooser = selectKit(".category-chooser");
    await categoryChooser.expand();
    await categoryChooser.selectRowByValue(2);

    await click("#reply-control button.create");
    assert.notStrictEqual(currentURL(), "/");
  });

[pfaffman (Jay Pfaffman)]

Ich stimme dem hier wirklich zu. Wenn Sie diese Regeln aufgestellt haben, möchten Sie sie wahrscheinlich wirklich. Ich habe sie auf einer Website, die nur ich benutze, und es ist wirklich ärgerlich, dass ich mich nicht darauf verlassen kann, dass Discourse mich an die von mir selbst aufgestellten Regeln hält, und es ist viel zusätzliches Tippen, um „todo“ auszuwählen und die Erstellung eines neuen „to“-Tags zu vermeiden.

Es würde mir gefallen, wenn Administratoren einfach gezwungen würden, die Regeln zu befolgen, aber wenn das nicht geht, wäre ein Modal „Sind Sie sicher, dass Sie die Regeln nicht befolgen möchten?“ schön.

Oder vielleicht eine Website-Einstellung „Mitarbeiter befolgen Tag-Regeln“. Das scheint ziemlich einfach zu sein.

[Jagster (Jakke Lehtonen)]

Für Moderatoren: +1
Für Administratoren: -1

Administratoren müssen die Fähigkeit haben, alles zu überschreiben. Und wenn man ein Administrator ist, geht man davon aus, dass er/sie/es/Bot weiß, was er/sie/es/Bot tun kann und was nicht.

[awesomerobot (Kris)]

@pfaffman

Es würde mir gefallen, wenn Administratoren einfach die Regeln befolgen müssten, aber falls das nicht geht, wäre ein Dialogfeld „Sind Sie sicher, dass Sie die Regeln nicht befolgen möchten?“ schön.

Ich denke, das ist ein guter Mittelweg, bei dem wir die Nutzung von Admin-/Mod-Befugnissen nicht erschweren… eine Art Warnung, die darlegt, was passiert… zum Beispiel:

#tag ist auf #category beschränkt. Sind Sie sicher, dass Sie Ihre Staff-Privilegien nutzen möchten, um dies in #different-category zu posten?

[mattdm (Matthew Miller)]

@Jagster

Admins müssen die Möglichkeit haben, alles zu überschreiben. Und wenn man ein Admin ist, geht man davon aus, dass er/sie/es/Bot weiß, was er/sie/es/Bot tun kann und was nicht.

Damit könnte ich leben – ich würde mein eigenes Konto zu einem Moderatorenkonto machen und ein sekundäres Admin-Konto erstellen.

@awesomerobot

Ich denke, das ist ein guter Mittelweg, bei dem wir die Verwendung von Admin-/Mod-Befugnissen nicht erschweren… eine Art Warnung, die umreißt, was passiert… zum Beispiel:

#tag ist auf #category beschränkt, sind Sie sicher, dass Sie Ihre Staff-Berechtigungen verwenden möchten, um dies in #different-category zu posten?

Ich stimme zu, dass dies besser wäre, aber es scheint, dass die Orte, an denen dies hinzugefügt würde, auch Orte wären, an denen "Regular mode" for admins and moderators (e.g. something like "sudo") noch besser wäre.

[jwheel (Justin Wheeler)]

Ich füge hier meine +1 hinzu, dass diese Funktion für große Communities mit dezentralen Ansätzen zur Governance über Tags hinweg nützlich ist.

Ich füge hier ein paar Ergänzungen hinzu zum letzten Thread:

@mattdm

Ich möchte nicht versehentlich beabsichtigte Tagging-Regeln verletzen können. (Können Nicht-Admin-Moderatoren dies auch versehentlich tun? Ich kann es nicht einmal leicht testen.)

@codinghorror

Ich verstehe die Bedenken, aber es ist in der Praxis kein großes Problem, zumindest nicht in den 10 Jahren, in denen ich an diesem Projekt gearbeitet habe.

@mattdm

Es hindert mich auch nicht daran, versehentlich selbst gesetzte Einschränkungen zu verletzen (wie die Tag-Regeln oder das Posten in Kategorien, die als Read-Only gelten sollen).

Dies ist eine Herausforderung für die Fedora Community, da sowohl die Führung als auch die Community eine offene Politik für die Verwaltung von Tags verfolgen. Jede registrierte Gruppe in Fedora kann neue Tags anfordern und Diskussionsmoderatoren für Tags zuweisen. Die Fedora-Führung arbeitet mit der Community zusammen, um neue Tags zu erstellen und sie in der gesamten Community zu bewerben (z. B. in Dokumentationen, Wikis, Websites, Mundpropaganda). Darüber hinaus haben wir als große Community, die eine breite Palette von Themen abdeckt, auch viele Tags! Ich kenne nicht immer jeden Tag in Fedora Discourse.

Wenn also ein Website-Administrator (der in unterschiedlichem Maße aktiv an Fedora Discourse teilnimmt) einem Beitrag Tags hinzufügt oder an einem Tag mit spezifischen Regeln teilnimmt, ist es für einen Fedora Discourse-Administrator ein leicht zu machender Fehler, Fedoras offene Richtlinien zu brechen. Die offenen Richtlinien sind der Weg, wie wir unsere globale Site-Governance integrativer und zugänglicher für die Community gestalten. Auf diese Weise können unsere Site-Admin-Berechtigungen unseren offenen Ansatz für die Art und Weise, wie die Fedora-Führung Fedora Discourse für die Community verwaltet, untergraben.

@Tris20

Haben Sie stattdessen in Erwägung gezogen, das Testkonto in einem Browser zu verwenden, den Sie nicht regelmäßig nutzen? Dann kann es einfach eingeloggt bleiben.

Während dies technisch funktioniert, ist es eine mühsame Aufgabe für einen Website-Administrator, der aktiv in mehreren Tags postet. Es ist eine negative Benutzererfahrung, da ich manchmal nicht viel Zeit zur Verfügung habe (z. B. in einer kurzen Pause zwischen Besprechungen mit Folgeaktionen). Geduld ist schwierig mit dem zusätzlichen Benutzerfluss, bevor ich zu dem komme, was ich ursprünglich tun wollte (d. h. einen neuen Thread über relevante Tags erstellen, von denen ich weiß, dass sie existieren und existieren könnten).

@Jagster

Admins müssen die Möglichkeit haben, alles zu überschreiben. Und wenn man Admin ist, ist die Grundannahme, dass er/sie/es/Bot weiß, was er/sie/es/Bot tun kann und was nicht.

Ich sehe diese Funktionsanfrage nicht als eine Einschränkung der Override-Fähigkeit eines Administrators. Stattdessen gibt sie einem Website-Administrator, der aktiv auf der Website postet, eine informierte Zustimmung, dass er während der Ausführung und nicht danach gegen Website-Regeln und Tagging-Normen verstößt.

[mattdm (Matthew Miller)]

Ich bin heute auch gerade darauf gestoßen – uff! Und gestern hat ein gut meinender und hilfreicher TL4-Benutzer einen Thread geteilt, und das geteilte Tag war dann nicht mehr getaggt.

Können wir hier bitte etwas tun? Das macht es für Administratoren, Moderatoren oder anscheinend sogar TL4-Benutzer schwieriger.

[Heliosurge (Dan DeMontmorency)]

@awesomerobot

Ich denke, das ist ein schöner Mittelweg, bei dem wir die Verwendung von Admin-/Mod-Befugnissen nicht erschweren… eine Art Warnung, die darlegt, was passiert… zum Beispiel:

#tag ist auf #category beschränkt, sind Sie sicher, dass Sie Ihre Staff-Berechtigungen verwenden möchten, um dies in #different-category zu posten?

Ähnlich wie die Theme component „Admin-Warnungen“, aber für die Tag-Erstellung anstelle von geschlossenen Themen.

[TheDarkWizard]

Riesige Schreib-Website hier, die an der Migration zu Discourse arbeitet, und wir planen, Tags, Einschränkungen und den Rest der Tag-Regeln ziemlich eifrig zu nutzen. Eine Option zu haben, die es ermöglicht, dass Staff-Accounts versehentlich keine Anforderungen umgehen, ist für Websites von Vorteil, die sich tatsächlich bemühen, diese einzurichten.

[Jarjar]

Bitte umsetzen, es ist zwingend erforderlich. Und wenn ein Admin es so eingerichtet hat, dass es nur für bestimmte Gruppen oder Tags gilt, dann soll es auch für ihn gelten. Es ist irgendwie dumm, das Ergebnis seiner Einstellungen nicht sehen zu können, ohne eine zufällige Person zu imitieren.

[ondrej]

Ich persönlich hatte nie das Bedürfnis, mich strikt an Tags oder Kategorien zu halten, aber beim Lesen dieses ganzen Themas scheint es für einige Communities etwas sehr Wichtiges zu sein, und ich kann den Anwendungsfall definitiv erkennen.

Vielleicht ist hier eine Art Seiteneinstellung erforderlich, da dies nicht in allen Communities erforderlich ist, aber es ist hilfreich, sie zu haben. Zum Beispiel:

---

Tag-Beschränkungen für Mitarbeiter erzwingen

---

Oder vielleicht die Einstellung detaillierter gestalten, falls Sie nicht überall Beschränkungen wünschen? In den Kategorieeinstellungen würden Sie einrichten, welche Tag-Gruppe Sie in der Kategorie erzwingen möchten, und dann würden Sie im Dropdown-Menü auswählen, welche Kategorie Sie in der Seiteneinstellung erzwingen möchten?

---

Tags in bestimmten Kategorien für Mitarbeiter erzwingen

Kategorie auswählen