Request: make category tag rules / restrictions apply to moderators too

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! ↩︎

3 Likes

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(), "/");
  });
2 Likes

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.

5 Likes

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.

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?

10 Likes

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

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.

2 Likes

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:

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.

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

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.

3 Likes