제가 디스코스 생태계에서 꽤 (오래) 자리를 비운 적이 있어서 궁금한 점이 생겼습니다. 주제 소유자가 자신의 주제만(자신의 주제 외에는 모더레이터 권한 없이) 관리할 수 있도록 하는 기능을 제안하거나 구현한 분이 계신가요? 빠른 검색으로는 관련 결과를 찾지 못했기 때문에, 여기서 논의를 시작하는 것이 도움이 될 수도 있을 것 같습니다. 여러분은 이런 기능이 유용하다고 보시나요?
그런 논의가 있었다는 사실은 알지 못하지만, 카테고리 그룹 모더레이터를 추가했습니다. 이를 통해 특정 그룹을 카테고리에 추가하여 관리 권한을 부여할 수 있습니다.
아니요, 작성자(OP)가 관리자 권한이 있는 것이 아니라면 자신의 특정 토픽을 관리할 수 없습니다. 이것이 바로 관리자가 존재하는 이유입니다. 더 자세한 내용은 justindirose의 링크를 참고하세요.
매우 유용합니다. 자체 관리되는 토픽을 성공적으로 활용하는 대형 포럼들이 있지만, 이는 매우 특정한 목적을 위한 것이며, 이것이 단지 예외적인 경우라고 생각합니다.
현재까지는 운영자(OP)들에게 플래그를 사용하도록 안내하고 있습니다.
명확한 이유로 인해 OP는 관리자 섹션(검토)에 접근할 수 없지만, 자신의 스레드에서 게시물을 삭제 또는 수정 대상으로 쉽게 플래그를 지정할 수 있으면 유용할 것입니다.
사용자가 자신이 "소유"한 토픽을 "관리"할 수 있어야 한다고 생각합니다. 다만, 특정 방식으로 말이죠. 조건에 따라 사용자는 자신의 토픽을 닫거나 삭제할 수 있어야 하고, 괴롭힘이나 모욕적이라고 판단되는 답변은 “부분적으로 숨기기”(스포일러 표시처럼) 할 수 있어야 합니다(최근 트위터의 기능 참고…).
여러분은 어떻게 생각하시나요?
@codinghorror의 반응을 상상만 해도…
이것은 특정 신뢰 수준을 가진 사용자에게만 가능해야 합니다.
Discourse는 무엇보다도 토론 소프트웨어입니다.
OP(첫 번째 게시자)라는 것은 단순히 토론을 시작했다는 뜻입니다. 사람들이 글을 읽고 답글을 쓰기 시작하면, OP는 다른 참가자들과 마찬가지로 그 토론에 대한 소유권을 더 이상 갖지 않습니다.
이 관점에서 보면, OP에게 주제(토픽)를 조정(모더레이션)할 수 있는 권한을 부여하는 것은 의미가 없습니다.
자신의 콘텐츠에 대한 상호작용을 완전히 제어할 수 있는 시스템이 필요하시다면, 블로그나 마이크로블로그 소프트웨어를 사용하는 것이 좋습니다.
일정 부분 동의하지만, (마이크로)모더레이션이 이루어지는지에 대해서는 여전히 논의의 여지가 있습니다. 모든 커뮤니티는 서로 다르기 때문에, 사람들이 토론이 어떤 수준으로 모더레이션될지, 그리고 누가 그 역할을 맡을지 선택할 수 있도록 하는 데 해로울 것이 없다고 생각합니다.
블로그/마이크로블로그에는 보통 단일 모더레이터가 있으므로, 이는 자체 모더레이션이 이루어지는 포럼과는 다른 '종류’라고 할 수 있습니다. 블로그 팜(블로그 집합체)은 관리하기가 더 어려울 수 있지만, 비교 대상으로는 더 적절할 수 있습니다. 다만, 그 문제는 토론이 ‘더 멀리 떨어져서’ 이루어진다는 점입니다(이것이 제 모국어가 아니기 때문에 영어로 어떻게 설명해야 할지 확실하지 않지만, 의미가 전달되길 바랍니다). 자체 모더레이션이 이루어지는 포럼에서는 사용자에게 권한을 부여하지만, 관리자는 카테고리, 태그 등을 사용하여 구조화된 토론을 유지할 수 있습니다.
아마도 (관리자로서) 대규모 커뮤니티를 운영할 때 켜고 끌 수 있는 기능일 수 있습니다. 특정 신뢰 등급의 사용자에게 몇 가지 특별한 작업을 허용할 수 있습니다. ![]()
(예를 들어, 여기서는 Reddit의 경우입니다)
동의하지 않습니다. 게시글에 답글이 달리면, 답글의 수가 얼마가 되든 게시글의 '소유권’은 변경되지 않습니다… 게시글 작성자 = OP = 게시글 소유자이며, 자신의 콘텐츠를 관리(합리적인 제한은 물론)할 수 있어야 합니다.
무슨 말씀이신지 잘 이해가 되지 않는데요?
그렇게 하면 안 됩니다. 그렇게 하면 модератор(관리자)와 플래그 제도의 의미가 사라지니까요. : )
이 주제는 두 가지 잘못된 전제에 기반한 용어 문제로 인해 잘못된 방향으로 시작되었다고 생각합니다. 그래서 양측이 서로를 이해하지 못하는 것입니다. 그들의 전제가 다르기 때문입니다.
이 주제의 제목과 첫 번째 게시글은 다음과 같이 주장하고 있습니다:
- 주제 작성자(관례상 OP, 즉 Original Poster)는 해당 주제를 소유합니다.
- 모더레이터(운영자)의 권한 범위는 자신의 주제, 즉 주제 게시글로만 제한될 수 있습니다.
짧은 답은, 이 두 가지 전제 모두 실제 법적 권리와 사전적 의미를 무시해야 한다는 것입니다:
- 주제 작성자(관례상 OP)에게 이 포럼에서 주제를 소유할 법적 권리는 없습니다. 그러나 해당 게시글의 콘텐츠에 대한 법적 권리는 존재합니다.
- '모더레이터’라는 단어의 일반적으로 수용된 사전적 의미는 자신의 콘텐츠만을 포함하는 범위를 허용하지 않습니다. 다시 말해, 모더레이터는 일반적으로 직위에 임명된 제3자를 의미합니다.
더 자세한 설명은 아래를 읽어보십시오.
소유자 (Owner)
무엇을 누가 소유하는가의 문제는 소유권이 주로 법적 권리에 관한 것이므로 쉽게 결정됩니다.
- 주제 콘텐츠의 소유권(주제 자체와의 중요한 구분)은 법적 해석, 예: 포럼 이용약관 및 저작권법과 혐오 발언 관련 법규에 의해 결정됩니다.
- 포럼 소유자가 어떤 주제를 누가 소유하는지 결정합니다.
- OP(첫 번째 게시글 작성자)는 자신의 콘텐츠에만 소유권을 가지며, 그 콘텐츠를 담는 컨테이너인 주제, 게시글 또는 답글을 소유하지 않습니다.
- 주제에서 첫 번째 게시글을 작성하는 것은 다른 게시글에 대한 소유권을 부여하지 않습니다.
법적 권리가 일반적으로 도덕적 권리보다 우선하므로, OP가 주제를 소유할 도덕적 권리에 대한 논의를 다룰 가치는 없습니다.
모더레이터 (Moderator)
모더레이터(화학 물질이 아닌 사람으로서)는 두 가지 구체적인 속성을 가집니다:
- 기능: 두 당사자 사이에서 중재하거나 조정하는 것.
- 직위: 권한이나 서비스의 위치에 임명되는 것.
원래의 제안은 이 두 가지 의미 어느 하나도 충족하지 않습니다:
- 회원은 일반적으로 자신에 대해 모더레이터가 될 수 없습니다.
유일한 예외는 자신의 영역에서 더 높은 권한이 없는 최고 존재일 것입니다. 보편적으로 그 사람은 하나님이며, 이 포럼에서는 그 사람이 codinghorror입니다. - 모더레이터는 직위에 임명되어야 합니다.
모든 회원이 모더레이터라면, 사실상 권한의 차이를 나타내는 별도의 모더레이터 직위는 존재하지 않는 것입니다. 따라서 이 경우 그 용어를 사용해서는 안 됩니다.
참고로, 이 논의와 무관한 사용자들(예: AFAIK 주제 생성이 불가능한 익명 사용자, 주제 수정이 불가능한 스테이징 사용자)이 있기 때문에 ‘사용자(user)’ 대신 '회원(member)'이라는 용어를 사용합니다.
권한의 수준을 나타내는 수식어를 앞에 붙일 수 있습니다. 예: 앞서 언급된 카테고리 그룹 모더레이터. 그러나 이는 모든 회원에게 이용 가능하며 회원이 해당 역할에 임명되지 않는 제안된 주제 수준의 권한에는 사용해서는 안 됩니다.
누군가는 내가 내 게시글을 모더레이션(moderate)한다면 '모더레이터’라는 용어를 사용할 수 있어야 한다고 말할 수 있습니다. 이 접근법의 문제는, moderator라는 명사의 사용은 일반적으로 moderate라는 동사(극단성을 줄이다)나 형용사(극단적이지 않은, 더 평균적인) 형태에서의 사용에 의해 결정되지 않는다는 것입니다. 내가 온건한 견해를 가지고 있거나 극단적인 견해를 완화한다면 나는 moderate(온건파)가 되며, 모더레이터가 되지 않습니다. 대신 모더레이터는 본질적으로 중재(arbitrate)와 조정(mediate)와 같은 동사를 사용하며, 인터넷 포럼이나 온라인 토론을 모니터링한다는 특정 의미 외에는 moderate라는 동사의 사용에 의존하지 않습니다.
누군가는 그 특정 의미를 사용하여 자신의 토론을 모니터링하는 누구에게나 모더레이터라는 용어를 적용할 수 있다고 주장할 수 있습니다. 그러나 그렇게 하면 다시 동일한 문제에 부딪힙니다. 모니터(monitor) 역시 직위, 즉 공식적인 자격과 연관되어 있으며, 포럼에서 모더레이션과 관련하여 모니터링의 의도된 범위는 거의 확실하게 이것이 맞습니다.
이 토픽의 토론 분위기와 수준이 꽤나 어긋나고 있습니다. 게다가 이 기능의 장점과 문제점에 대해 논의하는 다른 토픽들도 이미 존재하며, 과거의 실수를 피하는 방식으로 구현하는 방법에 대한 새로운 통찰은 보이지 않습니다.
이 토픽은 구현을 위한 좋은 출발점이라기보다는 그렇지 않으므로, @Stefan님의 질문에 대한 답변(“아니요”)이 이미 이루어졌으므로 닫겠습니다.