의외로… 많은 사람들이 포럼이 무엇인지와 어떻게 사용하는지 제대로 이해하지 못하는 것 같습니다.
저는 제 디스커스 사이트의 매력이 널리 퍼지기를 진심으로 원합니다.
그래서 궁금한 점이 있습니다. 여러분은 온보딩 과정에서 a) 방문객들이 사이트를 더 오래 머물게 하고, b) 포럼이라는 개념을 전달하여 사람들이 기여를 시작하고 자신감을 가질 수 있도록 어떤 방법을 사용하시나요?
어떤 조언이든, 이 부분을 잘 해내는 포럼의 사례든, 혹은 아이디어가 무엇이든 감사히 받아들이겠습니다.
미리 감사합니다!
여기서 무슨 뜻인지 제가 알고 있다고 생각하지만, 이 부분에 대해 좀 더 맥락이나 세부 내용을 알려주실 수 있을까요?
어떤 주제와 어떤 커뮤니티와 함께 일하느냐에 따라 달라질 것 같아요. 예를 들어, 저는 지식 베이스를 관리하는데, 플랫폼을 소개하고 사람들이 플랫폼을 잘 이해할 수 있도록 가상 미팅을 몇 번 진행했습니다. 플랫폼을 사용하는 데 자신감을 가질 수 있도록 돕고, 어떤 것을 게시할 수 있고 어떤 것은 허용되지 않는지를 교육했으며, 문제가 생기면 언제든 도와주겠다고 알렸습니다.
혹시 업무 관련이 아닐 수도 있지만, 제 경험이 몇 가지 아이디어를 드리는 데 도움이 되길 바랍니다!
행운을 빕니다!
안녕하세요 @jamesbrooks
흥미로운 주제네요. 2년 전에 질문하신 그 문제에 대해, 지금은 어떻게 생각하시는지 궁금합니다. 
가장 중요한 것은 전문적인 헬프데스크를 단순히 기다리는 것이 아니라, 커뮤니티와 커뮤니티 구성원들이 서로 돕는 것의 중요성을 항상 강조하는 것이라고 생각합니다.
그 방법 중 하나는 “DEAR SUPPORT” 같은 표시를 발견했을 때, “Dear Community,”(친애하는 커뮤니티 여러분)로 수정하고, 관련 표현들도 함께 다듬어 주는 것입니다.
또 다른 중요한 방법은 활발하게 활동하며 도움을 주는 구성원들의 기여를 강조하는 것입니다. 저희는 긍정적인 커뮤니티 기여를 장려하는 월간 게시글을 운영하고 있습니다.
여러분의 의견을 기다리겠습니다.
감사합니다!
질문 OS에 대해 생각하다가, 이 앱에 대해 전혀 모르는 사람들을 어떻게 찾는지 궁금해졌습니다. 저는 여기에서 처음이라, 온라인에서 쉽게 딴생각을 하고 이것저것 검색하고 읽다가 이런 것들을 우연히 발견하게 됩니다. 하지만 이런 디스커스를 어떻게 찾아내는 걸까요? 대부분의 사람들에게는 입소문으로 알게 되는 건가요?
사이트가 잠재적 회원들에게 잘 노출되는 것은 분명히 중요하다고 생각합니다. 다만, 이 주제가 다루고 있는 내용과는 약간 다른 주제라고 생각해요.
검색을 통해 해당 논의에 더 적합한 주제를 찾으실 수 있을 겁니다. 
좋은 질문입니다. 일반 사용자들을 위한 온보딩을 어떻게 진행할 것인가는 큰 도전이 될 수 있습니다.
Discourse의 핵심 개념은 "커뮤니티"인 것 같습니다. 따라서 누군가가 가입한다는 것은 커뮤니티에 기여하고 참여할 기회를 얻는 것을 의미합니다.
제가 고려하고 있는 전략 중 하나는 잠재적 고객들이 함께 일할 수 있을지 평가하기 위한 스크리닝 과정의 일환으로, Discourse 계정을 생성하도록 요구하는 것입니다. 정책은 다음과 같습니다: 계정을 생성할 의사가 없다면 그들과 협력할 수 없습니다.
다른 분들도 이 전략을 시도해 보셨는지, 혹은 다른 전략을 추천하시는지 궁금합니다.
나이가 좀 있으시지만 지적인 한 분께서 제 포럼이 어떻게 돌아가는지, 어떻게 사용하는지 이해하지 못하신다고 말씀하신 적이 있습니다. 혹시 첫인상을 기억하실 수 있는지 여쭤볼까 합니다.
제게는 포럼의 계층 구조가 명확해 보이지만, 물론 모든 사람에게 그런 것은 아닙니다.
한 시점에는 여러 활성 토픽이 존재하며, 관심 있는 토픽을 클릭해야만 최신 댓글을 볼 수 있습니다.
현재 비활성 상태인 오래된 토픽들도 표시됩니다.
각 토픽에 직접 들어가지 않고는 최신 댓글을 볼 수 있는 방법이 없습니다.
구조에 대한 유용한 일반적인 설명입니다. 상당히 명확해 보이지만, 항상 그렇게 명백하지는 않을 수 있습니다.
활동적인 대화가 진행 중인 디스코urs(Discourse) 사이트를 처음 보는新用户에게 있어, 계정을 생성하고 답변을 작성하는 것은 매우 쉽습니다. 주요 사회관계망 서비스(SNS) 플랫폼에서는 새로운 그룹에 가입할 때 새 계정을 만들 필요가 없지만, 독립적인 사이트로 운영되는 디스코urs와 같은 새로운 플랫폼에서는 계정을 생성해야 한다는 점이 많은 사람들에게 가장 큰 장벽이 될 수 있습니다.
저에게 디스코urs를 통한 소통의 가장 중요한 장점은 사적인 공간이 아닌 공공 영역에서 대화할 수 있는 기회입니다. 자신의 관점과 완전히 다른 관점을 가진 사람과 이메일이나 전화로 소통하려 할 때, 소통은 크게 제한될 수 있습니다. 누군가가 무엇을 이야기하는지 이해하려면, 대화에 더 많은 외부적 관점이 필요할 수 있습니다.
안녕하세요, @Francisco_Blackburn님.
흥미로운 질문이네요. 저는 이것이 온보딩 계획의 일부라고 생각합니다. 사용자들이 어디서 오는지 파악하는 것이죠. 우리는 커뮤니티가 메인 웹사이트와 소셜 사이트, 그리고 뉴스레터 등 모든 곳에 언급되도록 합니다.
질문에 답하고 해결책을 찾기 위해서는 완전한 "사용자 여정(user journey)"을 파악해야 합니다. 포럼의 존재를 인지하는 시점부터 활발한 커뮤니티 멤버가 되는 순간까지의 사용자 여정을 이해하게 되면, 사용자를 유치하고 가입 및 참여를 돕는 방법에 대한 이해를 갖게 될 것입니다. 세부 사항은 특정 사용 사례와 커뮤니티의 유형에 따라 달라집니다.
물론 긍정적인 경험과 구전은 때로 가장 좋고 가장 충성스러운 동맹군이 될 수 있습니다.
안녕하세요, @Architect님.
온보딩 계획 내 스크리닝 프로세스에 대해 더 알고 싶네요. 어떤 전략이나 질문을 사용하시나요? 질문을 답변하지 않거나 프로필을 완성하지 않는 경우 어떻게 하시나요? 가입은 하지만 비활성 상태로 남아있는 사람들이 있는가요, 아니면 결국 함께 일할지 말지를 선택해야 하는 “유료” 사이트인가요?
관심은 있지만 계정 생성에 주저하는 사람들이 있을 수 있습니다. 이 경우 우리는 때로 디스커스 초대 링크를 사용합니다.
안녕하세요, @Ed_S님.
좋은 지적이시네요. 핵심 아이디어에 대한 단순화된 관점을 가지는 것이 좋습니다. 첫인상은 모든 것이며, 저는 이러한 통찰이 디스커스를 사용하는 모든 사람에게 중요하다고 생각합니다.
‘고정된 주제(pinned topics)’, 카테고리 순서 및 설명, 배너 등 당신이 언급한 과제들을 돕는 도구들이 있습니다. 저는 모두 사용해 봤지만, 현재는 온보딩 계획의 다른 부분들, 예를 들어 그들이 처음 받는 메시지, 이메일 레이아웃, 튜토리얼 등을 조사하고 있습니다.
안녕하세요, @gassim,
새로운 사용자 계정이 특정 질문에 답하거나 프로필 정보 필드를 모두 완성하도록 요구하지 않습니다. 계정을 만드는 새로운 사람들에게 소개를 위해 몇 가지 스크리닝/면담 질문을 하는 것이 현명할 수 있습니다.
또한 사이트에는 유료 장벽(paywall)을 설정하지 않았습니다. 유료 모델도 좋지만, 무료 멤버십 옵션을 제공하는 것도 좋습니다.
건물 설계 및 건설 관련 작업 프로젝트는 논의할 내용이 많으므로, 공식적인 소통을 위해 Discourse와 같은 플랫폼을 통해 의사소통할 수 있도록 하는 것이 필요할 수 있습니다.
효과적인 온보딩 프로세스가 사용자 참여도에 큰 차이를 만들 수 있다는 것을 알게 되었습니다. 새로운 회원들을 위한 가이드된 소개를 제공하는 것이 효과적인 접근법 중 하나인 것 같습니다. 이는 일종의 ‘포럼 투어’와 유사하며, 참여의 이점을 강조하고 포럼의 구조를 설명하며, 가치 있는 토론의 예시를 보여줍니다. 또한, 포럼에 익숙하지 않은 사용자들이 과정을 더 쉽게 이해할 수 있도록 게시와 참여에 대한 팁이 담긴 환영 메시지나 스타터 키트를 보내는 것도 도움이 될 수 있습니다.
이걸 어떻게 알아차리게 되었는지 좀 더 자세히 알려줄 수 있을까요? 온보딩을 언제 시작했고, 어떤 계기로 시작하게 되었나요?
온보딩을 제대로 해내는 건 정말 어려운 일이라, 성공적인 구현 사례가 있다면 더 알고 싶어요
@Sustainability-Yogi 님, 이 주제에 대한 메모도 읽어보고 싶어요.
사이트를 새로 만들기 위해 가입한 초보 사용자로서, 단순한 소개의 필요성에 대해 언급한 첫 번째 게시글이 바로 이 글이었습니다. 이 시스템은 매우 강력하고 견고하지만, 숙련된 기술자임에도 불구하고 어디서부터 시작해야 하는지, 도움을 구할 곳이 어디인지 완전히 혼란스럽습니다. 카테고리倒是 많지만, 시작하는 법, 기초를 배우는 방법, 복잡한 질문이 있을 때 실시간으로 도움을 받을 수 있는 곳을 알려주는 단 하나의 명확하고 잘 홍보된 문서가 없습니다. 며칠이나 일주일씩 모든 문서를 읽을 시간은 없거든요. 실시간 채팅 지원이 있기를 기대했지만, 아직까지는 찾을 수 없으며, 도움을 받을 수 있는 디스코드 커뮤니티조차 없습니다. 개발자 카테고리에 가 보면 4개월 미만 된 게시글이 몇 개 있을 뿐입니다. 온보딩 과정에 훨씬 더 많은 주의를 기울여야 한다고 생각하며, 마침내 시스템을 배포하게 되면 일부 자원을 그쪽에 투입할 계획입니다. 한편으로, 커뮤니티 멤버들이 답변할 가능성이 높은 랜덤한 질문을 할 수 있는 최적의 장소를 알려주실 수 있나요? 미리 감사드립니다!
여기에 적합한 카테고리입니다. 사용자 및 관리자 문서를 최소한 읽어본 사람들이 답변을 주는 경우가 꽤 많습니다. 개발 관련 질문을 하기 전에 먼저 알아두어야 할 내용들이기 때문이죠 
저는 잘 모르겠습니다. 첫 포럼을 시작하기 전에 약 15분 정도 읽어본 적이 있습니다. 물론 그 후에도 더 깊이 파고들어야 했던 상황이 있었지만, 그건 더 많은 시간이 필요했을 수 있습니다. 하지만 절대 2주나 걸린 적은 없었습니다.
하지만 한 가지 이해가 안 되는 부분이 있습니다. 이렇게 소리 내어 말하는 것이 미안하지만. 사용자와 관리자 도움말 및 문서를 읽을 시간이 없는 사람에게, 24/7 항상在那里(there) 있어야 할 사용자들이 같은 순간에 도움을 주기를 바라며 디스코드 채널을 원하신다는 건가요 — 아니면 목적에 맞게 만들어진 포럼에서 질문을 하라는 건가요 
아니면 제가 무언가를 오해한 걸까요?
그것이 왜 문제가 되나요? 많은 문서 주제가 꽤 오래되었습니다. 마지막으로 업데이트된 시기를 확인하는 것이 더 좋습니다. 그리고 해당 주제 아래에 질문을 하면 종종 별도의 주제로 분리됩니다.
Support 채널은 질문하기에 좋은 곳입니다. 하지만 그렇다고 문서를 읽어야 할 의무가 면제되는 것은 아닙니다. 그런 경우에는 Marketplace 채널에 게시글을 올려서 도움을 줄 사람을 고용하는 것이 더 나은 선택이 될 수 있습니다.
Jakke, 이 문제에 대해 좀 더 일찍 답변드리지 못한 점 사과드립니다. 저희 프로젝트에 Discourse를 도입하기로 결정한 것이 아주 최근 일이었기 때문입니다. 여러 분들의 평가를 받아보기까지 시간이 좀 걸렸습니다.
또한 제 게시글을 좀 더 세심하게 다듬지 못한 점도 사과드립니다. 본래 무분별한 불평보다는 건설적인 비판의 의도가 더 컸는데, 제 개발자 중 한 명이 저와 정확히 같은 경험(빠르게 적응하기가 매우 어렵다는 점)을 한 직후라 서둘러 작성한 것이었습니다. 님처럼, 저와 그 개발자 모두 15분 만에 포럼을 만들어 봤습니다. 하지만 그것은 우리가 수일 동안 답변을 찾으려 애썼지만(매우 성공적이지는 못했지만) 수많은 질문의 시작에 불과했습니다. 이후 Discourse를 평가해달라고 부탁한 다른 몇몇 사람들도 비슷한 경험을 했다는 점을 확인해 주었기에, 우리의 경험이 비록 완전히 전형적이지는 않았더라도 어느 정도 타당성이 있다고 느낍니다.
이 모든 것이 제게는 그리 새로운 일이 아니었습니다. 오픈소스 프로젝트와 함께 일해 온 수년간의 경험을 통해, 개발자와 커뮤니티는 신규 사용자가 어떤 경험을 하거나, 얼마나 잘 이해하거나, 얼마나 빠르게 처리할 수 있는지에 대해 많은 것을 당연하게 여기는 경향이 있다는 것을 배웠습니다. 수년간 많은 분들이 첫인상이 중요하다고 말해 주었고, 저는 그 인상을 표현하고자 했습니다. 도움을 주고 싶었지만, 제 글과 반응들을 보니 전제 조건을 충분히 설명하는 데 시간을 할애하지 못했음을 깨달았습니다. 님의 답변 덕분에 앞으로는 그런 실수를 하지 않을 수 있을 것입니다.
현재 저는 Discourse에 깊은 인상을 받았고, 우리의 크고 야심 차며 중요한 프로젝트에 적합한 선택이라고 생각합니다.
앞으로 진행하면서 논의할 노트, 버그, 문제점 목록이 점점 늘고 있으며, 표현 방식에 훨씬 더 신경 쓰려 합니다. 저는 이런 종류의 프로젝트에 25년 이상 관여해 왔으며, 제 관찰, 통찰력 및 버그 리포트가 대부분의 프로젝트와 그 개발자들에게 환영받는다는 것을 잘 알고 있습니다. 아쉽지만, 이번과 같은 초기의 유감스러운 실수 없이 그런 대접을 받기는 어렵습니다. 이 점 너그러이 용서해 주시기를 바랍니다