이 제안은 카테고리별로 명확한 범위가 설정되는(예: 전역 Mod 역할은 문제가 있을 수 있음) 경우, 조정 활동을 위임하는 데 있어 제가 원하는 여러 요건을 충족합니다.
원하는 사항 중 아직 남아 있는 것은, 위임된 조정자가 자신의 특정 범위 내 카테고리 하위에 하위 카테고리를 생성할 수 있는 권한을 갖는 것입니다. 카테고리 거버넌스를 자동화하거나, 최소한 셀프서비스로 만들 수 있는 몇 가지 방법을 검토하고 있지만, 가능하면 같은 컨텍스트 내에서 처리하는 것을 선호합니다.
해당 기능을 추가하는 것은 제 머리속에서는 복잡해 보입니다.
"모드가 카테고리를 생성할 수 있음"이라는 사이트 설정을 확인해야 합니다.
사용자의 카테고리 Mod 상태를 확인하고, 카테고리/새로 만들기扳手(레버)를 표시해야 합니다.
새 카테고리 UI에서 상위 카테고리를 필수로 해야 합니다.
그리고 상위 카테고리는 해당 사용자가 카테고리 Mod인 카테고리 목록으로만 제한되어야 합니다.
이 기능이 이미 검토 대상인지, 아니면 적절한 설정 조합을 사용하면 현재 상태에서도 작동할 수 있는지 확인해 보고 싶었습니다. 만약 불가능하다면, 전역 Mod/스태프에 의한 수동 카테고리 생성 또는 외부 프로세스를 사용하는 것으로 충분할 것입니다. 위임된 Mod들이 항상 카테고리를 생성하는 것은 아니기 때문입니다.
사용 사례에 대한 세부 정보를 알려줄 수 있을까요? 이 기능이 실제로 어떻게 사용될지에 대한 현실적인 예시를 제시하면 도움이 될 수 있습니다.
현재로서는 불가능합니다. 카테고리 생성을 관리자(그리고 moderators manage categories and groups 설정이 활성화된 경우 관리자)로 제한하는 로직은 다음 위치에 있습니다:
이 기능이 핵심 Discourse 코드에 추가될 수 없다면, Discourse 플러그인을 통해 구현할 수 있다고 생각합니다. can_create_category? 메서드에 parent가 설정되어 있는지와 사용자가 parent 카테고리에서 카테고리 관리자 권한을 가지고 있는지 확인하는 추가적인 검사가 필요합니다.
플러그인이 옵션이 아니라면, API를 통해 구현할 수 있습니다. 기본적으로 시스템 사용자가 카테고리 관리자를 대신하여 하위 카테고리 생성 요청을 보내는 방식입니다. 이는 개발이 다소 복잡할 수 있으며, Discourse 포럼의 DiscourseConnect 제공자 역할을 하는 외부 사이트가 있는 경우 가장 쉬울 것입니다.
우리 입장에서는 카테고리 스코프 기반 모더레이션과 동일한 사용 사례입니다. 기본적으로 그룹 단위의 카테고리 모더레이터에게 자율성을 부여하여, 각자가 자신의 커뮤니티 부분을 원하는 대로 관리할 수 있도록 하는 것입니다.
이 기능이 메인 코드베이스에 추가되어 카테고리 모더레이션 패턴을 강화할 수 있을 것 같다는 데 동의합니다. 해당 함수는 좋은 출발점입니다. 카테고리 모더레이터 데이터가 어디에 저장되어 있는지 찾아내고, 해당 검사에 OR 조건을 하나 더 추가해야 합니다.
다만 더 복잡한 변경 사항(이라고 생각합니다)은 UI 자체일 것입니다. 부모 항목 선택이 필수인데 사용자가 카테고리 모더레이터인 경우 말이죠. 부모 항목의 결과를 카테고리 모더레이터로 활동하는 카테고리만 필터링하는 것이 더 쉬울지, 아니면 사용자가 카테고리 모더레이터일 때 부모 항목이 선택되지 않거나 카테고리가 맞지 않으면 오류가 발생하는 검증 로직을 트리거하는 것이 더 쉬울지 코드를 더 자세히 살펴봐야 합니다. 필터링이 UX 측면에서는 더 좋겠지만, 검증 패턴이 구현하기는 아마 더 간단할 것입니다.
그리고 이 내용을 별도의 토픽으로 분리해 주셔서 감사합니다. 공지사항에 게시한 후에도 이 주제는 별도의 글로 다뤄져야 한다고 느꼈거든요.
네, 저희 경우에는 비공개 범주가 더 적습니다. 특정 그룹에 대해 읽기 권한을 제한하려는 범주가 있긴 하지만, 그 부분은 나중에 도입될 수 있습니다. 이 기능이 실제로 범주 관리자 수준의 역할을 암묵적으로 생성한다면 동의합니다. 하위 범주를 만들면 해당 사용자가 읽기 설정 등을 조정할 수 있어야 한다는 것이 합리적이죠.
저는 단순히 생성 활동에만 집중하고 있었지만, 범주 설정이 동일한 범위의 일부가 되어야 한다는 점에 동의합니다.
카테고리 관리자가 있는 카테고리가 몇 개인가요? 카테고리 관리자가 카테고리를 생성하거나 수정할 것으로 예상되는 빈도는 얼마나 되나요? 개인정보 보호가 문제가 되지 않는다면, 카테고리 관리자가 왜 일반 관리자나 운영자에게 대신 변경을 요청하지 못하는지 이해가 되지 않습니다.
오피스의 다양한 그룹을 위해 최상위 카테고리가 대략 20~30개 정도가 될 것 같습니다. 각 그룹은 하위 카테고리를 위한 자체적인 구조를 가질 것입니다.
메타 카테고리나 기타 접수(intake)를 통해 수동으로 요청하는 방식으로도 100% 구현할 수 있습니다. 최상위 카테고리 각각에 기존 카테고리 관리자 권한이 활성화된 최상위 모더레이터 1~2명을 배치하는 것을 고려하고 있습니다. 이들은 또한 카오스를 관리하고 필요 시 문제를 에스컬레이션하기 위해 해당 카테고리의 모더레이터 그룹을 관리할 것입니다.
일부 사용자는 자신의 콘텐츠에 대한 편집 권한이 다른 사람에게 있는 것에 대해 민감하게 반응할 수 있으므로, 쉬운 방식의 격리된 공간(walled garden)을 만들 수 있었으면 좋았을 것입니다. 최상위 스태프 인원이 많지 않을 것이므로, 처리 시간이 지연되는 것을 원하지 않습니다. 시스템이 본격적으로 돌아가기 시작하면, 사용자가 자신의 목소리가 반영되고 있다는 느낌을 받을 수 있도록 범위에 따른 참여도(scoped engagement) 보고서를 검토해야 하며, 모든 구성원이 규정을 준수하고 있는지 확인하기 위해 관리자 등급(admin tier) 보고서도 살펴봐야 합니다.
네. 카테고리 관리자(moderator)가 해당 카테고리의 관리자(admin) 권한을 가졌으면 합니다. 예를 들어 카테고리 설정, 권한 구성, 또는 카테고리 생성 등이 이에 포함됩니다. 후자의 경우, Discourse API를 통해 카테고리 생성을 자동화하여 해결했습니다.
Discourse가 훨씬 더 많은 카테고리와 잘 작동할 수 있게 되었으니, 이제 이 기능을 원하는 사람이 더 많을지 궁금합니다:
저의 경우, 100개 이상의 국가에 지부가 있는 포럼을 운영하면서 기타 유형의 카테고리도 함께 사용하는 모습을 상상해 봅니다. 태그를 사용해서도 가능하겠지만, 각 국가가 매번 관리자/스태프에게 수동으로 요청하지 않고 자체 하위 카테고리를 관리할 수 있다는 아이디어를 좋아합니다. 왜냐하면 카테고리 관리는 태그 관리보다 누가 열람/답변/생성할 수 있는지에 대한 통제를 더 많이 제공한다고 생각하기 때문입니다.