커뮤니티가 성장할 때 흔히 발생하는 문제점은 무엇인가요?

What does "Enterprise-Ready" look like in your view? (Hot takes welcome!)Signals a community is moving beyond early stage에서 이어지는 논의입니다:

비관리형 성장은 지원 프레임워크와 프로세스가 성장 속도를 따라가지 못하면 시작되는 역설을 낳습니다. 즉, 커뮤니티의 사회적 복잡성이 운영 구조를 초과하는 상황입니다.

이것은 다음과 같은 형태로 나타날 수 있습니다:

  • 모더레이션 공백
    • 플래그가 증가하면 기존 가이드라인에 대한 엣지 케이스가 더 자주 발생합니다.
    • 명시적인 정책이 아닌 비공식적인 프로세스에 의한 반응적 모더레이션은 사례 처리 방식의 불일치를 초래하여 신뢰를 훼손할 수 있습니다.
    • 때로는 아무도 의도하지 않았음에도 예외가 선례가 되어 더 많은 하류 마찰을 유발합니다.
  • 문화적 이탈
    • 초기 단계에서 파워 유저가 문화를 형성하는 것은 긍정적인 경우가 많지만, 규모가 커지면서 관리되지 않으면 거버넌스 문제가 될 수 있습니다.
    • 대규모 커뮤니티에서는 익명성의 수준이 높아지고 맥락이 부족해져 책임 소재가 흐려지며, 새로운 행동 패턴이 출현할 수 있습니다.
    • 모더레이션 기능이 커뮤니티와 함께 확장되더라도, 초기 모더레이터와 파워 유저의 비율이 신규 멤버에 비해 희석되어 문화적 규범이 사라질 수 있습니다.
  • 리포트 복잡성
    • 초기 단계의 성공은 종종 일화적(anecdotal)이지만, 엔터프라이즈 레벨에서는 가치에 대한 증거를 제공해야 합니다.
    • 초기부터 올바른 지표가 정의되고 추적되지 않으면 비즈니스 케이스를 구축하기가 더 어려워집니다.
  • 매몰된 지식
    • 확장 가능한 분류 체계가 없으면, 선택의 역설(paradox of choice)이 어디에 게시할지에 대한 마찰을 만듭니다.
    • 정보 구조가 약해지면 검색 결과가 노이즈가 많아지고, 사람들은 검색을 포기하고 다시 질문하는 것을 선호하게 되어 문제가 커집니다.
  • 내부 소유권 균열
    • 기능 간(cross-functional) 의사결정에 대한 명확한 소유자가 없으면, 커뮤니티에서 서로 다른 것을 원하는 여러 팀이 압력을 가할 수 있습니다.

여러분은 이러한 상황 중 어떤 것을 커뮤니티에서 경험해 보셨나요? 어떻게 해결을 시도해 보셨나요?

12개의 좋아요

모드레이션에서 불일치가 발생하거나 플래그가 무시되는 경우, 저는 보통 모드레이션 팀과 다음에 대해 논의합니다. 어디서 더 많은 인력이 필요한가? 그들은 어떻게 대응하고 있는가? 그런 다음, 그러한 문제를 돕기 위해 활동적이고 신뢰할 수 있는 사용자를 TL4 또는 카테고리 모드레이터로 시범 기간 동안 승진시킵니다.

이 경우 #ai에 의한 관련 주제(Related Topics)는 매우 유용합니다. 이는 때때로 답변을 포함하는 관련 주제를 제공하기 때문입니다. 관련 주제가 너무 많을 때의 단점 중 하나는, 제안된 주제들이 현재 주제의 단순한 반복에 불과할 수 있다는 것입니다.

유용한 답변을 포함하는 매우 오래된 주제들은 부스트(상단으로 올리기)하고, 중복된 주제들은 정리(병합 또는 삭제)하겠습니다.


다른 사람들이 어떻게 하는지 듣고 싶습니다.

6개의 좋아요

AI에 대해 대체로 비판적인 입장에 있는 저이지만, 이번에는 동의할 수밖에 없습니다. 어떻게 된 일인지, 이 관련 주제 기능은 AI 버블 시대에 거의 모든 소프트웨어에 추가된 기능 중에서도 제 취향에 가장 잘 맞는 부분입니다. 이전에 ‘비슷한 주제’ 기능으로 찾지 못했던 문제를 이미 해결한 사례를 찾아주는 데 놀라울 정도로 정확합니다.

3개의 좋아요

좋든 나든, 아직까지 이런 문제들을 겪어본 적이 없습니다. 사용자 기반은 크지만 상대적으로 조용합니다 (:melting_face:).

커뮤니티가 성장하면서 우리가 느낀 유일한 불편한 점은 카테고리 및 그룹의 범위 확장(scope creep)입니다.

  • 카테고리의 경우, 충분한 양이 없는 콘텐츠 유형을 수용하기 위해 사소한 예외를 두는 것입니다. 기존 어딘가에 억지로 끼워 넣거나, 새 주제가가 거의 없는 새 카테고리를 만들어야 합니다.
  • (내부) 그룹의 경우, 담당자가 부재 중일 때 그 대행을 추가해야 하지만, 그 대행을 나중에 제거하지 않은 채로 남아 있는 경우가 있습니다.
1개의 좋아요

네, 좋습니다. 제가 언급했던 그 간극은 주로 플래그 처리 방식이나 결정 과정에서 발생하는 일관성 부족과 관련이 있습니다. 이러한 것들이 제대로 정리되고 문서화되지 않으면, 추가적인 모더레이터를 배치하는 것이 오히려 문제를 악화시킬 수 있습니다. 모든 사람이 같은 방향을 보고 있는지 어떻게 보장하시나요?

네, 저도 과거에 이 문제로 고생해 본 적이 있습니다. 제가 찾은 가장 좋은 대안은 [임시] 태그입니다. 해당 태그가 충분히 쌓이면 새로운 하위 카테고리로 이동시키는 것이 쉽습니다.

3개의 좋아요

내 경험에서 규모는 커뮤니티의 가장 큰 분기점(break-point)이었습니다.

커뮤니티, 특히 B2C나 엔터테이저 수준의 관심에 기반한 커뮤니티가 특정 규모를 넘어서면 여러분이 나열한 여러 문제들이 복합적으로 나타나기 시작하는 흥미로운 현상이 있습니다. 그중에서도 문화적 표류(cultural drift)가 가장 눈에 띄는 문제입니다. 이는 커뮤니티의 원래 설립 의도가 사용자 기반의 변화하는 동기에 의해 포기되거나 압도되거나, 자연스러운 이탈로 인해 사라지는 현상입니다.

항상 저를 불안하게 만드는 것은 구조적 콘텐츠 분류의 분기점, 즉 여러분이 '확장된 분류 체계에서 발생하는 과도한 노이즈를 유발하는 매몰된 지식’이라 부른 것입니다. 커뮤니티를 분재(또는 비유에 따라 과일 나무)로 보는 제 마음속 모델에서, 토론 카테고리(가지)가 너무 크고 활발해지면 오히려 그 카테고리를 유지해 온 핵심 사용자에게 해가 되곤 합니다. 활동량이 급증하면 유용성이 떨어지고, 커뮤니티 매니저가 주의하지 않으면 콘텐츠 가치의 희석으로 인해 카테고리가 붕괴할 수 있습니다.

여기서 핵심은 핵심 사용자를 해치지 않으면서 카테고리가 자연스럽게 분할되어야 할 시점을 파악하는 것입니다. 이를 위해서는 상당한 수준의 세심한 주의를 기울여야 합니다.

주요 핵심 카테고리들이 너무 커져서 더 이상 유용하지 않게 되거나, 처음에는 비교적 캐주얼한 ‘일반 토론’ 영역이던 것이 악성 종양처럼 번져 콘텐츠가 더 이상 표면화(surfaceable)되지 않아 커뮤니티가 위축되는 모습을 여러 번 보았습니다.

이 문제의 해결책은 과학적 접근보다는 예술적 접근에 가깝습니다. 하지만 저는 ‘활발한(active)’ 카테고리가 어떻게 평가되는지에 주목하는 편입니다. 전통적으로 저는 Reddit의 오래된 정의를 따랐는데, 하루 5개 이상의 게시물이 있으면 '활발함’으로 간주합니다. 이는 자급자족 가능한 핵심 커뮤니티가 충분히 형성되었음을 의미하는 기준입니다. '너무 활발함’에 대한 하한선은 중간 규모 커뮤니티의 경우 같은 5를 세제곱으로 적용하여 하루 약 125개 게시물로 설정합니다. 세제곱이라 한 이유는, 이 모델이 점점 커지는 도넛 모양의 구조들이 연속되어 있고, 인간의 기억으로 상호작용할 수 있는 우리 궤도 안의 행위자(actors)의 범위를 고려하기 때문입니다.

또한 제가 주목하는 주요 항목 중 하나는 지식 기반 엔터프라이즈 커뮤니티 내에서 발생하는 분기점입니다. 바로 두려운 '과도한 모더레이션(Overmoderation)'이 그 대가를 치르기 시작하는 부분입니다. 모더레이터가 너무 많거나, 모더레이션이 지나치게 강하거나, 지나치게 엄격하거나, 훈계조일 경우 신규 사용자의 적응을 억제하는 효과가 있어 '회색머리(Graybeards, 고참)'들로만 이루어진 정체된 풀(pool)이 형성될 수 있습니다. 권력 남용적인 모더레이션, 또는 시민적 예의 범위를 넘어 독단적인 엄격함으로 톤을 통제하려는 과도한 시도는 커뮤니티의 활기를 죽이고 문화를 위축시키며, 궁극적으로 커뮤니티의 유용성을 감소시키거나 완전히 제거할 수 있습니다.

상당한 규모의 커뮤니티에서는 모더레이션에 대한 투명성을 확보하는 것이 중요합니다. 모더레이션은 징벌적 관점이 아니라 회복적 관점에서, 그리고 우아하게 이루어져야 하며, 모더레이션은 명성이나 특권이 아닌 커뮤니티의 시민적 참여(civic engagement)로 남아야 합니다.

모더레이션 공백에 대한 제 경험칙은 필요한 모더레이터보다 20% 더 많은 인력을 확보하되, 그들이 추가적인 잠재적 모더레이터를 식별할 권한이 있다는 점을 확실히 인지하도록 하는 것입니다.

3개의 좋아요

이것은 저에게는 작은 도전입니다.

저는 모더레이터-관리자 팀의 포럼 리더입니다. 포럼의 소유자는 아니지만, 우리 스태프가 올바른 일을 하도록 하고 포럼에 적절한 수의 스태프가 있는지 확인하는 역할을 맡고 있습니다. 때로는 포럼에서 가장 활발하게 활동하는 스태프 중 한 명으로서, 저는 작은 부담을 지고 있다고 느낍니다. 가끔 반쯤 활동적인 상태의 사용자와 이야기하여 그들에게 모더레이터 권한을 부여해 보고, 스팸이나 괴롭힘과 같은 사용자 기반 위반 사항을 처리하는 등 제 부담을 조금 덜어보려 합니다. 하지만 그런 경우 그들은 잠시 사라져 버립니다. 때로는 스스로에게 묻곤 합니다…

포럼의 소유자/창립자가 가끔 오프라인으로 전환되고 커뮤니티와 상호작용하지 않는다는 사실이, 실제로 규모가 매우 작은 이 포럼에 게시물을 올리고 기여하려는 사람들의 의욕을 떨어뜨리는 걸까요?

그 이유는 다음과 같습니다.

작년 제가 가입했을 때 포럼은 꽤 활발했습니다. 하지만 여름이 찾아오면서 활동량이 급감했고, DAU/MAU(일일/월간 활성 사용자 수) 지표는 최악이었으며 포럼의 끈성(Stickiness)도 좋지 않았습니다. 올해에는 속도를 되찾는 데 크게 실패했고, 소유자도 거의 활동하지 않았습니다. 최근에는 포럼이 자주 다운되어 다른 웹사이트에서 온 사용자들로부터 포럼이 왜 다운되었는지를 묻는 메시지를 많이 받았습니다. 그래서 저는 그 이유를 설명해야 했습니다(소유자로부터 받은 이메일에 따르면 포럼 서버와 관련된 문제였습니다). 마침내 포럼이 다시 돌아왔을 때 몇몇 사용자가 채팅에 게시물을 올리고 반쯤 활동적인 상태가 되었는데, 그때 저는 슬퍼졌습니다. 만약 우리가 이 활동성을 유지한다면 제 부담은 다시 더 무거워질 것임을 알았기 때문입니다. 우리 다른 세 명의 관리자는 매우 활발하지는 않았지만, 저는 그것이 좋은 일이라고 생각했습니다. 하지만 지금은 다시 죽어버렸고, 제 질문은 제 머릿속에 여전히 남아 있습니다.

1개의 좋아요

흥미로운 주제입니다. 특정 크리에이터 플랫폼에서는 모더레이션이 (예측 가능하게) 자의적으로 적용되는 것에 대한 많은 논의가 이루어지고 있습니다. 여러 경우에서 플랫폼 자체가 자신의 결정 사항을 공개하지 않습니다. 하지만 투명하고 공정하며 일관된 모더레이션을 원한다면, 이 시스템은 규모에 맞춰 어떻게 설계되어야 할까요? 이의 제기 시스템? 내부 감사? 무임승차하는 모더레이터를 포착하기 위한 패턴 인식?


모더레이션의 공백을 제외하고, 나머지 지적 사항들은 조직이 성장하면서 내부적으로 경험하는 문제들과 정확히 동일해 보입니다. :slightly_smiling_face:

3개의 좋아요

테드, 반갑네. :slight_smile:

제 경험상 더 중요한 것은 올바른 사람들을 확보하는 것, 그들을 신뢰할 수 있는지 확인하는 것, 정기적으로 소통하는 것, 프로세스를 문서화하는 것(예외 사항 포함) 그리고 명확한 이의 제기 경로를 마련하는 것입니다.

The Community Lifecycle: From Launch to Legacy 참고

[55명의 자원봉사자 모더레이터로 구성된] 팀은 이미 잘 윤활된 기계처럼 작동하고 있었습니다. 거버넌스는 서로 다른 서브포럼에 배치된 팀 리더, 어드바이저, 멘토들 사이에 분산되어 있었으며, 모두가 잘 문서화되고 정기적으로 재평가되는 중앙 집중식 프로세스를 따랐습니다.

관련 경험이 있는 분이 계시다면 다른 의견도 듣고 싶습니다.

2개의 좋아요

이 시나리오는 낯설지 않았습니다. 마치 커뮤니티 구축 관련 빙고 카드에서 항목을 하나씩 지워나가는 것과 비슷했기 때문입니다.

도전 과제가 발생할 때마다 선제적으로 대응하는 이해와 지지를 보내는 팀원들과 매우 도움이 되는 Discourse 스태프를 볼 수 있어 고무적입니다.

저의 관점에서, 파워 유저가 커뮤니티의 행동에 영향을 미치는 것 자체가 본질적으로 문제 있는 것은 아닙니다. 단, 그들의 행동이 우리가 확립한 가이드라인과 지속적으로 일치한다면 말입니다.

제 주요 관심사는 시간이 지나도 경험 많고 긍정적인 파워 유저를 지속 가능하게 유지하는 것입니다. 커뮤니티가 성장하고 진화하면서, 이러한 개인들은 우리의 문화적 규범과 모범 사례를 새로운 세대의 활성 멤버들에게 전수하는 데 핵심적인 역할을 하게 되며, 이를 통해 커뮤니티의 장기적인 건강을 보장합니다.

3개의 좋아요

@sps 님, 전적으로 동의합니다. 대부분의 경우, 바로 그 이유 때문에 파워 유저를 육성하는 것이 매우 유익합니다.

정말 운이 좋으시네요! 몇 년 전에 바로 그 주제에 대해 연구를 해본 적이 있습니다. Motivations - Building Successful Superuser Programs 를 참고해 보세요.

2개의 좋아요

캘린더/캘린더 통합(및 화상회의 통합)의 매우 ‘부분적인’ 구현은 Discourse의 기업용 사용에서 명백한 문제점입니다.

본질적으로 Microsoft 중심적인 직장 환경에서 Discourse를 더 깊이 채택하도록 유도하려 할 때, Discourse 내에서 완전히 진행되고(일정/시간을 위한 Discourse 투표와 같은 멋진 기능까지 포함되었을 수 있음) 결국 일정 부분은 Teams/Outlook 링크를 제공해야 한다는 사실을 인정해야 하는 것은 솔직히 부끄러운 일입니다. 대부분의 팀은(특히 초기에는) 참가자들의 극심한 Discourse 수용이 필요한 Discourse 내장 캘린더를 완전히 채택하는 데 의지가 없습니다.

2개의 좋아요

당신도 운이 좋습니다! 캘린더/이벤트는 활발하게 개발 중이며, 비디오 회의는 로드맵에 포함되어 있습니다. 이러한 부족함을 인지하고 있습니다.

2개의 좋아요

저는 특히 초기 단계에서 이것이, 그리고 프로젝트 상위의 사람들에 대한 신중한 기대치 관리가 매우 중요하다고 생각합니다.

모든 사람에게 문을 활짝 열고 디스코urses(Discourse)를 과하게 홍보하면 프로젝트를 쉽게 망칠 수 있습니다. 관련성 없거나 주의 분산을 일으키는 콘텐츠, 전문가들을 화나게 만드는 형식이 엉망인 질문들이 쏟아지고, 이제 그 초기 사용자 수에 묶여버린 관리팀(그 수는 분명히 줄어들 것입니다)이 생깁니다. 그 상태에서 복구하는 것은 예방하는 것보다 훨씬 어렵습니다.

우리가 이 문제를 해결한 방법 중 하나는 사람들이 특정 주제에 대한 내용을 읽기 전에 새 주제를 만들지 못하도록 하는 것이었습니다:

  1. 좋은 질문을 작성하는 방법 (스택 오버플로우 방식)
  2. 공유하면 안 되는 것 (고객의 기밀성 요구 사항에 따라)
  3. 공유해도 되는 것과 불법적인 내용을 합법적으로 수정하는 방법

이것은 세 가지 결과를 가져왔습니다:

  1. 플랫폼 관리가 쉬워졌습니다 - 주제를 만들기 전에 무엇이 괜찮고 무엇이 아닌지를 매우 명확하게 설명했기 때문입니다.
  2. 전문가들을 저열한 콘텐츠의 물결로부터 보호했습니다.
  3. 많은 사람들을 화나게 했습니다.

특히 3번에 대해 말하자면, 초기 제한 조치에 부딪힌 직원의 약 20~30%는 10분간의 독서가 자신들에게는 하찮은 일이라고 느끼고, 이미 완벽한 질문을 작성하는 방법을 알고 있다고 생각했습니다. 일부 경우에서는 이것이 사실이었지만, 대부분은 제 생각에 우리가 구축하고자 하는 문화에 맞지 않는 사람들을 막아내는 역할을 했습니다. 즉:

  • 읽기는 쓰기보다 중요합니다.
  • 겸손한 태도로 플랫폼에 오세요.
  • 다른 직원들이 잘 형식화된 질문을 통해
    • a) 당신을 돕기 위해 자발적으로 내어주는 시간을 덜 쓰게 하고
    • b) 2~3년 후에도 그 주제에서 배울 수 있도록 하세요.

이 또한 매우 좋은 지적입니다. 우리는 주제 수, 주제 조회수, 답변 수 등을 기반으로 ROI 공식을 작성하는 것이 매우 유용하다는 것을 발견했습니다. 결국 이는 전문가가 여러 회의와 이메일 체인에서 여러 번 질문받지 않고 디스코urses(Discourse)에서 한 번만 질문받음으로써 얼마나 많은 시간이 절약되었는지를 나타내는 결과로 이어졌습니다.

5개의 좋아요

좋은 지적입니다, 트리스탄. 초기 단계라고 하셨는데, 이전에 이미 커뮤니티가 존재했나요? 아니면 정말로 첫 출시를 말씀하시는 건가요?

좋은 질문입니다. 위의 글에서는 첫 출시를 염두에 두고 있었지만, 현실에서는 그렇게 단순하지 않습니다. 엔터프라이즈 기업에서는 이전 커뮤니티가 어떤 형태로든 항상 존재합니다.

제가 무슨 뜻인지 구체적인 예를 들어보겠습니다. 우리의 Discourse 이전의 커뮤니티는 여러 플랫폼에 흩어져 있었습니다:

  • Yammer(Viva Engage) :face_vomiting:
  • Sharepoint :roll_eyes:
  • Microsoft Teams :person_shrugging:

이로 인해 기대치 관리가 훨씬 더 어려워졌습니다.

Viva Engage에서 넘어온 사용자들은 "내가 하고 싶은 것을 아무거나 올릴 수 있다"는 기대를 하고 있었습니다. 이를 운영하던 팀은 검수를 하지 않았고, 접근하는 모든 매니저의 요구를 단순히 받아들이기만 했습니다. 그 결과, 매니저의 KPI를 충족시키기 위한 목적만으로 존재하는 커뮤니티들이 생겨났습니다. 새로운 커뮤니티가 생기고 3개월 동안 활성화되었다가, 그 후 죽음을 맞는 식이었습니다. Needless to say(말할 것도 없이), 이러한 사고 방식을 극복하고 왜 정확히 그 접근 방식이 몇 달 후 실패하는지, 그리고 왜 우리의 구조적이고 장기적인 접근 방식이 처음에는 더 느리겠지만 6~12개월 후에 더 나은 결과를 제공할 수 있는지를 설득하기 위해 상당한 코칭과 커뮤니케이션 노력이 필요했습니다.

Sharepoint는 "내가 원하는 파일을 아무거나 업로드할 수 있다"는 기대를 형성했습니다. 엔터프라이즈 수준에서는 파일을 공개적으로 공유할 때 매우 신중해야 합니다. 각 고객과 서비스 제공업체는 회사와 각각 계약이 있으며, 그들이 우리에게 공유하는 각 파일은 서로 다른 기밀성 요구 사항을 가집니다. Sharepoint는 사용자가 해당 파일에 누가 접근할 수 있는지 정확히 설정할 수 있게 해주지만, Discourse는 그렇지 않습니다(그리고 그럴 이유가 있습니다. 그것은 파일 공유 플랫폼이 아니므로). 저는 이 문제를 사용자들에게 Sharepoint에 파일을 업로드한 후 해당 파일의 링크를 공유하도록 장려하여 해결했습니다. 공유된 파일에 접근할 수 없는 사람이 있다면 해당 주제(topic)에서 권한을 요청할 수 있었습니다. 귀찮은 일이었지만, 소송보다 비용이 덜 들었습니다.

MSTeams는 "여기에 나만의 채널/커뮤니티 구획을 가질 수 있다"는 기대를 만들었습니다. 아니요, Discourse의 핵심은 바로 그 반대였습니다. 이 프로젝트의 목표는 지식의 비효율적인 단절(silos)이 아닌 지식 공유를 만드는 것이었습니다. 팀 채널은 기밀이 있거나 프로젝트에 특화된 지식에는 좋은 솔루션이었지만, 더 일반적인 맥락으로 추상화할 수 있는 모든 것은 Discourse에서 공유하도록 장려했습니다.

3개의 좋아요

관련해서 약간 다른 주제로, 커뮤니티의 확장성과 분열에 대해 이야기하고 있으니.

인류학에는 던버의 수(Dunbar’s number)라는 개념이 있습니다. 간략히:

[던버는] 인간이 안정적으로 유지할 수 있는 관계의 수가 150개라고 제안했습니다

Discourse 내에서 특정 사용자의 관심을 끄는 사용자 그룹의 평균 크기를 파악할 수 있을까요? 그리고 사용자 그룹, 사용자 정의 그룹 등에 대한 일반적인 분석을 통해 결론을 도출할 수 있을까요?

이렇게 질문하는 이유는 다음과 같습니다: 사회적 범위의 한계에 도달하거나, 혹은 이러한 가정된 한계를 깨뜨리는 것이 커뮤니티의 분열 지점(breaking points)에 기여하는 요인일 수 있기 때문입니다. :red_question_mark: Discourse가 대규모로 이를 분석할 수 있을까요? 흥미로운 연구가 될 것 같습니다.

수정: 이전에도 이 오래된 토론에서 던버의 수 이론이 언급된 적이 있지만, 맥락은 달랐습니다. Don't be fooled by activity metrics – they may vary greatly in different community types - #8 by HAWK

대규모 커뮤니티에서는 분명히 기여 요인이며, 여러분의 전략에는 이러한 그룹이 분화되고 반자율적으로 운영될 수 있도록 지원하는 프로세스를 포함해야 합니다.

출처: Community Fragmentation: When Growth Becomes Your Obstacle

온라인 커뮤니티 수명 주기의 마지막 단계는 '미토시스(mitosis)'라고 불리며, 이는 단일 세포가 유전적으로 동일한 자식 세포로 분열하는 세포 분열 과정을 이름에서 따왔습니다. 그 목표는 정체성을 유지하면서 분열을 가능하게 하는 것입니다. 소그룹이 원래 커뮤니티의 DNA, 즉 가치관, 문화, 그리고 공유된 전설(lore)을 단순히 구성원만이 아닌 이를 물려받도록 하는 데는 의도적인 노력이 필요합니다.

미토시스 전략은 커뮤니티마다 고유하기 때문에 각기 다르게 보일 수 있지만, 성공하려면 더 넓은 커뮤니티 생태계의 공생적 부분으로서 자율적으로 운영되는 소그룹의 형성을 가능하게 해야 합니다.

2개의 좋아요