그룹 소유자가 그룹 멤버가 아니어도 되도록 허용

[tobiaseigen]

여기에는 그룹 소유자가 그룹 멤버가 아닌 경우를 허용하는 기능 요청에 대한 추가 설명이 필요합니다. 더 많은 설명이 필요하면 알려주세요. 감사합니다, @sam!

@tobiaseigen

관리자로서 저는 항상 그룹에 사람을 추가하고 제거하는 일을 처리해야 하는데, 이는 문제점이 많고 시간이 많이 걸리며, 중요한 기능의 중심에 제가 과도하게 위치하게 만듭니다. 우리는 비공개 카테고리에서 멤버들을 하나로 모으고 토론에서 @멘션 가능하게 만들기 위해 여러 그룹을 사용하고 있습니다(예: 직원 부서, 과정 참가자 등). 우리의 헬프데스크 팀은 온보딩과 오프보딩, 그리고 계정 관련 도움을 제공합니다. 우리는 여러 가지 이유로(예: 민감한 토론에 사용되는 일부 비공개 카테고리에서 PM이나 주제를 읽을 수 없어야 함, 데이터 프라이버시 이유로 사용자 내보내기 접근 권한 제한, 문제 해결을 쉽게 하기 위해 무언가를 망가뜨릴 수 있는 사람 제한 등) 그들에게 관리자 권한을 부여할 수 없습니다.

[InspektorCluzo (Michel)]

그걸 볼 수 있다면 정말 좋겠습니다.

@InspektorCluzo

워크플로상의 이유로, 본질적으로 스태프가 아닌 사용자를 그룹 멤버로 지정할 권한을 위임할 수 있는 기능이 매우 유용합니다.

우리 사이트의 경우를 들어볼까요:

• 디스패처(스태프가 아닌 자원봉사자)들은 우리가 하는 일(식사 배달)의 워크플로를 관리합니다.
• 그들은 사이트에 방문하여 식사(그룹)를 이용하거나 식사 배달 자원봉사를 하기를 원하는 사람들을 상대합니다.
• 이를 수행할 수 있는 유일한 방법은 모든 디스패처를 소비자(Consumer)와 운전자(Driver)로 만들고, 그 다음 그룹 소유자(Group Owner)로 만드는 것입니다.

우리 입장에서는, 이 경우 디스패처를 운전자 그룹과 소비자 그룹의 멤버로 만들지 않고, 단순히 해당 그룹들의 그룹 소유자로 만드는 것이 훨씬 깔끔합니다.

이 기능의 개념을 정말 좋아하는 이유는, 많은 사이트에는 두 가지 워크플로가 있기 때문입니다:

(1) 사이트 멤버십 프로세스를 관리하는 워크플로

(2) 사이트의 존재 목적을 관리하는 워크플로. 우리에게는 식사 배달이 목적입니다.

(1)에 대해 스태프가 책임지는 것이 합리적입니다. 하지만 (2)는 다른 인력(크레)으로 관리할 수 있어야 합니다. 이 기능은 본질적으로 사이트 관리자가 사이트의 사명에 초점을 맞춘 연결된 역할의 위계 구조를 만들 수 있게 해줍니다.