10개의 게시글이 새로운 주제로 분리되었습니다: I’m considering moving a writing community to Discourse
저는 이전에 Circle에 대해 들어본 적이 없는데, 웹사이트를 살펴본 바로는 자체 호스팅 옵션이 없는 유료 서비스인 것 같습니다. 따라서 대부분의 사용자가 구독을 구매하면서 서비스를 시작한다고 추측합니다.
비슷한 사용자들이 discourse.org를 열면 $100부터 시작하는 가격을 보게 되는데, 이는 여기에서 언급된 작은 사용자들과 커뮤니티에게는 감당할 수 없는 금액입니다. 또한 대부분의 일반 사용자들에게 '오픈소스’라는 단어는 텅 빈 화려한 buzzword(유행어)에 불과하므로, '오픈소스 → 무료로 실행할 수 있다’는 함의를 따라가지 못합니다. 저는 실제로 Discourse에 대해 듣고 웹사이트를 방문한 후, "$100 이상의 서비스"라고 생각하며 떠나버린 사람을 꽤 많이 알고 있습니다.
저는 CDCK를 탓하지 않으며, '무료로 자체 호스팅할 수 있다’는 아이디어를 더 명시적으로 제시해야 한다고 주장하려는 것도 아닙니다. 이는 단지 추가적인 맥락과 관점을 제공하기 위한 것입니다.
4개의 좋아요
“네 번째 열을 추가해서 굵은 글씨로 ‘무료’라고 쓰라고”라고 말했어야 했는데, 아시다시피 요즘 일반 사용자들은 본문을 읽지 않고 제목이나 굵은 글씨만 가끔 읽거든요.
1개의 좋아요
하지만 물론 직접 호스팅을 운영하는 것은 결코 '무료’가 아닙니다. 유료 인프라가 필요하며, 이를 위해 노력과 학습이 요구됩니다. 이 두 가지는 모두 시간이 소요되며, 그 시간은 다른 유급 업무에 투입될 수 있는 시간을 대체하게 됩니다.
커뮤니티를 잘 운영하는 것은 특히 시간 소모가 큽니다.
하지만 이전에도 말씀드렸듯, 이는 매우 보람 있는 활동이며, 온라인, 엔지니어링, 비즈니스 관련 다양한 기술을 습득하는 데 훌륭한 출발점이 됩니다.
9개의 좋아요
그렇다면 첫 번째 열은 어떻게 다시 작성하시겠습니까?
1개의 좋아요
데이터를 다른 포럼으로 가져갈 수 있는 옵션도 없는 것 같아서, 만약 커뮤니티가 거기서 시작된다면 거기서 끝나게 될 겁니다.
8개의 좋아요
여기서 논의되고 있는 작은 사용자들과 커뮤니티에게는 얼마가 부담 없이 가능한 가격이라고 생각하시나요?
4개의 좋아요
죄송합니다, 방금 랜딩 페이지 하단의 가격 블록이 가격 페이지의 것과 다르다는 걸 알게 되었습니다.[1]: Discourse pricing | Discourse - Civilized Discussion. 두 가지가 다른 이유가 있을까요?
물론이죠! 그래서 제가 그 부분에 대해 논쟁하고 싶지 않다고 한 것입니다. 많은(매우 많은) 사람들에게는 직접 해결책을 찾는 것보다 누군가에게 문제를 해결하게 하는 것에 비용을 지불하는 것이 더 선호되기 때문입니다.
미국 사용자/고객에 대한 제 경험은 매우 제한적입니다. 유럽에서는 시작 플랜으로 약 20~30달러, 아시아에서는 10~20달러를 예상해 봅니다.[2]
관련해서, 제가 일했던 사람들 중 온라인 토론 플랫폼을 고려해 본 사람들은 사용자들이 왜 커뮤니티에 기여하고 싶어 하는지(즉, 포럼이 어떻게 살아남고 성장할지)와/또는 그것이 실제로 그들의 경우에 적합한지라는 명확한 비전을 거의 갖고 있지 않았습니다. 그들은 소규모 기업/집단이었으며, 소프트웨어/웹 솔루션을 접근하는 방식은 "X가 멋있어 보이는데, 왜 X를 시도해 보지 않겠어?"와 크게 다르지 않았습니다. 그리고 자체 호스팅이든 100달러 플랜이든, 단순히 "한번 테스트해 보고 싶다"는 욕구보다 약간 더 많은 헌신이 필요합니다.[3]
다시 강조하자면, 제 핵심 주장은 이렇습니다: Discourse는 왜 커뮤니티가 필요한지 명확히 이해하고 그 커뮤니티를 성장시키기 위해 헌신할 준비가 된 사람들에게 이상적인(그리고 아마도 비교할 데 없는) 도구입니다. 하지만 대부분의 스타트업/소규모 그룹은 그런 사람들이 아니므로, 대부분의 사람들이 Discourse에 대해 이야기하지 않는다는 것은 놀라운 일이 아닙니다.
11개의 좋아요
늦었지만, @hiddenseal님의 매우 도움이 되는 게시물에 대한 답변입니다:
이 문제를 수정했습니다 - 지적해 주셔서 감사합니다!
놓치셨을 수 있으니 말씀드리자면, 최근 월 $50의 새로운 기본 플랜을 출시했으며, 한시적으로 50% 할인된 가격으로 이용할 수 있습니다. Our new Basic Plan is now available. Try it out today! 링크를 확인해 주세요.
이것은 유용한 통찰입니다. 저도 동의하는 편입니다. Discourse를 이러한 유형의 사람들이 쉽게 접근할 수 있도록 만든 새로운 기본 플랜, 신규 사이트 소유자의 경험을 개선하기 위해 Discourse에 도입하고 있는 변경 사항, 그리고 최근에 웹사이트에 적용한 변경 사항들이 이러한 상황을 바꿀 수 있을지 지켜보겠습니다.
9개의 좋아요
이 주제를 다시 꺼내는 것이 죄송하지만, 이에 대해 꽤 확실한 추측이 있습니다. 바로 UI입니다.
Discourse는 사람들이 익숙한 도구, 즉 Instagram이나 Facebook처럼 보이지 않습니다. 이는 사람들이 적응해야 한다는 것을 의미합니다. 게다가 이러한 복잡성과 유연성은 단점을 동반합니다: 사용자든 신규 관리자든 처리해야 할 정보가 매우 많다는 것입니다.
이는 더 가파른 학습 곡선을 의미하며, 일부 사용자 집단의 참여를 회피하게 만들 수 있습니다. 많은 사람들이 다루기 싫어하는 문제입니다.
다음과 같은 논리를 상상해 볼 수 있습니다: “사용자의 경험을 매끄럽게 만들어, 더 오래 머물게 하고 제공/공동 창작된 콘텐츠를 즐기게 하려면 무엇이 필요할까?” 그렇다면 그들의 초점은 잠재력이 아니라 사용 편의성에 있을 것입니다.
Discourse가 이런 일을 못 한다는 말은 아닙니다. 다만 막 시작할 때는 압도적이고 무섭게 느껴질 수 있다는 뜻입니다.
Discourse가 Facebook처럼 보이거나 Instagram처럼 작동하길 원하지 않는다는 점은 명확하고, 저는 그 방식을 좋아합니다. 하지만 정리, 특히 중복성 측면에서 정리가 필요합니다.
메뉴
상단 메뉴에 왜 두 개의 채팅 알림(빨간색, 사이드바의 채팅은 포함되지 않으며, 메시지가 올 때도 빛납니다)이 있나요? 노란색으로 표시한 부분: 이미 답글/언급, 좋아요, DM, 북마크로 정리되어 있는데 왜 모든 알림을 위한 벨 메뉴가 있나요?
또한, 프로필 버튼을 클릭하면 제 프로필로 이동하는 대신, 이 버튼 중 어느 것을 클릭하더라도 이미 마주치게 될 또 다른 메뉴가 표시됩니다:
그리고 또 다른 중복: 여기서와 사이드바 내비게이션에서 모두 임시 저장(Drafts)에 접근할 수 있습니다.
(이 메뉴에서 로그아웃할 수 있는 점은 흥미롭지만, 그렇다면 “환경 설정”, “알림 중지”, "로그아웃"만 표시하여 이해하기 쉽게 만들 수도 있을 것입니다. 이 메뉴의 일부 버튼을 쉽게 비활성화하는 방법을 찾아보았지만 찾지 못했습니다.)
메시지
메시지 시스템의 경우, 서로 다른 이름(DM, 채팅, 채널)으로 불리지만 더나로 같은 필요를 충족시키는 3개의 독립된 옵션이 있습니다.
DM은 비활성화할 수 없으며(비활성화할 수 있나요?), discobot에 의해 사용되며 기본적으로 비공개 포럼과 같습니다. 채널은 카테고리와 관련이 있고, 채팅은 그룹 대화 등을 허용하는 채팅입니다. 이 모든 것을 하나로 통합할 수는 없을까요?
결론
더 자주 추천되게 하려면 정리하여 신규 사용자의 진입 장벽을 낮추는 것이 좋을 것 같습니다. 플랫폼이 제공하는 잠재력이 문제인 것은 분명 아니니까요.
14개의 좋아요
테마 개발자와 플러그인 개발자들이 이를 바꿀 수는 있겠지만… 예를 들어, 마스토돈은 트위터/X와 다르려 하지만, 특히 매우 인기 있는 테마를 사용하는 인스턴스의 경우 매우 유사합니다.
알고 있습니다. 다시 말하지만, 마스토돈은 X와 동일한 니치에서 운영되므로 저의 나쁜 예시입니다. 그리고 포럼인 디스코스는 소셜 미디어와 근본적으로 다릅니다. 하지만 유사성의 부족은 일반 사용자인 제인 존스나 잭 존스에게는 진입 장벽이 됩니다.
하지만 우리, 적어도 저는, 원래 주제와 다른 방향으로 가고 있는 건 아닌가요?
3개의 좋아요
이 추측은 이 토픽 초반에 제기된 “문제가 Discourse가 커뮤니티 플랫폼으로 포지셔닝하고 있느냐 여부와 관련이 있다”는 제안보다 더 핵심을 찌르고 있다고 생각합니다.
Discourse는 다양한 문제를 해결하는 데 사용할 수 있습니다. 이러한 유연성 때문에 UI가 압도적으로 느껴질 수 있습니다.
Discourse는 또한 다양한 작업을 수행하기 위한 여러 워크플로를 허용합니다. 도움이 되려 한 UI 요소가 실제로는 혼란을 야기하는 경우가 있을 수 있습니다. 예를 들어, 선호 설정 드롭다운 메뉴나 사용자 활동 페이지 중 어디에서든 초안을 접근할 수 있는 것 등이 그렇습니다.
UI에 대한 코멘트를 하자면, 아마도 제가 할 수 있는 최선은 “물고기는 물에 대해 묻지 말라”는 말일 것입니다. 저는 약 5년간 업무용으로 매일 Discourse를 사용했으며, UI로 인해 혼란을 겪는 경우는 거의 없습니다. 아직 진행 중이 아니라면, 사용성 테스트를 해보는 것도 가치가 있을 것입니다. 친구, 지지자, 경험 많은 사용자로부터 좋은 피드백을 얻기는 어렵기 때문입니다. 테스트 대상은 Discourse의 잠재적인 최종 사용자와 잠재적인 스태프 사용자 모두를 포함해야 합니다.
비활성화할 수는 있지만, 이는 별도의 토픽에서 논의하는 것이 적절할 것입니다.
13개의 좋아요
좋은 피드백입니다. Discourse가 존재해 온 대부분 기간 동안 비슷한 의견을 들어온 것 같습니다.
소셜 네트워크와 비교하면, 우리는 아마도 “위원회式设计(design by committee)” 방식을 훨씬 더 많이 따르는 편입니다. 이 표현은 흔히 비하하는 의미로 쓰이지만, 저는 그 평판이 실제 상황보다 나쁘다고 생각합니다. 물론 이 방식은 단순화를 어렵게 만드는 것이 사실입니다.
우리는 Meta, 내부 직원, 그리고 고객들로부터 많은 피드백을 받습니다… 그리고 이 모든 사람들이 Discourse를 사용하는 방식에는 상당한 차이가 있습니다.
광범위한 피드백과 빠른 반복 개발을 결합하면, 우리가 빠르게 무언가를 구축하고 한 달 후에 재설계를 시도할 때, 기존 방식에 의존하고 있다고 말하는 사람들이 필연적으로 나타납니다. 제거하려는 옵션이 그들의 최애였다는 식의 반응이죠.
몇 가지 랜덤한 예시:
-
/categories 페이지에는 8가지(모바일을 포함하면 9가지)의 서로 다른 레이아웃이 있습니다. 대부분 다양한 요청에 기반하여 구축되었습니다…
-
북마크 알림 옵션을 줄이기 위해 사람들이 어떤 옵션을 사용하는지에 대한 내부 논의를 한 적이 있는데, 목록에 있는 거의 모든 옵션을 정말로 좋아하는 사람이 있다는 것을 발견했습니다.
-
처음에는 사이드바를 선호하는 추세에 맞춰 드롭다운 햄버거 메뉴를 제거하고 싶었지만, 드롭다운을 선호하는 사이트들이 상당수 있었습니다… 그래서 가까운 미래까지 2가지 내비게이션 메뉴 옵션을 유지할 예정입니다…
-
사이드바의 새로운 콘텐츠 알림에 대해 여러 스타일을 시도해 보았지만, 의견이 거의 반반으로 갈렸습니다… 그래서 이 부분에 대해 2~3가지 사용자 설정을 두고 있습니다.
-
일부 사용자는 채팅을 포럼 경험과 거의 완전히 분리되기를 선호하기 때문에, 채팅을 사용하는 방식도 2~3가지가 있습니다.
어떤 의미에서 이것은 좋은 일입니다. Discourse는 다양한 사람들에게 많은 것을 의미할 수 있기 때문입니다… 우리는 막대한 수량의 기능과 설정을 갖추고 있습니다. 단점은, 언급했듯이, 사용자가 매우 숙련되지 않은 한… 이 모든 것이 매우 빠르게 압도적으로 느껴진다는 점입니다.
몇몇 게시글에서 언급하고 있고, 우리가 이제 살펴보기 시작한 것 중 하나는 관리자(및 사용자)가 처음에 마주하게 되는 옵션과 설정의 수를 줄이는 것입니다… 기본적인 취미용 포럼의 경우, 대부분의 설정을 단순히 숨기는 것만으로 충분할 가능성이 높아 보입니다. 테마는 요소를 단순히 숨김으로써 일부 이러한 작업을 수행할 수 있지만, 이러한 테마는 종종 매우 목적에 맞춘 형태입니다… 개발 경험이 0인 관리자가 특정 기능을 추가하려고 할 때 조정하기가 쉽지 않습니다. 관리자와 사용자는 거대한 도구함을 받고 있는데, 실제로 필요한 것은 망치와 못 몇 개일 뿐입니다.
21개의 좋아요
구글 시트(사실 어떤 스프레드시트든)를 설정 도구로 활용하는 시스템을 구상하고 코딩을 시작했습니다. 이 시스템은 X를 위한 유용한 커뮤니티를 구축하기 위해 사이트를 미리 채워 넣는다고 생각하는 사람들이 일반적인 가져오기 작업(사용자, 카테고리, 주제, 게시글)을 수행할 수 있게 해줍니다. 또한 테마를 추가하고 설정하는 것(테마 설치 및 테마 설정 구성)과 사이트 설정도 허용합니다. 이를 통해 다양한 목적에 맞는 사전 설정된 사이트 세트를 가질 수 있습니다(예: 일부 무료 콘텐츠와 일부 회원/구독자 전용 콘텐츠가 있는 사이트, 소규모 그룹/가족/클럽용 사이트). 또한 회원 전용 카테고리 생성과 같은 일반적인 작업을 수행하는 것도 가능해집니다(현재 UX에서는 이것이 꽤 "간단"할 것 같지만, 그런 것을 찾고 싶다는 사실을 알아야 찾을 수 있는 것일 수도 있습니다).
인기 있는 소셜 미디어 사이트에서 볼 수 없는 많은 내용을 숨기는 사이트를 가지는 것은 나쁜 아이디어가 아닙니다. 일부 “단순한” 테마는 특정 내용을 숨기는 기능을 제공합니다.
12개의 좋아요
여기서 주신 답변과 정보에 진심으로 감사드립니다. 구체적인 사항에 대해 몇 가지 말씀드리고 싶지만, 그 전에 제가 Discourse를 사랑하고 성공을 바라고 있다는 점을 기억해 주셨으면 합니다. 제 의견이 날카롭거나 비판적으로 들린다면, 그것은 아마도 무지(예: 내부 프로세스나 고려해야 할 균형 요소 등에 대한 무지)나 단순한 의견의 차이에서 비롯된 것이며, CDCK가 구축해 온 것과 구축하고 있는 것, 그리고 그로부터 얻은 성공에 대한 비난이 결코 아닙니다. 어떤 프로세스나 조직도 완벽하지 않으며, 피드백은 그런 elusive한 목표에 점점 더 가까워지도록 방향을 잡아주는 역할을 합니다.
위에서 @simon이 언급한 대로, *비사용자 테스트(non-user testing)*도 함께 수행하고 계시기를 바랍니다. 제 경험상, 언급하신 그룹들로부터 주로 얻게 되는 것은 제도적이고 고착화된 이해관계자의 관점이며, 다양성은 있지만 성장에 대한 통찰력은 부족합니다. 물론 성장 자체를 위한 단순한 자본주의적 imperatives를 지지하지는 않지만, 기업의 장기적인 번영을 위해서는 어느 정도의 성장이 사실상 필수적이라고 생각합니다.
가능한 많은 사람들을 만족시키려는 시도는 훌륭하지만… 물론, 항상 모든 사람을 만족시키는 것은 문자 그대로 불가능합니다. 여러분이 그렇게 하려는 것은 아니라는 점을 인식하고 있지만, 기존 사용자의 요구를 잠재적 신규 사용자의 요구보다 우선시하는 것처럼 보입니다. 명확히 하자면, 저는 이것이 좋은 편향이라고 생각합니다… 어느 정도까지는요. 다만, 신규 및 잠재적 사용자(관리자/커뮤니티 빌더뿐만 아니라 최종 사용자)를 이해하고 그들의 요구에 부응하는 방향으로 균형이 조금 더 이동해야 한다고 제안합니다. 또한 일부 사람들을 실망시킬 수밖에 없다는 것도 중요한 현실입니다.
때로는 더 큰 이익을 위해 많은 사람들을 화나게 해야 합니다. 성장의 고통, 마이그레이션의 불편함 등은 여러분과 팀 전체가 잘 알고 있듯이 소프트웨어 개발의 현실입니다. 제시하신 예시를 통해, 아무도 실망시키지 않으려다 보니 결과적으로 옵션이 증식되고 있는 것처럼 들리지만, 실제로는 더 복잡할 것입니다. 다만, 이렇게 설명하신 것은 오히려 현재 취하고 있는 접근법에 대한 확신을 주지 못했고, 사실은 그 반대였습니다.
CDCK가 잘못된 접근을 하고 있다고 말하는 것은 아닙니다. 그런 판단을 내릴 만큼 충분한 정보나 직접적인 경험이 없으며, 제게도 그런 오만함이 있기를 바랍니다. 하지만 제가 말하고자 하는 것은, 현재 Discourse를 사용하는 방식(관리자와 사용자 모두로서)과 제시하신 예시를 단순히 판단했을 때, 플랫폼과 사용자 기반 전체의 이익을 위해 몇몇 사람들을 더 실망시키는 쪽으로 균형이 이동해야 한다고 주장할 수 있다는 것입니다. 거기서 자칭 presumptuous한 a-hole처럼 들리지 않도록 절도 있게 말하려 노력했습니다. 
그렇지 않았다면 죄송합니다.
네, 이것이 아마도 가장 필요한 부분이라고 생각합니다: 더 단순한开箱(out-of-the-box) 경험, 이상적으로는 상당한 사용자(관리자/최종 사용자) 테스트를 통해 다수가 원할 기본 기능 세트를 결정하는 것입니다. 기본 구성에 이미 일부 이러한 요소가 있으며, 저는 그 경계의 반대편(즉, 기본적으로 켜져 있지 않은 무언가를 활성화해야 하는 경우)에 서본 적이 있고, 그렇게 할 수 있는 옵션이 있다는 사실에 감사했습니다. 따라서 기능을 완전히 제거하는 것을 반드시 원하지는 않습니다. 하지만 모든 설정, 기본값 등을 전면 검토하고 조정하는 것, 그리고 최적화된 기본 옵션과 상호작용 모델 개념에 기반한 새로운 테마를 만드는 것은 훌륭할 것입니다. 많은 작업이 필요하겠지만, 다가오는 주요 새 버전을 위해 가치가 있을 것입니다. 그 결과 신규 고객을 확보하는 데 보상이 되지 않는다면 놀라울 것입니다.
항상처럼 경청하고 소통해 주셔서 감사합니다. 더 적극적으로 활동할 시간이 있었으면 좋았을 텐데, 저는 여전히 Discourse의 팬입니다!
9개의 좋아요
실제로 아주 좋은 아이디어입니다. 포럼이 특정 기능이 필요할 때, 관리자는 해당 기능만 활성화하면 됩니다. (관리자 경험을 향상시키기 위해, 마우스 우클릭 시 가능한 동작 목록이 열리고 실제 버튼이 해당 설정과 연결되는 기능이 있다면 정말 훌륭할 것입니다. 때로는 자신이 보고 있는 것이 무엇인지 이름조차 모를 때가 있으니까요. [특히 색상과 테마의 경우 ] 그리고 이는 CSS 관련 기능으로 어느 정도 가능합니다.) 중복성을 줄이는 것도 좋은 접근 방식입니다. 기능을 유지하면서 중복을 없앨 수 있기 때문입니다.
이 답변을 작성하면서 중복성의 다른 예시들을 발견했습니다. (일부는 주제와 관련되고, 일부는 답변과 관련되어 있다는 점은 이해하지만, 여전히 중복이 있습니다):
이것은 UI에 대해 많은 좋은 답변을 이끌어낼 것입니다. 훈련된 눈은 훈련되지 않은 눈이 마주하는 장애물을 볼 수 없습니다.
저도 그렇게 생각합니다. ^^
찾았습니다!
3개의 좋아요
화제를 벗어날 위험이 있지만, 이 아이디어는 이미 꽤 오래전부터 거론되어 왔습니다.
설치 마법사의 “회원 경험” 단계를 개선하여 "어떤 유형의 사이트를 만들겠습니까?"라고 질문하도록 할 수 있습니다.
가능한 옵션은 다음과 같습니다:
- 팀워크
- 소프트웨어/제품 개발
- 고객 지원
- 커뮤니티
- 전통적인 포럼
- 모든 것 제공!
이렇게 되면 Discourse 사이트는 선택된 사이트 유형에 적합한 UI 요소와 사이트 설정을 강조하도록 구성됩니다.
사이트가 셀프 호스팅되는 경우, 선택된 사이트 유형에 적합한 플러그인이 제안될 수 있습니다. 예를 들어 "팀워크"가 선택되면 Assign, Policy, Calendar 플러그인이 제안될 수 있습니다.
호스팅된 사이트의 경우, 이 단계를 설치 마법사에서 호스팅 가입 양식으로 이동하는 것이 더 합리적일 수 있습니다. 이렇게 하면 고객이 선택한 사이트 유형에 적합한 기능이 다양한 호스팅 티어에서 어떻게 비교되는지 확인할 기회를 가질 수 있습니다. 예를 들어 "커뮤니티"가 선택되면 “Gamification” 플러그인이 Discourse의 비즈니스 플랜에서만 사용 가능하다는 점을 강조할 수 있습니다. 적절히 구현된다면, 처음부터 친근한 방식으로 업셀링(상위 플랜 유도)을 수행하는 좋은 방법이 될 것입니다.
6개의 좋아요
이것은 커뮤니티를 위한 훌륭한 플랫폼이 될 수 있습니다. 저는 디스코urs를 처음에는 알지 못했는데, 디스코urs 포럼을 운영하던 전화 회사인 리퍼블릭 와이어리스(Republic Wireless)를 알게 된 후에야 처음 들어보게 되었습니다. 몇 년 전, 이 회사는 포럼을 폐쇄했는데, 이는 디시(Dish)에 인수된 후의 변화에 불만을 품은 회원들이 늘어나면서 포럼이 혼란에 빠졌기 때문입니다. 그리고 최근에는 이 회사가 부스트 모바일(Boost Mobile)의 일부가 되었습니다.
아미시인(Amish)과 같은 일부 커뮤니티는 전화 서비스 자체에 관심이 없었습니다. 전화가 항상 커뮤니티의 화합에 도움이 되는 것은 아니기 때문입니다.
이러한 종류의 포럼 플랫폼은 일반 음성 전화보다 훨씬 더 진보되어 있으며, 새로운 커뮤니티를 구축하거나 기존 커뮤니티의 의사소통을 개선하는 데 도움이 될 수 있습니다.
지난 몇 년간 Meta에서 해당 기능이 논의되는 것을 보고 나서 “디스코스가 그런 걸 할 수 있다는 걸 몰랐어요”, “그 기능/옵션이 내장되어 있다는 걸 몰랐어요”, "그 기능/옵션은 어디에서 찾을 수 있나요?"라고 말하는 사람들을 많이 봤습니다.
기본적으로 비활성화된 기능/옵션(대부분의 설치 환경에서)에 대한 인덱스를 만들면 어떨까요(관리자 대시보드에 링크를 포함하여). 또 다른 가능한 인덱스는 모든 테마, 테마 컴포넌트 및 플러그인에 대한 것일 수 있습니다(관리자 대시보드에 링크 포함). 기능, 테마, 테마 컴포넌트 및 플러그인(공식 및 비공식)의 범위가 매우 넓습니다. 또한 일부 플러그인은 비즈니스/엔터프라이즈 호스팅에서만 사용 가능하고, 다른 일부는 셀프 호스팅 사이트에서만 사용 가능합니다. 제가 아는 한 중앙 집중식으로 정리된 목록은 없습니다. "디스코스로 이런 걸 할 수 있으면 좋겠다"고 말하는 사람들에게 그들의 바람이 이미 충족되었음을 알려주는 데 큰 도움이 될 것입니다. 
3개의 좋아요