카테고리 태그 규칙/제한을 관리자에도 적용해 주세요

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

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

관리자/모더 권한 사용을 더 어렵게 만들지 않으면서도, 어떤 일이 일어나고 있는지 설명하는 일종의 경고가 포함된 좋은 중도안이라고 생각합니다. 예를 들어:

#tag는 #category에 제한되어 있습니다. 스태프 권한을 사용하여 #different-category에 게시하시겠습니까?

#customization:theme-component의 "관리자 경고"와 비슷하지만, 폐쇄된 토픽 대신 태그 생성에 사용되는 것입니다.

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

개인적으로는 태그나 카테고리를 엄격하게 따를 필요가 없었지만, 이 전체 주제를 읽으면서 일부 커뮤니티에서는 꽤 중요한 문제라는 점을 알 수 있었고, 그 사용 사례도 충분히 이해할 수 있습니다.

모든 커뮤니티에서 이런 기능이 필요하지는 않지만, 있으면 도움이 되므로 어떤 형태의 사이트 설정이 필요할 수도 있습니다. 예를 들어:

---

스태프에 대한 태그 제한 적용

---

아니면, 모든 곳에 제한을 걸고 싶지 않은 경우를 위해 설정을 더 세분화하는 방법도 있습니다. 카테고리 설정에서 해당 카테고리에 적용할 태그 그룹을 설정하고, 사이트 설정의 드롭다운 메뉴에서 적용할 카테고리를 선택하는 방식입니다.

---

특정 카테고리에 대한 스태프 태그 적용

카테고리 선택