שיחולו כללי תגיות קטגוריה / הגבלות גם על מנהלים

[mattdm (Matthew Miller)]

Problem:

1. We have moderators who are also very active users of the site
2. We’re using tag groups and tag requirements heavily — it’s fundamental to the structure of the site. ^[1]
3. Moderator powers are always on, even if someone with moderator status is just posting.

Together, this means it is easy to inadvertently mess up.

Request

Please make tag requirements for categories apply even to moderators and admins.^[2]

---

1. See Navigating Fedora Discussion — Tags, Categories, and Concepts - Fedora Discussion for how this is set up — and we’re planning to merge Ask Fedora into the site as well, making this even more important. ↩︎

2. My suggestion for a sudo-like approach to site privs did not get a lot of enthusiasm, but this would cover one of the biggest issues! ↩︎

[mattdm (Matthew Miller)]

I guess another way to phrase it would be: please invert the sense of this test!

  test("staff bypass tag validation rule", async function (assert) {
    await visit("/");
    await click("#create-topic");

    await fillIn("#reply-title", "this is my new topic title");
    await fillIn(".d-editor-input", "this is the *content* of a post");

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

I really agree with this one. If you’ve set up these rules, you probably really want them. I have them on a site that only I use and it’s really annoying that I can’t count on discourse to keep me following the rules I set up for myself and it’s lots of extra typing to select “todo” and avoid creating a new “to” tag.

It would suit me to just force admins to follow the rules, but failing that, having a “are you sure you don’t want to follow the rules” modal would be nice.

Or maybe a “staff follows tag rules” site setting. That seems pretty easy.

[Jagster (Jakke Lehtonen)]

For moderators: +1
For admins: -1

Admins must have ability to override everything. And when one is an admin the basic assumption is he/she/it/bot knows what can do and what not.

[awesomerobot (Kris)]

@pfaffman

It would suit me to just force admins to follow the rules, but failing that, having a “are you sure you don’t want to follow the rules” modal would be nice.

I think this is a nice middle-ground where we’re not making it harder to use admin/mod powers… some kind of warning that outlines what’s happening… for example:

#tag is restricted to #category, are you sure you want to use your staff privileges to post this to #different-category?

[mattdm (Matthew Miller)]

@Jagster

Admins must have ability to override everything. And when one is an admin the basic assumption is he/she/it/bot knows what can do and what not.

I could live with this — I would make my own account a moderator account and make a secondary admin account.

@awesomerobot

I think this is a nice middle-ground where we’re not making it harder to use admin/mod powers… some kind of warning that outlines what’s happening… for example:

#tag is restricted to #category, are you sure you want to use your staff privileges to post this to #different-category?

I agree that this would be better, but it seems like the places where this would be added would also be places where "Regular mode" for admins and moderators (e.g. something like "sudo") would be even better.

[jwheel (Justin Wheeler)]

Hi, I am adding my +1 that this feature is useful for large communities with decentralized approaches to governance across tags.

I am adding here a few additions to the last thread:

@mattdm

I don’t want to be able to accidentally violate intended tagging rules. (Are non-admin moderators also able to accidentally do this? I can’t easily test, even.)

@codinghorror

I understand the concern, but it isn’t a huge issue in practice, at least not over the 10 years I’ve been working on this project.

@mattdm

It also doesn’t prevent me from accidentally violating constraints I set up on purpose (like the tag rules, or posting in categories which are supposed to be read-only).

This is a challenge for the Fedora Community because both leadership and the community follow an open policy for managing tags. Any registered group in Fedora can request new tags and assign tag discussion moderators. The Fedora leadership works with the community to create new tags and promote them across the community (e.g. documentation, wikis, websites, word-of-mouth). Additionally, as a large community that covers a wide range of topics, we also have a lot of tags! I don’t always know every tag in Fedora Discourse.

So, when a site admin (who actively participates to varying degrees across Fedora Discourse) adds tags to a post or participates in a tag with specific rules, it becomes an easy mistake for a Fedora Discourse admin to break Fedora’s open policies. The open policies are how we make our global site governance more inclusive and accessible to the community. In this way, our site admin privileges can sabotage our open approach to how Fedora leadership runs the Fedora Discourse for the community.

@Tris20

Instead of this, have you considered using the test account in a browser you don’t regularly use? Then it can just stay logged in.

While this technically works, it is an onerous task for a site admin who posts actively across several tags. It is a negative user experience because sometimes I don’t have a lot of immediate time on hand (e.g. in a short break between meetings with follow-up actions). Patience is difficult with the extra user flow before I get to the thing I was trying to do in the first place (i.e. make a new thread across relevant tags I know exist and think might exist).

@Jagster

Admins must have ability to override everything. And when one is an admin the basic assumption is he/she/it/bot knows what can do and what not.

I don’t see this feature request as taking away an admin’s ability to override. Instead, it gives informed consent to a site admin vis-à-vis active site poster that they are breaking site rules and tagging norms during the action of doing it, not after.

[mattdm (Matthew Miller)]

I just hit this myself today — ugh! And yesterday, a well-meaning and helpful TL4 user split a thread and the split tag ended up untagged.

Please, can we do something here? This makes it harder to be an admin, moderator, or apparently even TL4 user.

[Heliosurge (Dan DeMontmorency)]

@awesomerobot

I think this is a nice middle-ground where we’re not making it harder to use admin/mod powers… some kind of warning that outlines what’s happening… for example:

#tag is restricted to #category, are you sure you want to use your staff privileges to post this to #different-category?

Like the theme-component “Admin Warnings” but for tag creation instead of closed topic.

[TheDarkWizard]

Huge writing site here working on migrating to Discourse, and we plan to use tags, restrictions and the rest of the tag rules rather zealously. Having an option to make it, so staff accounts don’t accidentally bypass requirements, is beneficial to sites that actually put in the effort to set them up.

[Jarjar]

בבקשה תגרום לזה לקרות, זה חובה. ואם מנהל מערכת הגדיר להשתמש רק בקבוצה או בתגיות מסוימות, החל את זה גם עליו. קצת מטופש לא להיות מסוגל לחזות בתוצאה של ההגדרות שלך מבלי להתחזות לאקראי.

[ondrej]

באופן אישי, מעולם לא הייתה לי צורך לעקוב בקפדנות אחרי תגיות או קטגוריות, אבל בקריאת הנושא הזה נראה שזה משהו די חשוב לכמה קהילות ואני בהחלט יכול לראות את השימוש.

אולי סוג כלשהו של הגדרת אתר נחוץ כאן מכיוון שזה לא נחוץ בכל הקהילות אבל זה מועיל שיהיה. לדוגמה:

---

אכוף הגבלות תגיות עבור צוות

---

או אולי להפוך את ההגדרה ליותר גרנולרית למקרה שאתה לא רוצה הגבלות בכל מקום? בהגדרות הקטגוריה תגדיר איזו קבוצת תגיות אתה רוצה לאכוף בקטגוריה, ואז תבחר איזו קטגוריה אתה רוצה לאכוף בהגדרת האתר בתפריט הנפתח?

---

אכוף תגיות על קטגוריות ספציפיות עבור צוות

בחר קטגוריה