첫 번째 디스코스 관리자, 그 의욕이 꺾이다

이 글은 페이스북에서 이주하는 활발한 지원 커뮤니티 구조화라는 주제와 별개로 별도의 주제로 올립니다. 왜냐하면 이 문제는 또 다른 차원의 이야기이기 때문입니다. 커뮤니티 구축은 누군가가 그곳에 도착하기 전에 시작됩니다. 커뮤니티 빌더(이렇게 부르기로 하죠)가 커뮤니티가 기능하는 방식을 설계하고, 그 커뮤니티 설계를 자신의 선택한 도구(Discourse)에 구현할 때 말입니다. 설정 조정, 기능 추가 또는 제거, 테마 선택, 카테고리 생성, 회원 온보딩 플로우에 대한 생각, 모더레이션 집행 방식 등입니다.

이러한 설계 결정들은 커뮤니티 빌더의 비전과 도구의 가능성 사이의 상호작용, 일종의 “대화”의 결과물이라고 할 수 있습니다. “우리가 도구를 만들고, 도구가 우리를 만든다”는 말을 대략 인용하며 말입니다.

지금 이 커뮤니티 빌더는 매우 압도당하고 좌절감을 느끼고 있습니다. 그리고 저는 이에 대해 몇 가지 생각을 나누고 싶습니다.

먼저, 저에 대해 조금 말씀드리겠습니다. 저는 처음 커뮤니티를 구축하는 사람이 아니며, 웹 기반 도구에도 익숙합니다. 저는 25년 이상 “온라인에서 사람들이 연결되는” 이 영역에 있었습니다. 때로는 전문적으로, 때로는 그렇지 않은 형태로요. 저는 개발자가 아니지만, 과거에 제 서버를 관리하고 몇 가지 WordPress 플러그인을 코딩할 만큼 충분한 기술 지식을 갖추고 있습니다. 블로그, 소셜 미디어, 온라인 커뮤니티가 하나의 “현상”이 되기 전에 관련 과정을 설계하고 가르친 적도 있습니다. 무엇이 제대로 작동하지 않는지 해결하기 위해 사용자 매뉴얼과 씨름하는 것도 저에게는 낯선 일이 아닙니다.

현재 제가 운영하는 주요 커뮤니티는 곧 8주년이 되며, 3개의 Facebook 그룹에 걸쳐 8,000~9,000명의 회원으로 구성되어 있습니다. 이 커뮤니티는 완전히 비웹, 비기술적입니다. 여기는 아픈 고양이들이 있는 사람들을 위한 곳입니다. 그리고 수의사들도 포함되죠. 매우 활발하고 건강하며, (이 말을 하는 사람은 저이지만) 극도로 잘 관리되고 모더레이션이 이루어지고 있습니다. 20~30명의 팀이 운영에 관여하고 있습니다. 평균적인 커뮤니티 회원은 평소 활동(메신저 채팅, Facebook 게시물 작성, 댓글 달기)에서 벗어나면 디지털 조작에 어려움을 겪습니다. 그들에게 Google 시트에 값을 입력하고, 휴대폰에서 로그인 상태를 유지하며, 게시물에 시트 링크를 공유하게 하는 것은 도전 과제입니다.

이것은 제 자랑이 아니라, 제가 소위 “비개발자 웹 파워 유저”임을 명확히 밝히는 것입니다. “포럼”이나 “커뮤니티”를 설정해보겠다고 생각하는 아무나 같은 사람이 아닙니다.

Discourse에서 보는 가능성에 대해 제가 매우 열정적임에도 불구하고, 저는 drowning(완전히 압도당하고) 있습니다. 저는 Meta에서 수없이 많은 시간을 검색, 읽기, 게시에 보냈습니다. 체크박스를 보고 눈이 정사각형이 될 때까지 설정을 살펴봤습니다. 저는 플랫폼에 충분히 익숙하여 무엇이 가능해야 하는지 감을 잡고 있지만, IKEA 소파가 들어오던 박스의 내용물 앞에 서 있지만 설명서나 도구는 없는 것 같은 기분이 듭니다. 모든 가능성과 옵션의 인지적 부하가 저를 죽이고 있습니다. 디지털 문맹에 가까운 제 소중한 회원들이 Discourse의 기본 설정과 외관의 수많은 기능에 직면하게 된다는 생각만으로도 식은땀이 납니다.

그렇다면 저는 여기서 무엇을 하고 있는 걸까요? Facebook 커뮤니티가 이렇게 잘 돌아가고 있는데 왜 상황을 그대로 두지 않는 걸까요? 그것은 제가 첫날부터 Facebook이 불가피한 열화(enshittification, 당시에는 제 어휘에 없었지만 그 과정을 매우 명확히 이해했습니다)가 허용하는 한에서만 작동할 것이라는 것을 알고 있었기 때문입니다. 수년간 그 균형은 Facebook 쪽에 유리했습니다. 최근 몇 년간 그 균형이 기울기 시작했습니다. 때때로 저는 그룹이 사라진 채로 아침에 눈을 뜰 수 있다는 것을 알면서도 대안을 찾아보았습니다. 그러나 제가 본 어떤 해결책도 이 커뮤니티를 지원하기에 실행 가능한 옵션처럼 보이지 않았습니다.

올해 여름, Discourse가 제 시야에 들어왔습니다. 저는 트라이얼에 가입하고 일주일 동안 최대한 이것저것 해보았습니다. (Facebook 계정 정지로 인해 트라이얼 두 번째 주가 날아갔지만, 그것은 또 다른 이야기입니다.) 저는 감탄을 금치 못했습니다. 여기는 우리가 Facebook에서 꿈꿀 수 있었던 모든 것을 할 수 있게 해주는 도구가 있었습니다. 강력하고, 끝없이 설정할 수 있으며, 현대적이고 견고했습니다. 그리고 오픈소스였습니다: 저는 자체 호스팅을 할 수 있었습니다. 며칠 만에 저는 마음을 굳혔습니다. 우리 커뮤니티의 새로운 집은 Discourse가 될 것입니다.

제 마음은 변하지 않았습니다. 여전히 Discourse가 우리에게 필요한 모든 상자를 체크해 줄 미래, 그리고 우리 커뮤니티가 빅 플랫폼의 족쇄에서 벗어나 자신의 집에서 번성하는 미래를 보고 있습니다. 하지만 그곳에 도달하는 길은 제가 예상했던 것보다 훨씬 더 어렵습니다. 저는 정말로 고전하고 있습니다. 어제 제 기술에 더 밝은 모더레이터 중 한 명이 제 손을 들어주려고 Discourse 인스턴스에 접속했는데, 그녀의 첫 반응은 인터페이스와 기능에 대한 혼란이었습니다. 이것이 우리가 위해 작동할 것과 얼마나 멀리 떨어져 있는지에 대한 확인이 필요했다면, 바로 그것이었습니다.

어젯밤, 저는 이 주제를 우연히 발견했습니다: Why isn't Discourse more frequently recommended as a "community platform"? – 저는 읽고, 읽고, 더 읽었습니다. 저는 그 대화에서 표현된 많은 감정에 공감할 수 있었습니다. 특히 @oshyan 님은 제게 매우 공감되는 많은 점을 지적합니다. 저는 제 배경과 스킬셋을 가진 사람이 “일반인” 커뮤니티를 위해 Discourse를 작동하는 형태로 만드는 데 이렇게 큰 어려움을 겪어야 한다는 것에 대해 정직하게 생각합니다. 저는 수많은 플러그인을 설치하고 설정한 WordPress 인스턴스를 땀 한 방울 흘리지 않고 수없이 많이 해왔습니다 – 물론 WordPress는 덜 복잡하지만, 그것만이 아닙니다: 제가 해야 할 일을 찾는 “정보 구조”에 대해 뭔가 있어, 가이드된 시티 투어보다는 미로처럼 느껴지게 만듭니다.

아마도 제가 잘못하고 있는 것일 수 있습니다. 하지만 만약 그렇다면, 그것은 제가 “제대로 하려고” 최선을 다함에도 불구하고입니다. 저는 Discourse의 존재에 대해 매우 감사하게 생각합니다. 진심으로요. 그리고 Meta에서 발견한 반응성도 또한 마음을 따뜻하게 합니다. 비즈니스를 운영하거나 심지어 “단순히” 도구를 개발할 때, 해야 할 모든 것과 하고 싶은 모든 것을 수행하기 위해 자원이 항상 충분한 것은 아니며, 이는 이해할 수 있는 부분입니다.

하지만 열정적인 사용자로서, 도구의 인터페이스가 커뮤니티 구축과 관리라는 중요한 부분을 촉진하기보다 방해가 되고 있다는 느낌을 받는 것은 매우 좌절스럽습니다. 그리고 불행히도, 이것은 세상에서 가장 도움이 되는 지원 커뮤니티(말씀드리는데, Meta!)조차 “고칠” 수 없는 것입니다.

제 관점에서, 특히 위에서 링크된 긴 스레드를 읽은 후, (진정한) 파워 유저들이 원할 경우 그들의 방식대로 할 수 있도록 많은 기능과 설정을 갖는 것은 괜찮습니다. 하지만 제가 Discourse에서 부족한 것으로 보는 것은, 평균적인 커뮤니티 빌더와 평균적인 비기술 커뮤니티에 작동하는, 축소된 기본 설정입니다. 때로는 적을수록 더 많습니다.

WordPress를 설치하면, 이메일을 보낼 수 있는 기술적 스킬만 있으면 바로 블로그를 시작할 수 있으며, 할 말이 있는 평균적인 사람과 읽고 싶어 하는 평균적인 독자에게 작동합니다. 원한다면 몇 가지 설정을 조정하거나, 엣지 케이스나 파워 유저라면 플러그인과 테마를 마음껏 사용할 수 있습니다. 제 Mac에는 대부분의 사람들에게 작동하는 디자인 선택이 내장되어 있습니다. 그렇지 않다면, 용감하거나 기술적인 사용자가 가지고 놀 수 있는 명령줄과 구성 파일도 있습니다.

제가 여기서 이전에 말해지지 않은 것을 말하고 있다는 것, 그리고 “Discourse”가 자신의 단점을 인지하고 해결할 계획을 가지고 있다는 것을 알고 있습니다. 하지만 저는 지치고, 좌절하며, 낙담하고 있습니다 – 그리고 여기 사람들이 얼마나 친절하고 지지적인지에 대한 어떤 것을 빼앗지 않으려 하지만, 이 모든 것이 얼마나 어려운지에 대해 제가 조금 외로움을 느끼고 있습니다: 보세요, 여기에는 저의 문제를 한 가지 방식으로든 해결해 줄 모든 훌륭한 가이드, Meta의 모든 훌륭한 정보, 모든 설정과 테마와 컴포넌트와 플러그인이 있습니다. 하지만 그것은 다른 레벨에 존재하는 문제를 해결하는 데 아무것도 도움이 되지 않습니다: 너무 풍부하여 제 뇌에서 안정적인 자리를 찾기를 거부하는 이 낯선 가능성의 정글을 헤쳐 나가는 것, 그리고 제가 제거해야 할 필요가 있는 곳에 마찰을 추가하는(물론 의도적으로 그런 것은 아니지만!) 인터페이스를 다루는 것 말입니다.

이곳까지 읽어주셔서 감사합니다. 그리고 여러분의 경험에 대한 생각을 환영합니다. 유사한 시련을 겪었거나 겪고 있거나, 제가 핵심을 놓치고 있다고 생각하시더라도요.

28개의 좋아요

안녕하세요,

먼저, 상황과 불만사항을 명확하고 세심하게 표현해 주셔서 감사합니다.

관리자의 경험과 사용자의 경험은 구분하는 것이 중요하다고 생각합니다. 제 생각에는 Discourse의 사용자들은 이 플랫폼으로 인해 비슷한 다른 플랫폼에서 겪는 것 이상의 어려움을 겪지 않습니다. 그러나 관리자의 경험은 확실히 매우 다릅니다.

Discourse는 매우 강력한 플랫폼이지만, 그 복잡성은 부인할 수 없습니다. 개인적으로 제 경험을 일반화하고 싶지 않습니다: 25년 전에 비슷한 플랫폼을 사용했던 경험이 있어, 이 유형의 도구와 그 복잡성에 익숙합니다. 그럼에도 불구하고, 매우 숙련된 관리자로서도 최근 몇 주 또는 몇 달간 업데이트의 빠른 속도와 그로 인해 발생하는 충돌, 특히 확장 프로그램과 플러그인 간의 충돌로 인해 다소 압도당하는 느낌을 받았습니다.

제 경험을 요약하자면, 주요 도전 과제는 빠른 업데이트 속도와 컴포넌트 및 플러그인 간의 버전 충돌에서 비롯됩니다. 제 견해에 따르면, Discourse의 복잡성과 때때로 혼란을 유발하는 설정은 이러한 빠른 개발 주기와, 소프트웨어가 오픈소스라는 사실(몇 가지 작은 단점이 있음에도 불구하고 엄청난 장점) 때문인 경우가 많습니다.

6개의 좋아요

아, 아직 그런 상황에 직면한 적도 없네요! :fearful:

그렇기를 바랍니다 – 제 경우에는 ‘제어’ 주체가 사람들이 이미 사용 중인 Facebook이기 때문입니다. 거기서 이주를 고려하기까지 이렇게 오래 걸린 주된 이유이기도 하죠…

카테고리와 태그가 어떻게 조직되는지도 커뮤니티 구성원이 직면하게 되는 아키텍처의 중요한 부분이므로, 커뮤니티 ‘구조’가 더 잘 설계될 수 있었음에도 그렇지 않다면 관리자가 겪는 어려움이 간접적으로 사용자들에게도 영향을 미칠 수 있습니다.

읽어주셔서, 그리고 답변해 주셔서 감사합니다!

8개의 좋아요

예를 들어 페이스북 그룹과 디스코urs는 구조 측면에서 근본적인 차이가 있다는 점은 사실입니다. 디스코urs는 포럼입니다. 적어도 대부분의 사람들이 이를 포럼으로 사용합니다. 저도 블로그 그리고 포럼처럼 조금씩 사용하는데, 가능하기 때문입니다. 모든 것은 청중의 과거 경험에 달려 있습니다. 청중이 포럼 구조에 대한 경험이 전혀 없다면, 페이스북에서 넘어온 경우 실제로 문제가 될 수 있으며, 이는 부정할 수 없는 사실입니다. 반면, 청중의 일부가 이미 포럼에 대한 경험이 있다면, 저는 디스코urs뿐 아니라 카테고리나 섹션을 가진 포럼 구조를 갖춘 모든 포럼을 말씀드리고자 합니다. 이는 꽤나 다른 문제입니다. 그들은 매우 쉽게 길을 찾을 수 있을 것입니다.

2개의 좋아요

특정 목표가 있는 경우가 아니라면 대부분은 보지 않는 것을 추천합니다. 그리고 필요한 경우 여기에서 도움을 요청하면서 한 단계씩 천천히 진행해 보세요.

맞아요, 가능성의 수가 엄청나고 더 잘 정리될 수 있었어야 합니다… 그리고 우리는 그 작업을 하고 있지만, 아직 갈 길이 멉니다. 현재 설정 옵션의 수는 한 사람이 마음속으로 모델링할 수 있는 범위를 초과하고 있습니다… 그래서 가능성에 압도당하는 것이 당연한 일입니다.

우리는 할 수 있습니다! 여기 있는 모든 게시물은 디스코urs를 개발하는 누군가가 읽습니다. 지난주에 작성하신 게시물을 읽은 후, 태그 페이지를 통해 직접 태그를 추가하는 기능을 작업하기 시작했습니다. 이 피드백을 여러 번 받아왔기 때문에 이제 시도해 볼 때가 된 것 같았습니다.

19개의 좋아요

불편하시군요. 설정이 정말 많거든요.

Discourse도 마찬가지입니다. 바로 게시물을 작성하기 시작할 수 있습니다. WordPress와 마찬가지로 카테고리를 만들 필요가 없으며, 기본 카테고리를 사용하면 됩니다. 만약 그것이 정말로 원하시는 것이라면, 두 플랫폼은 거의 동일한 수준입니다.

제가 파악하기로는 여러분이 원하시는 것은 고양이 데이터베이스를 구축하는 것 같습니다. 이는 어려운 일입니다. WordPress에서 이를 하려면 새로운 게시물 유형(post-type)을 생성해야 하고, 하나의 고양이가 여러 사용자에게 속하게 하거나 사용자가 여러 마리의 고양이를 소유하게 하려면 무엇을 더 해야 하는지 모르겠습니다. WordPress로 이를 구현해 달라고 한다면 10,000달러를 청구하겠습니다(단순히 WordPress를 싫어해서 그런 것입니다). Discourse로 구현해 달라고 한다면 1,000~2,000달러에 할 가능성이 높습니다. 이메일을 보낼 수 있는 수준을 넘어선 상당한 기술이 있는 사람이 없다면, Discourse나 WordPress 어느 쪽으로도 이를 구현할 수 없습니다.

간단한 고양이 데이터베이스 솔루션은 고양이 카테고리 하나와 템플릿 하나입니다. 두 사람이 같은 고양이를 좋아한다면, 이를 표시하기 위한 공식적인 메커니즘은 없습니다. 그냥 텍스트에 @katDude도 이 고양이를 좋아합니다라고 추가하고, KatDude에게 해당 토픽을 관찰(watch)하도록 하면 됩니다. 다른 방법은 사람들이 고양이의 이름으로 추가 계정을 만들도록 유도하는 것입니다. 그러면 그 사용자를 @mention할 수 있지만, 이는 매우 번거로운 일입니다.

하지만 여러분이 정말로 원하는 것은 고양이들을 위한 완전히 새로운 모델입니다. 그러면 @mention 대신 :cat: 멘션을 사용할 수 있게 됩니다. 정말 멋진 일이겠지만, 개발 비용이 증가할 것입니다.

3개의 좋아요

현재 단계에서는 외관이나 작동 방식에서 수정이 필요한 부분이 정말 많습니다. Discourse에 충분히 익숙하지 않아서 제가 시도하는 것이 설정에 의해 제어되는지, 테마(또는 컴포넌트) 수준에서 처리되는지, 아니면 플러그인 때문인지 종종 알 수 없는 것이 도움이 되지 않는 것 같습니다.

그렇게 들으니 다행이고, 정말로 그것이 큰 노력임을 이해합니다.

정말 그렇습니다! 바로 그겁니다. 솔직히 말하면, 제 '멘탈 모델링’에 저항하는 상황에 직면하는 데 익숙하지 않아서 이 상황을 잘 처리하지 못하고 있는 이유를 설명할 수도 있습니다.

와, 정말 좋은 소식입니다.

지금까지 당신과 다른 사람들의 댓글을 읽고 나니, 제가 ‘커뮤니티 멤버 경험’ 수준(제가 달성하려는 것)에서 제 문제점을 좀 더 평이하게 게시해야 할지, 아니면 반쯤 스스로 해결한 후에 더 ‘기술적인’ 질문을 해야 할지 고민이 됩니다.

또한 Discourse가 어떻게 작동하는지에 대해 제 머리가 어떻게 이해하고 있는지(제 '멘탈 모델’의 일부)를 명확히 하고 공유해 보겠습니다(도움이 된다면요).

제 곤경에 관심을 갖고 시간을 내어 주셔서 정말 감사합니다!

11개의 좋아요

네! Discourse의 거의 모든 것을 머릿속에 가진 몇몇 개인이 주변에 있다고 생각합니다. 더 일반적인 질문을 하신다면 그분들이 정확히 도움을 주실 수 있을 겁니다.

ask.discourse.com을 시도해 보셨나요? 이 곳도 이 부분에 있어 꽤 좋습니다.

8개의 좋아요

:slightly_smiling_face: 말씀해 주셔서 감사합니다!

그것은 정확하지 않다고 생각합니다. 두 도구 간의 비교에는 한계가 있으며, 저는 여기서 차이가 있다고 봅니다. WordPress는 블로그 도구로서 주로 블로그 게시물 작성에 초점을 맞춰 설계되었습니다. 반면 Discourse는 커뮤니티를 수용하도록 설계되었습니다. 커뮤니티 역학은 블로그의 작가-독자 관계보다 훨씬 복잡합니다.

물론 제 Discourse 커뮤니티를 기본 설정으로 회원들에게 개방하지만, 솔직히 말하면 회원들이 실제로 커뮤니티가 형성될 정도로 오래 머무를 가능성은 희박합니다. 반면, 제 순수한 WordPress 설치 환경에서는 블로그 게시물을 계속 작성할 수 있으며, 사람들이 많이 방문하지 않더라도 시간이 지나면 사람들에게 보여줄 수 있는 충분히 좋은 블로그를 갖게 됩니다.

사실 그것은 제 고민거리 중 하나가 아닙니다. 카테고리에 "고양이 파일"을 두는 것은 완벽하게 실행 가능한 옵션입니다(현재 Google Sheets로 고양이 한 마리당 하나씩 하는 방식의 확장입니다).

제 고민은 다음과 같은 것들입니다:

  • 카테고리 구조와 속성을 쉽게 실험하고 결과를 "확인"하지 못하는 것(도구를 통해 "생각을 소리 내어 표현"하는 것 – Canapin이 만든 시각적 인터페이스 목업은 분명히 이를 위해 필요한 종류의 것입니다)
  • 토픽, 카테고리 목록, 내비게이션, 어디에나 있는 다양한 위젯과 버튼의 시각적 레이아웃의 특정 측면을 제어하는 것이 무엇인지 쉽게 식별하지 못하는 것
  • 배지: 너무 많습니다. 완전히 없앨까요, 아니면 일부만? 어떤 것? "격려의 촉진"과 "쓸모없거나 혼란스러운 알림"으로 인식될 수 있는 것 사이의 적절한 균형은 무엇일까요?
  • 알림 및 경고: 앱에서, 이메일로… 다시 말하지만, 겨우 부화한 Discourse 인스턴스에서 24시간도 되기 전에, 제 모더레이터가 오늘 아침 첫 번째로 남긴 코멘트는 받은 편지함의 이메일 수에 대한 것이었습니다. 이메일 통합/알림을 자산으로 보고 있지만, 사람들이 스팸을 받는다고 느끼고 단순히 떠나지 않도록 하기 위한 적절한 균형은 무엇일까요?
  • 예상대로 작동하지 않는 사용자 정의 필드: 나중에 세분화할 생각으로 몇 개를 추가했지만, 현재 프로필에서 추가된 필드를 채워 넣는 장소를 찾지 못했습니다. 그래서 "나중에 세분화"는 아마도 잘못된 계산일 수 있다는 생각이 듭니다(아니면 제 프로필에서 사용자 정의 필드를 찾지 못한 것일 수 있으니, 그렇다면 우리 일반 회원들은 어떻게 찾을까요?).
  • 회원 온보딩: Facebook에서는 새 회원들이 고양이를 돌보는 "학습 여정"을 따라가도록 "촉진"하기 위해 게시물 시리즈를 진행합니다. 이는 엄청난 시간 소모이며, 매우 번거롭습니다. Discourse가 이를 자동화할 수 있다고 확신합니다(이미 조금 찾아보았습니다). 게시물 대신 메시지로 이 작업을 수행할까요? 적절한 “자동 응답기” 같은 것을 가동하기 위해 어떤 단계가 필요합니까? 무언가가 자리 잡았고 사람들이 Discourse 커뮤니티에 들어온 후 온보딩 프로세스를 조정하는 것이 얼마나 쉬울까요(아니면 어렵을까요, 카테고리 참조)?
  • 사용자 역할과 권한: Facebook에는 모더레이터와 헬퍼가 있으며, 모더레이션 팀은 특정 임무를 가진 작은 팀으로 구성됩니다. 일부는 새 사용자를 분류하고 환영 게시물을 작성합니다. 일부는 콘텐츠 모더레이션을 합니다. 일부는 초보자 그룹을 관리합니다. 일부는 헬퍼를 코칭합니다. 일부는 주기적인 온보딩 게시물을 위해 회원 목록을 준비합니다. 우리는 항상 Facebook의 매우 제한적인 사용자 역할에 의해 제한받는다고 느꼈고, Discourse는 우리가 다르게 할 수 있게 해줄 것입니다. 하지만 어떻게? 다시 말하지만, “설계”(어떤 역할, 그룹, 권한, 누가 어디에 배치되는지)와 “시스템 내 구현”(실제로 그룹, 설정, 회원 목록 등을 조정하는 것)이 있습니다. 그리고 우리 현재 조직은 내장된 신뢰 수준(trust levels)과 어떻게 기능하거나 충돌할까요? 진행 기준(progress criteria)이 우리 커뮤니티에 어떤 의미라도 있습니까?
  • 그룹 문서: 게시된 페이지(Published Pages)처럼 작동할 것 같지만, 기존 문서와 다소 일치하도록 제목 수준을 올바르게 스타일링하는 방법을 알아내야 합니다. 가져오기/이전을 어떻게 관리합니까? 수동으로 복사-붙여넣기해야 하는지, 아니면 이를 자동화할 방법이 있는 건지? 제가 모르는 것을 모른다는 것을 알 정도로 충분히 알지 못합니다. 영상도 마찬가지입니다: YouTube에 약 70개의 영상을 올리고, 각각에 대해 토픽을 만들어야 합니다: 자동화 솔루션을 찾는 것이 가치가 있는지, 아니면 수동으로 해야 하는지? 전혀 모르겠습니다.
  • 이런 종류의 것들 :face_with_peeking_eye: (AI 통합도 Discourse에 대해 이렇게 흥분하는 이유 중 하나인데, 아직 언급조차 하지 않았습니다…)

이미 성숙한 커뮤니티를 이전하고 있다는 사실도 고민에 추가되는 요인일 수 있습니다: 백지 상태에서 시작하여 커뮤니티 문화가 그 커뮤니티를 수용하는 도구와 공진화하도록 기회를 갖는 것과 전혀 다른 문제이기 때문입니다.

8개의 좋아요

예, 꽤 많이 사용해 봤습니다 (8월에 Discourse를 시험 사용했을 때요). 지금은 좀 덜 사용하게 되었는데, 솔직히 말씀드리자면 Meta의 특정 토픽으로 연결되는데 그 정보가 여전히 유효한지 불분명한 경우가 많거나, 스레드가 너무 길어서 절반도 읽기 전에 압도당하는 경우가 많기 때문입니다. 또한 챗봇으로 인한 딴 길로 빠지는 것(rabbit-hole)도 걱정됩니다(저는 그런 길로 아주 빠르게 빠져들기 때문이죠). 하지만 다시 한번 시도해 봐야 할지도 모르겠습니다.

반드시 그렇게 하겠습니다. 격려해 주셔서 감사합니다!

7개의 좋아요

그건 다른 문제입니다. 당신은 워드프레스를 시작해서 뭔가를 올릴 수 있다고 했잖아요. 저는 디스코스를 시작해서 뭔가를 올릴 수 있다고 말하는 거예요. 사람들이 계속 머물러 있게 만드는 블로그를 만드는 것도 뭔가를 올리는 것보다 훨씬 복잡합니다. 아마도 이 비유가 맞지 않는 것 같네요.

그리고 거의 10년 동안 디스코스로 생계를 유지해 왔지만 워드프레스의 가장 단순한 작업조차 할 수 없는 사람으로서, 저에게 물어보는 건 좋은 선택이 아닐 수도 있습니다!

하지만 네, 목록에 있는 모든 것은 꽤 어렵습니다. 특정 사람이 이메일을 얼마나 많이 원하는지 파악하는 것? 그리고 관리자가 알림을 받는 것에 화를 낸다면 새로운 관리자가 필요할 수 있어요—그들이 제 역할을 충실히 수행하고 항상 온라인에 있다면 브라우저에서 알림을 확인하므로 많이 받지 않을 테지만, 그 설정을 조정하는 것은 꽤 쉽습니다. 그리고 새로운 포럼의 경우 사람들이 사이트의 존재를 알게 하도록 많은 이메일을 보내는 것이 기본 설정인데, 이 중 많은 것들이 디스코스가 어렵게 만들기 때문이 아니라 본질적으로 어려운 문제이기 때문에 어렵습니다.

자동화된 알림(노딩)? 적절한 시기에? 그건 꽤 어렵습니다.

그건 제 전문 분야입니다! 하지만 데이터에 접근할 수 있을 때조차(페이스북에서 스크래핑하는 방법을 알아내기 전까지는 접근할 수 없으며, 그게 합법적인지조차 확실하지 않다고 생각하는데) 여전히 복잡합니다. 저는 현재 이주 작업을 엉망으로 처리한 누군가로 인해 생긴 문제를 정리하고 있는데, 이로 인해 모든 사용자들이 화가 나 있습니다.

네! 그건 훨씬 더 어렵습니다. 모든 사람에게 기대치가 있고, 특정 시스템의 끔찍한 부분조차도 그 기능이 사라지면 사람들이 화를 냅니다!

그러므로, 제가 디스코스를 위해 비합리적으로 방어적인 태도를 취하고 있고 더 쉽게 만들 수 있는 부분이 몇 가지 있긴 하지만, 제게는 여러분이 하려는 것의 상당 부분이 플랫폼이 무엇이든 간에 그저 단순하게 어려운 일일 뿐입니다.

6개의 좋아요

제 비유의 의도가 정확히 그건 아니었어요. 더 정확히 말하면 “도구가 기본적으로, 사용자가 필요로 하는 작업을 충분히 잘 수행하는가”(워드프레스: 블로깅; 디스코스: 커뮤니티)에 대한 것이었죠. 하지만 네, 비유에는 한계가 있고, 그걸 파고들면 끝없는 토끼굴에 빠질 수 있겠네요!

:joy:

물론 그건 알 수 없죠. 하지만 가장 많은 사람들을 만족시키거나 용인할 수 있는 설정이 무엇인지에 대해서는, 네 – 그게 바로 사용자 리서치가 제공하는 정보입니다(불행히도 제 커뮤니티에서 리서치를 수행할 수단이 없어서, 추정할 수밖에 없네요).

그녀는 화가 난 게 아니라, 그 문제를 지적한 거예요. 그리고 말씀하신 대로, 그녀는 자신의 알림 설정을 수정해야 한다고 언급했어요. 하지만 우리의 "평균 사용자"들은 그렇게 하지 않을 거예요.

여기가 바로 문제입니다: 제 모더레이터의 초기 피드백을 바탕으로 볼 때, 그 설정은 우리의 사용자 기반에게 너무 "간섭적/압도적"일 것이 분명해요.

그들이 어려운 문제라는 점에는 절대 부정하지 않아요. 하지만 그렇다면, 인터페이스가 어려운 문제를 다루는 것을 더 쉽게, 혹은 더 어렵게 만들 수 있죠. 디스코스는 제 커뮤니티에서 이 행동(이메일 전송)에 대한 명확하고 이해하기 쉬운 표현을 제공하지 않아요(혹은 제가 아직 못 찾았거나). 저는 긴 설정 목록을 보게 되는데, 더 사용자 스토리에 가까운 것이 필요해요. 설정 이름과 값 아래에 설명이 있다는 점은 감사하지만, 디스코스의 이 측면이 어떻게 작동하는지에 대해 이미 명확한 정신적 이미지를 가지고 있지 않다면(당신은 광범위한 경험을 통해 당연히 가지고 계실 테지만), 각각의 설정이 무엇을 하는지 이해하기가 매우 어렵습니다. 이 기능이 회원들의 도구 사용 경험에 어떻게 영향을 미치는지 그 이야기를 들려주고, 어떤 시나리오나 대안적인 이야기를 원하는지 물어보세요: 그러면 작동합니다.

참고로, 우리 문서들은 모두 구글 문서에 있고 페이스북에는 없어요(호기심 많은 분들을 위한 인덱스) 그리고 페이스북의 모든 비디오 게시물은 실제로 스크래핑되었어요, 합법적이든 아니든. 만약 제가 그 측면에 너무 신경 쓰였다면, 저는 고양이에게 인슐린을 얼마나 주어야 하는지 사람들에게 알려주는 커뮤니티를 운영하지는 않았을 거예요 :sweat_smile: – 그리고 솔직히 말해서, 페이스북에 관해서는, 정당한 우리의 콘텐츠인 것을 가져가는 것에 대해 어떤 양심적 고민도 하지 않을 거예요.

걱정 마세요, 이해해요 – 디스코스가 사람들이 열정을 가지는 도구라는 점이 정말 좋다고 생각해요. 그것은 자산이죠 :slight_smile:

코멘트와 피드백에 정말 감사드립니다!

8개의 좋아요

하지만 사용자가 몇 명 더 늘면 그렇게 시끄럽지 않을 것입니다. Understanding and managing bootstrap mode – 사실 이 기능은 기본적으로 새 사용자에게(대부분 관리자처럼 더 인내심이 많을 것으로 추정됩니다) 수백 통의 이메일을 보내도록 설정되어 있으며, 설정을 직접 변경하는 방법을 찾지 못하면 자동으로 그 강도를 낮춥니다.

아, 다행이네요! 똑똑한 누군가, 혹은 몇 가지 도구와 https://ask.discourse.com/ 의 도움을 받는 똑똑한 누군가가 이를 Docs 플러그인에 맞게 조정할 수 있을지도 모릅니다.

동의합니다. 그리고 저는 그들이 그 부분에서 대체로 좋은 일을 했다고 생각합니다. 또한 설정에서 검색 기능을 사용하는 법을 꼭 배워두세요. 설정 목록을 직접 살펴볼 일은 거의 없습니다. 검색창에 아무거나 막 입력해 보세요. 모든 설정의 이름, 설명, 값을 검색합니다. 정말 놀라운 기능입니다.

수정:

네, 그리고 여러분의 좌절감이 현실적이거나 정당하지 않다는 것을 시사하려는 것은 아닙니다. 다만, 그 문제들 중 어떤 것을 해결하기 위한 구체적인 실행 단계가 무엇인지 제가 명확히 파악하지 못하고 있을 뿐입니다.

6개의 좋아요

더 이상 덧붙일 말은 없지만, 자신의 이야기를 공유해 주시고 고민을 말씀해 주셔서 감사드립니다.

좋은 결과는 성공적인 Discourse 커뮤니티를 구축하는 것이겠죠. 그리고 더 큰 성과는 Discourse를 조정하여 이 과정을 더 쉽게 만드는 것입니다.

저는 가능한 한 최소한의 변경만 하고, 테마 컴포넌트도 하나만 추가했으며, 그것도 바로 적용하지 않았습니다. 비교적 기술적인 배경을 가진 대상 독자를 대상으로 했다는 점이 유리했지만, 적어도 한 명의 똑똑한 사람이 인터페이스에 혼란을 느꼈다는 것을 알고 있습니다.

제 접근 방식은 이랬습니다. 이전에 있던 것을 재현하려는 것이 아니라, 자신의 커뮤니티에 맞는 것을 만드는 것이 목표였습니다. 비교적 낮은 진입 장벽을 원했고, 사람들이 원하는 것을 쉽게 찾고 기여할 수 있기를 바랐습니다.

제 미니멀리즘 접근법의 일부는 카테고리를 상당히 적게 사용하고, 처음에는 태그에 신경 쓰지 않는 것입니다. 새로운 게시자에게는 어떤 카테고리를 선택할지가 마찰 요인이 되므로, 첫 번째 카테고리는 항상 범용(catch-all) 카테고리로 설정하고, 필요할 경우 관리자가 카테고리를 재분류할 수 있음을 명시합니다.

기본 보기에서도 실험을 해 보았습니다. 첫 화면은 카테고리 목록 또는 최신 게시글 중 하나를 선택할 수 있습니다. 저는 이 두 가지만 시도해 보았으며, 여러 번 변경했습니다.

제가 추가한 유일한 것은 Topic List Previews입니다.

Discourse의 다양한 주제 목록 레이아웃을 사용자 정의할 수 있는 테마 컴포넌트로, 기본적으로 썸네일 미리보기와 발췌문을 추가합니다.

이것은 목록 내 각 주제에 텍스트 조각과 이미지 썸네일을 추가하여 주제 목록을 더 매력적이고 스스로 설명이 되도록 만듭니다.

10개의 좋아요

처음에 설정 항목이 너무 많아 압도되는 감정이 얼마나 힘든지 충분히 공감합니다.

완벽함이 좋은 것의 적이 되지 않도록 주의할 것을 권합니다. 완벽한 세팅은 존재하지 않으며, 커뮤니티가 안정화되는 과정에서 시간이 지날수록 조정해야 할 부분이 생기기 마련입니다. 항상 조금씩 유동적일 수밖에 없습니다. 또한, 설계를 위해 투자한 시간 중 상당 부분은 서비스가 실제로 운영되고 사용자가 피드백을 보내기 시작하면 무용지물이 될 가능성이 매우 높습니다(저는 이걸 뼈저리게 배웠습니다!).

저희 커뮤니티에 도움이 된 것 중 하나는 베타 테스터 그룹을 두는 것이었습니다. 이들에게는 전용 그룹과 카테고리, 그리고 컴포넌트 테스트를 위한 특정 테마가 할당되어 있습니다. 지난 몇 년간 많은 훌륭한 피드백을 제공해 주었으며, 잠재적인 함정이나 제가 생각하지 못했던 부분들을 찾아내는 데 큰 도움이 되었습니다.

최소 기능 제품(MVP)으로 시작하는 것이 큰 도움이 될 것이라고 생각합니다. 사용자로부터 피드백을 받으면 필요에 따라 조정할 수 있습니다. 플러그인/컴포넌트를 추가하거나 제거하거나, 카테고리를 추가/제거하는 식으로 말이죠. 처음부터 완벽하게 다듬어진 카테고리 트리를 갖출 필요는 없습니다. 시간이 지나면서 어떤 방식이 효과적인지 배워나갈 수 있습니다. 만약 불안하다면, 정식 출시 전에 일부 사용자를 먼저 초대해 적응할 시간을 주고 피드백을 받는 것도 좋습니다. 디스코urs에 익숙한 사용자가 있으면 전환 과정에도 도움이 됩니다.

이 모든 과정은 커뮤니티가 자신의 디스코urs 인스턴스의 분위기를 함께 만들어가도록 허용하며, 그들에게 발언권을 주어 커뮤니티에 대한 소속감과 연결감을 더 크게 느끼게 해줍니다.

10개의 좋아요

왜 이런 작은 규모의 그룹을 자신의 하드웨어로 직접 호스팅하고 싶은지 물어봐도 될까요? 디스코르스(Discourse) 설치와 설정이 어렵다고 생각하신다면, 컴퓨터가 상하로 완전히 해킹당하지 않도록 24시간 365일 감시하는 역할을 누가 맡을 것입니까? 저는 컴퓨터 보안 분야 경력이 있으며, 솔직히 말씀드리면 연간 최소 100만 달러의 확실한 수익이 보장되는 서비스를 운영하는 경우를 제외하고는 절대 직접 서버를 호스팅하지 않을 것입니다.

개인 블로그를 운영하면서 이러한 위험을 감수하는 것은 별개의 문제입니다. 8,000명이 자신의 신원 보호를 당신에게 맡기고 있을 때는 완전히 다른 차원의 문제입니다. 해커가 사용자 데이터베이스를 탈취한 후 당신 명의인 것처럼 위장한 피싱 이메일을 대량으로 발송하기 시작하면 어떻게 하시겠습니까? 비밀번호를 재사용하는 사람들에게는 어떻게 설명하시겠습니까? 도난당한 비밀번호가 그 사람의 전 재산이 보관된 증권 사이트에서도 통용되는 경우 말이죠. 왜 그런 위험을 감수하시겠습니까?

컴퓨터를 적절히 보호하고 지속적으로 모니터링하는 데에는 연간 수십만 달러가 소요됩니다. 이를 직접 수행하는 사람들은 주로 프로그래머와 보안 전문가이며, 그들에게는 직업이자 취미이기도 합니다. 디스코르스에 월 20달러를 지불하고 보안 로그 모니터링, 백업, 업그레이드를 그들에게 맡기는 것이 훨씬 저렴합니다.

참고로, 페이스북 계정 정지 문제에 대해 시작하실 스레드에 대한 링크를 공유해 주시면 좋겠습니다. 저는 페이스북에서 15,000명 규모의 그룹을 운영 중인데, 3주간 계정이 정지되었습니다. 그 3주 동안 제 페이스북 콘텐츠가 모두 사라져 그룹이 완전히 혼란에 빠졌습니다. 이 일 하나로 인해 페이스북이 원인 없이 사람들을 무작위로 정지하는 통제 불능의 정신병적인 AI이며, 이러한 실수를 해결하기 위한 백엔드 시스템이 완전히 비기능적이라는 것을 깨달았습니다.

1개의 좋아요

감사합니다! 그리고 네, 확실히 그렇습니다. 저는 '완벽함이 좋은 것의 적’이라는 말에 크게 공감합니다. 다만, Discourse 관리자가 설정들을 제시하는 방식이 '완벽함’의 함정에 빠지기 쉽게 만든다고도 해야겠습니다.

오늘 아침 이 문제를 생각하면서, 새로운 관리자로서 ‘충분히 좋은’ 설정으로 나를 이끌어줄 것이 무엇인지 자문해 보았습니다. 커뮤니티 빌더로서 고려해야 할 다양한 '차원’에 대한 명확한 위계와 우선순위에 대한 감각이 제게는 부족합니다. 아마 이런 것이 존재하지만 제가 찾지 못했을 수도 있고, 아니면 커뮤니티를 구성하는 기능과 기능들의 고수준 '목록’이 있으면 좋겠습니다. 거기서 제게 중요하고 덜 중요한 것을 표시하면, 구현할 수 있는 어느 정도 사전 포장된 설정 컬렉션이 제안되길 바랍니다.

제 생각을 명확히 하기 위한 예시입니다(아마 이 아이디어를 더 발전시키기 위해 다른 게시물에서 더 생각해 봐야 할 것 같습니다). 신규 설치 시, 커뮤니티의 다양한 측면이 얼마나 중요한지를 묻는 체크리스트가 있으면 좋겠습니다:

  • 태그 또는 카테고리, 또는 둘 다를 사용하여 콘텐츠 구조화
  • 채팅을 통한 멤버 간 상호작용 허용
  • 시각적 디자인

이렇게 쓰면서 제 생각만큼 명확하지 않다는 것을 깨닫고 있습니다. 제 아이디어를 이해하기 쉬운 방식으로 제시하려면 더 생각해 봐야 합니다. 제가 염두에 둔 것은 기술적 설정이 아닌 '사용자 스토리’를 사용하는(인용부호를 쓴 것은 정확히 그렇게는 아니기 때문) 일종의 설정 마법사입니다. 이는 설정으로 번역하는 데 도움을 줍니다. 어쩌면 자연어 설명을 분석하고, 시작하기 위해 필요한 이 '단순 구성’을 안내하고 올바른 방향으로 유지하도록 설계된 AI 챗봇이 있을 수도 있습니다. 이 챗봇은 설정에 접근하거나 설정을 표시해 줄 수 있습니다. 'Ask Discourse’가 이 중 일부를 수행하는 것 같습니다…

(좋아요, 더 생각하고 돌아오겠습니다!)

이것은 제가 항상 하려 했던 방식과 매우 일치합니다. 그러나 제 어려움은 정말로 내 커뮤니티의 성격과 필요를 고려할 때, 이 최소 기능 커뮤니티 플랫폼에 도달하는 것입니다. 베타 테스터라는 당신의 아이디어는 제 머릿속에 그렇게 명확하게 형성되어 있지 않았던 것이므로 마음에 듭니다. 또한 새로운 구성 요소를 테스트하기 위해 전용 테마를 두는 것도, 제가 생각하지 못했던 것입니다.

제 생각에 많은 압력을 주는 한 가지는, Facebook에서 벗어나는 것에 대한 많은 저항이 있을 것이라는 점을 알고 있다는 것입니다. 많은 멤버들에게 '새로운 Discourse 커뮤니티’에 발을 들여놓은 첫 몇 분은 성패를 가를 것입니다. 그래서 저는 최소 기능 커뮤니티가 온보딩 및 Facebook과의 비교 사용에 대한 장벽이 되지 않도록 반드시 확인해야 합니다. 그렇지 않으면 사용자들은 와서 둘러보고 Facebook에 머물러 있게 될 것이며, 이는 제 마이그레이션 목표에 도움이 되지 않을 것입니다.

Facebook의 커뮤니티는 매우 윤활이 잘 되어 있고 효율적입니다. 또한 멤버들에게 이 경험을 주기 위해 백그라운드에서 많은 복잡성이 있습니다. 우리는 때때로 멤버들의 반려동물에 대해 생사가 걸린 상황을 다루고 있다는 압박감도 있습니다. 주제는 매우 민감하며 즉각적인 현실 세계의 결과와 밀접하게 연결되어 있습니다. 그래서 이것도 제가 고려하는 사항입니다. 커뮤니티 참여의 기술적 측면이 우리 멤버들에게 너무 큰 장벽이 되면, 동물들이 고통을 받고 죽게 될 것입니다 – 물론 모든 동물은 아니지만, 그것이 최종 결과입니다. 그리고 우리 커뮤니티 참여의 용이성 벤치마크는 Facebook입니다.

명확히 하기 위해, 위에서 언급한 우리의 역할에 대해 누군가 우려한다면: 우리는 '모든 사람을 구할 수 없다’는 것을 알고 있습니다 :sweat_smile: 그리고 반려동물 소유주에게는 수의사가 있습니다. 하지만 우리는 틈새 질병에 대한 주요 프랑스어권 자원입니다 – 많은 수의사들도 그들의 고객을 우리에게 보내고, 그들 스스로도 우리 커뮤니티에 가입합니다. 우리는 ‘단순히’ ‘공통 관심사’ 커뮤니티가 아닙니다. 그런 것이 잘못된 것도 아니고, 어떤 커뮤니티든 그 주제와 관계없이 멤버들의 삶에 실제 중요한 영향을 미치지 않는다는 것도 아닙니다. 그리고 이것이 커뮤니티 빌더/설립자/매니저로서의 제 역할과 책임에 대한 제 시야에 영향을 미친다는 것을 인식하고 있습니다. (그러니 우리는 토끼 구멍으로 빠져들지 맙시다: 저는 치료사를 두고 있습니다 :sweat_smile:, 그리고 이 커뮤니티에 대한 개입과 책임, 그리고 무엇을 놓아야 하는지에 대한 질문을 8년 동안 상당히 성공적으로 다뤄왔습니다 :face_with_peeking_eye:.)

따뜻하고 사려 깊은 메시지 덕분에, 지금까지 제 '관리자 경험’에서 무엇을 놓쳤는지를 더 명확하게 파악할 수 있었고, 그것을 우회하고 다른 방식으로 파악할 아이디어를 얻게 되었습니다. 정말 감사합니다 :hugs:

6개의 좋아요

따라서 저는 이 문제를 단순히 ‘적절한 기능’을 갖추는 것이라기보다는, 오히려 조직화(organizing)의 문제로 보고 있습니다.

제가 말하는 조직화란, 사용자들이 이 플랫폼으로 넘어오도록 하는 캠페인을 개발해야 한다는 뜻입니다. 앞서 언급했듯이, 커뮤니티 전체에 공개하기 전에 신뢰할 수 있는 사용자들이 먼저 참여하여 테스트하도록 하는 것이 좋습니다. 커뮤니티의 자연스러운 리더들, 즉 열정적으로 환영의 손길을 내밀 수 있는 커뮤니티 챔피언들을 찾아내야 합니다. 이들에게 설치를 테스트하게 하고, 몇 가지 말하기 포인트(talking points)를 제공하며, 사용자들이 이 플랫폼으로의 이동을 기대하게 만드는 ‘접종(inoculate)’ 역할을 하게 하세요. 그리고 런칭 시점에 이 그룹이 바로 ‘환영 인력(welcome wagon)’이 되도록 하십시오.

초보자를 위한 견고한 사용 가이드는 정말로, 정말로 집중해야 할 부분입니다. 사실, 저는 이 부분에 거의 모든 것보다 우선하여 집중할 것입니다. 특히, 디스코스에서 사용자가 페이스북에서 하던 것과 동일한 작업을 어떻게 수행할 수 있는지를 보여주는 표와 같은 것이 필요합니다. 단계별 안내(walkthrough)는 매우, 매우 도움이 될 것입니다. 사용자들의 기술 수준이 낮다면, 페이스북에서 하던 특정 작업을 디스코스에서 수행하는 방법을 보여주는 짧은 비디오를 녹화하는 것도 고려해 보세요. 이메일은 마찰 요인의 한 가지로 언급되었는데, 바로 이런 내용을 단계별 안내에 포함해야 합니다. 이메일에 대한 사용자의 반응을 예측하려 하기보다는, 사용자가 알림 설정을 스스로 할 수 있도록 안내함으로써, 모든 사용자에게 완벽하게 맞추려 한다는 심리적 부담에서 벗어날 수 있습니다.

진심으로, 태그나 카테고리 구조화처럼 콘텐츠 구조를 결정하는 데 훨씬 더 적은 시간을 보내고, 첫인상을 최대한 좋게 만드는 데 매우 집중해야 합니다. 나중에 언제든(그리고 항상) 조정할 수 있지만, 환영의 기회는 단 한 번뿐입니다. 사용자가 진심어지고 열정적으로 의미 있는 방식으로 환영받으면, 주변의 거친 부분들은 일반적으로 너그럽게 봐줍니다.

런칭 날짜를 염두에 두고 있다면, 런칭 전에 디스코스에서 할 수 있는 멋진 기능들(우연히도 페이스북에서는 할 수 없는 것들)을 홍보하는 티저를 몇 가지 준비해 보세요. 이 과정에서 페이스북을 깎아내리지 않는 것이 중요하며, 페이스북의 나쁜 점보다는 디스코스의 좋은 점에 초점을 맞추되, 사용자가 기대할 수 있는 것들을 보여줘야 합니다. 사람들이 이 플랫폼으로의 이동을 기대하게 만드세요. 그리고 런칭 날짜가 없다면, 역산(backwards plan)하여 홍보할 수 있도록 날짜를 정해 두는 것이 좋을 수 있습니다.

런칭 후, 환영 인력이 페이스북의 자주 방문하는 사용자와 체크인(check-in)을 하도록 하세요. 잘 적응하고 있는지? 도움이 필요한지? 열정적이고 새로운 경험을 즐기는 사용자를 찾아내고, 그 에너지를 전파하도록 격려하세요.

아마도… 더 나은 표현을 모르겠지만, 이 이사에 대해 불평불만(cranks)을 늘어놓는, 그냥 현실적인 ‘네거티브 넬리(Negative Nellies)’인 사용자들이 있을 것입니다. 이 태도를 즉시 중화시키는 데 최선을 다하세요. 이런 유형의 사용자는本该 흥분해야 할 일을 무겁게 만드는 큰 분위기 망치기(mood killer)가 될 수 있으며, 다른 사용자들도 끌어내릴 수 있습니다. 환영 인력이 이런 사람들을 따로 불러 그들의 문제를 해결하거나, 적어도 그들의 발작(tantrums)을 진정시킬 수 있도록 준비를 시키세요. 이런 사용자가 전혀 없을 수도 있지만, 저는 모릅니다! 하지만 솔직히 제가 해본 모든 이식 작업에는 항상 최소 한 명은 있었습니다.

작성하신 게시물에서 제가 느끼는 바는, 그리고 제가 틀렸다면 용서해 주십시오, 지식 있는 사람과 함께 앉아 필요 사항을 논의하고 설정 과정을 코칭 받는 것이 도움이 될 수도 있다는 것입니다. 설정이 너무 많아서 부담을 느낄 때, 이렇게 대화하는 것이 정말로 도움이 됩니다. 그냥 때로는 대화를 나누는 것이 더 쉽기 때문입니다.

커뮤니티를 위해 이 공간을 만들기에 얼마나 많은 생각과 정성을 쏟고 있는지 정말로 감탄스럽습니다!

6개의 좋아요

그렇고 말입니다 – 두 가지 사이에 명확한 구분이 있을까요? 기능과 도구는 조직화를 촉진하기도 하고 방해하기도 합니다. 제가 사용하는 이메일 클라이언트나 캘린더에 따라, 도구의 기능 덕분에 이메일이나 캘린더를 "관리"하는 것이 더 쉬울 수도 있고 더 어려울 수도 있습니다.

어떤 도구를 사용하여 "조직화 아이디어"를 구현하려고 할 때, 사용자가 설정을 찾으려 해도 직관적이지 않거나 찾기 어려우면, 조직화가 더 어려워집니다.

네, 맞습니다. 그리고 그것은 이미 진행 중이며, 제가 고군분투하는 부분은 아닙니다. 솔직히 말해서, 제 커뮤니티의 "사람들의 이주(people migration)"에 대한 도전과 그것을 어떻게 수행할지에 대한 제 비전은 현재 단계에서 "충분히 좋다"고 생각합니다. 제 문제는 한쪽으로는 제가 가진 아이디어를 도구 측면에서 실현시키기 위해 설정/구성으로 어떻게 번역할지 파악하는 것이고, 다른 한쪽으로는 도구가 무엇을 하는지, 그리고 너무 많은 마찰 없이 시행착오를 통해 제 아이디어를 정교화할 수 있도록 하는지에 대한 명확한 그림을 그리는 데 어려움을 겪고 있다는 것입니다.

이주에 대한 당신의 실용적인 조언은 정말 감사하게 생각하고 있으며, 그것은 확실히 사물을 접근하는 올바른 방법이지만, 저는 이미 그 작업을 하고 있습니다.

그렇습니다 – 그리고 이것이 제가 여기서 커뮤니티를 "활용"하려는 방식입니다. 어느 정도는 효과가 있지만, 다른 때는 약간 좌절스럽기도 합니다 (그리고 제 커뮤니티의 새로운 멤버들이 때때로 어떤 기분을 느낄지 깊이 생각하게 만들기도 하죠!). 제가 특정 사항들이 복잡하다고 느끼거나, 제가 겪고 있는 문제의 정확한 성격을 적절히 전달하지 못하고 있다고 표현할 때, 그 결과는 더 많은 정보, 더 많은 선택지, 또는 "문제는 나 자신이다"라는 느낌을 갖게 되는 경우가 많기 때문입니다. (그리고 물론, 아마도 어느 정도는 문제가 나 자신일 수도 있겠죠.)

"Discourse 전문가"와 1:1로 이야기를 나누거나 구현에 대해 걱정해 줄 수 있다면 정말 좋을 것입니다. 제 머리 속에서는, 그리고 블로그 공간에서 10년이나 20년 전 이 역할을 수행했을 사람으로서, 이것은 컨설팅 업무입니다. 자신의 네트워크에서 맛있는 식사와 교환할 의사가 있는 그런 행운의 사람이 없는 한요. 하지만 그런 사람이 없다면, 온라인 지원 커뮤니티가 존재하는 이유가 바로 그것 아닙니까? :sweat_smile:

(읽고 계신 분 중 이 영감을 받아… 하지만 솔직히 말해서, 제가 잘 모르는 사람에게 요청할 것이라고 생각하지는 않습니다…)

감사합니다!!

5개의 좋아요

혹시 제가 오해를 하고 있는 건 아닌지 모르겠는데, VPN 클라우드 서버가 "제 자신의 하드웨어"라고 보시는 건가요?

그렇다면 기본적으로 컴퓨터 보안에 대한 탄탄한 배경이 없는 사람은 디스코urs(Discourse)를 셀프 호스팅해서는 안 된다는 말씀이신가요?

제 생각에는 제가 하고 있는 일을 오해하신 것이거나, 셀프 호스팅 자격이 있는 사람에게 "요구 사항"을 제시하고 계신데, 그 기준이 상당한 규모의 기업을 운영하는 사람을 제외하고는 거의 모든 사람을 배제하는 것 같습니다. 메타(Meta)에서 활동하던 시절의 제 경험상, 셀프 호스터 모두의 프로필이 그런 것은 아니었습니다 – 아니면 제가 완전히 착각하고 있는 건가요?

제 커뮤니티의 필요를 충족시키기 위해 월 20달러 플랜이 충분했다면, 저는 셀프 호스팅을 하지 않았을 것입니다.

제 경험과 정확히 같은 것 같습니다! 이 게시물에서 제 블로그를 파보실 수 있습니다… 읽어보시길 권합니다 :sweat_smile:

6개의 좋아요