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

[mattdm (Matthew Miller)]

문제:

1. 관리자 중에도 사이트에서 매우 활발하게 활동하는 사용자가 있습니다.
2. 우리는 태그 그룹과 태그 요구 사항을 대량으로 사용하고 있습니다 — 이는 사이트 구조의 핵심입니다. ^[1]
3. 관리자 권한은 항상 켜져 있습니다. 관리자 상태의 사용자가 단순히 게시물을 올리는 경우에도 마찬가지입니다.

이 모든 것이 합쳐져 실수로 문제를 일으키기 쉽습니다.

요청

카테고리에 대한 태그 요구 사항이 관리자와 관리자(admin)에게도 적용되도록 해 주세요. ^[2]

---

1. 이것이 어떻게 설정되어 있는지 확인하려면 Navigating Fedora Discussion — Tags, Categories, and Concepts - Fedora Discussion 를 참조하십시오 — 또한 Ask Fedora를 이 사이트로 통합할 계획이므로, 이 부분은 더욱 중요해집니다. ↩︎

2. 사이트 권한에 대한 sudo 방식 접근에 대한 제 제안은 큰 호응을 얻지 못했지만, 이 조치는 가장 큰 문제 중 하나를 해결할 수 있습니다! ↩︎

[mattdm (Matthew Miller)]

다른 표현을 쓰자면: 이 테스트의 의미를 반대로 바꿔주세요!

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

이 의견에 정말 공감합니다. 이런 규칙을 설정하셨다면, 실제로 그 규칙을 따르기를 원하시는 거겠죠. 저는 혼자만 사용하는 사이트에서 이 기능을 사용하고 있는데, 제가 스스로 세운 규칙을 따르도록 디스코스를 믿을 수 없다는 점이 정말 짜증납니다. "todo"를 선택하고 새로운 “to” 태그를 생성하지 않으려면 매번 추가 입력을 해야 하거든요.

관리자에게 규칙 준수를 강제하는 방식이 가장 좋겠지만, 그게 어렵다면 "정말 규칙을 따르지 않으시겠습니까?"라는 확인 모달이 뜨면 좋겠습니다.

아니면 "스태프가 태그 규칙을 준수합니다"라는 사이트 설정 항목을 추가하는 것도 괜찮을 것 같습니다. 구현도 꽤 쉬워 보이니까요.

[Jagster (Jakke Flemming)]

모더레이터용: +1
관리자용: -1

관리자는 모든 것을 무시할 수 있는 권한을 가져야 합니다. 그리고 누군가가 관리자라면, 기본적으로 그/그녀/그것/봇이 무엇을 할 수 있고 무엇을 할 수 없는지 알고 있다는 전제가 깔려 있습니다.

[awesomerobot (Kris)]

@pfaffman

관리자들에게 규칙을 따르도록 강제하는 것이 나한테는 더 적합할 것 같긴 한데, 그게 안 되면 “정말 규칙을 따르지 않으시겠습니까?”라는 모달이 뜨면 좋겠습니다.

관리자/모더 권한 사용을 더 어렵게 만들지 않으면서도, 어떤 일이 일어나는지 설명하는 경고창을 보여주는 좋은 절충안이라고 생각합니다. 예를 들어:

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

[mattdm (Matthew Miller)]

@Jagster

관리자는 모든 것을 무시할 수 있는 권한을 가져야 합니다. 그리고 누군가가 관리자라면, 기본적으로 그 사람/그녀/그것/봇이 무엇을 할 수 있고 무엇을 할 수 없는지 알고 있다는 전제가 됩니다.

저는 이것을 받아들일 수 있을 것 같습니다 — 제 계정을 moderator(모더레이터) 계정으로 만들고, 보조 관리자 계정을 하나 더 만들겠습니다.

@awesomerobot

관리자/모더레이터 권한을 사용하는 것을 더 어렵게 만들지 않으면서도, 어떤 일이 일어나는지 요약하는 종류의 경고가 표시되는 좋은 중도적 해결책이라고 생각합니다. 예를 들어:

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

이것이 더 낫다는 데 동의하지만, 이 기능이 추가될 위치들은 "Regular mode" for admins and moderators (e.g. something like "sudo") 의 '일반 모드’가 훨씬 더 적합할 것 같은 곳이기도 합니다.

[jwheel (Justin Wheeler)]

안녕하세요, 태그를 중심으로 한 분산 거버넌스 방식을 채택한 대규모 커뮤니티에서 이 기능이 유용하다고 생각합니다. 저도 +1을 표합니다.

마지막 스레드에 몇 가지 추가 의견을 남깁니다:

@mattdm

의도된 태그 규칙을 실수로 위반하는 것은 원치 않습니다. (관리자가 아닌 모더레이터도 실수로 이런 일을 할 수 있을까요? 쉽게 테스트해 볼 수도 없고요.)

@codinghorror

그 우려를 이해하지만, 적어도 이 프로젝트에 관여한 10년 동안 실제로는 큰 문제가 되지 않았습니다.

@mattdm

또한 의도적으로 설정한 제약 조건(예: 태그 규칙이나 읽기 전용으로 되어야 하는 카테고리에서 게시하는 것 등)을 실수로 위반하는 것도 막아주지 않습니다.

이것은 Fedora 커뮤니티에게는 큰 과제입니다. 리더십과 커뮤니티 모두 태그 관리를 위한 개방형 정책을 따르고 있기 때문입니다. Fedora의 등록된 그룹이라면 누구나 새 태그를 요청하고 태그 토론 모더레이터를 지정할 수 있습니다. Fedora 리더십은 커뮤니티와 협력하여 새 태그를 만들고 이를 커뮤니티 전반에 홍보합니다(예: 문서, 위키, 웹사이트, 입소문 등). 또한 다양한 주제를 다루는 대규모 커뮤니티인 만큼 태그 수도 매우 많습니다! 저는 Fedora Discourse의 모든 태그를 항상 다 알고 있지는 않습니다.

따라서 사이트 관리자(각도 다른 수준으로 Fedora Discourse에 적극적으로 참여하는 사람)가 게시글에 태그를 추가하거나 특정 규칙이 있는 태그에 참여할 때, Fedora Discourse 관리자가 Fedora의 개방형 정책을 위반하기 쉽습니다. 이러한 개방형 정책은 전역 사이트 거버넌스를 더 포용적이고 커뮤니티 접근성이 좋게 만드는 방법입니다. 이 관점에서 보면, 사이트 관리자 권한은 오히려 Fedora 리더십이 커뮤니티를 위해 Fedora Discourse를 운영하는 개방형 방식을 저해할 수 있습니다.

@Tris20

대신, 평소 사용하지 않는 브라우저에서 테스트 계정을 사용하는 것은 고려해 보셨나요? 그러면 로그인이 유지될 수 있습니다.

이 방식은 기술적으로는 작동하지만, 여러 태그에 걸쳐 활발하게 게시하는 사이트 관리자에게는 부담이 큰 작업입니다. 때로는 즉시 쓸 시간이 많지 않을 때(예: 후속 조치가 필요한 회의 사이의 짧은 휴식 시간) 이런 상황이 발생하기 때문에 사용자 경험 측면에서 부정적입니다. 결국 하려던 일(즉, 존재한다고 알고 있거나 존재할 것으로 생각하는 관련 태그를 걸어서 새 스레드를 만드는 것)에 도달하기 전에 추가적인 사용자 플로우를 거치는 것에 대한 인내심이 필요하기 때문입니다.

@Jagster

관리자는 모든 것을 오버라이드할 수 있어야 합니다. 그리고 누군가가 관리자라면, 기본적으로 그/그녀/그것/봇이 무엇을 할 수 있고 무엇을 할 수 없는지 알고 있다고 가정합니다.

저는 이 기능 요청이 관리자의 오버라이드 능력을 박탈하는 것으로 보지 않습니다. 대신, 사이트 관리자가 사이트 규칙과 태그 규범을 위반하고 있다는 사실을, 그 행위를 수행하는 동안 사후에가 아니라 사전에 인지한 동의(informed consent)를 제공한다는 것입니다.

[mattdm (Matthew Miller)]

오늘 저도 이 문제를 겪었습니다 — 어휴! 그리고 어제, 선의에 찬 도움을 주려는 TL4 사용자가 스레드를 분리했는데, 분리 태그가 태그가 지정되지 않은 상태로 남아 있었습니다.

부탁드립니다, 이 문제에 대해 뭔가 조치를 취할 수 없을까요? 이렇게 되면 관리자나 모더레이터, 심지어 TL4 사용자조차 일을 하기 _더 어려워_집니다.

[Heliosurge (Dan DeMontmorency)]

@awesomerobot

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

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

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

[TheDarkWizard]

여기에는 대규모 글쓰기 사이트가 있으며, Discourse로의 마이그레이션을 진행 중입니다. 태그, 제한 사항 및 기타 태그 규칙을 매우 엄격하게 적용할 계획입니다. 스태프 계정이 실수로 이러한 요구 사항을 우회하지 않도록 하는 옵션을 제공하는 것은, 실제로 설정에 공을 들이는 사이트들에게 유익합니다.

[Jarjar]

반드시 실행해 주세요. 관리자 설정에서 특정 그룹이나 태그만 사용하도록 지정된 경우, 그 설정도 동일하게 적용해 주세요. 임팩토싱 없이 설정한 결과를 직접 확인할 수 있도록 해 주세요. 임팩토싱을 통해 무작위 사용자로 전환해야만 결과를 볼 수 있는 건 좀 멍청한 일이잖아요.

[ondrej]

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

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

---

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

---

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

---

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

카테고리 선택