Discourse Chat (베타) 출시

3년 전, 우리는 Discourse와 롱폼(long-form) 포럼 패러다임이 숏폼(short-form) 채팅 패러다임과 어떻게 공존할 수 있는지에 대한 블로그 포스트를 게시한 바 있습니다:

이러한 도구들의 조합은 작동하지만, 몇 가지 결점이 있습니다. 결국 다음과 같은 상황이 발생하게 됩니다:

  • 중복된 사용자 디렉터리
  • 경쟁하는 형태의 개인 메시지
  • "이 메시지는 어디에 속하는가?"라는 불확실성
  • 콘텐츠 가드닝을 위한 poorly integrated 도구

올해 가장 많은 추천을 받은 HN 스토리 중 하나는 포럼이 채팅보다 우월하다는 내용의 포스트였습니다:

첫 번째 단락은 우리가 현재 해결하고자 하는 문제를 즉시 드러냅니다:

개발자 커뮤니티를 구축하려는 시도를 약 1년 해본 후의 핫 테이크(Hot take). 단 하나만 선택할 수 있다면, 개발자 플랫폼을 중심으로 커뮤니티를 구축할 때는 동기식 채팅 소프트웨어보다 포럼 소프트웨어를 사용하세요.

커뮤니티 빌더들은 둘 중 하나를 고르라는 것처럼 상호 배타적인 선택을 강요받아야 하지 않습니다. 이는 거짓 이분법입니다. 일시적 vs 영구적, 숏폼 vs 롱폼; 이들은 단순한 유용성의 미묘한 차이를 가진 커뮤니케이션의 다른 모드일 뿐입니다. 여전히 사람들의 커뮤니케이션이라는 동일한 목적을 수행합니다.

최소 실행 가능 커뮤니티(Minimum Viable Community)

채팅 룸에 두 사람을 함께 앉히면 건강한 커뮤니티의 시작이 됩니다. 정기적으로 어떤 잡담이 오가지만 한다면, 그 룸은 다른 잠재적 참가자들에게 활기차고 환영하는 곳으로 느껴질 것입니다. 이는 커뮤니티 초기 단계에서 훌륭한 온보딩 전략이지만, 이를 확장할 수 있는 한계는 명확합니다. 확장되지 않는 일을 하는 것은 스타트업과 싹트는 커뮤니티 모두에게 승리 전략이 될 수 있으며, 핵심은 초기 성장 전략을 벗어났다는 것을 아는 것입니다.

커뮤니티가 클수록, 지금까지 Discourse의 표준(이자 유일한) 인터페이스가 더 필요해집니다. 하지만 사용자 수가 적은 하위 구간과 Day-0(초기) 스타트업의 경우, 가장 큰 장벽은 파티를 질서 있게 유지하는 것이 아니라, 오히려 파티를 시작하는 것입니다. 그리고 우리는 채팅이 이러한 작은 규모에서 더 잘 작동한다는 것을 사실로 알고 있습니다.

즉, 채팅은 "누가 말 좀 해줘!"라는 문제를 해결합니다:

역사적으로 우리는 Day-0 커뮤니티에 대해 채팅 플랫폼에 의존해 왔으며, 상대적으로 성공적이었습니다: 규모가 커지면, 대부분의 채팅 커뮤니티는 그들의 채팅 파이어호스(firehose)에 더 구조화된 대응책이 필요하다는 것을 유기적으로 발견하게 되어, 결국 우리를 찾아옵니다.

이로 인해 우리는 규모 있는 토론을 위한 최고의 도구로 집중할 수 있었습니다. 그러나 대부분의 그린필드(신규) 커뮤니티에서 선택받는 도구가 되지 못하면서, Discourse는 종종 추가 커뮤니케이션 도구로서, 스택의 더 아래쪽에 있는 매우 어려운 위치에 놓이곤 합니다.

스택의 위로 이동

채팅 관성(chat inertia)이 몇 년간 깊게 자리 잡은 커뮤니티에 Discourse를 소개해야 하는 우리의 버티기 힘든 위치를 해결하기 위해, 우리는 다소 급진적인 무언가를 개발하기 시작했습니다:

이 플러그인은 현재 Meta의 비공개 카테고리에서 테스트를 위해 활성화되어 있습니다. 우리는 Discourse Chat의 MVP가 기존 Discourse 커뮤니티에 도입될 것과 매우 유사한 방식으로, 이 폐쇄된 공간에서 함께 채팅을 나눌 것입니다: 스태프 채팅.

채팅의 장기적인 계획을 전달하는 데 복잡성을 가하는 요인 중 하나는 우리가 필연적으로 두 개의 분리된 시장을 대상으로 하고 있다는 것입니다:

(대부분 사적인) 팀 작업을 위한 채팅
(대부분 공개적인) 커뮤니티를 위한 채팅.

이 두 세로(vertical)는 대부분 동일하며, 하나를 해결하면 다른 하나도 해결됩니다. 팀 프로젝트를 시작하든 커뮤니티를 시작하든, 주요 이해관계자들이 조정되고 사회적으로 연결되도록 좋은 staff 채팅이 필요합니다.

얼리 액세스(Early Access)

현재 채팅을 직접 체험해 볼 수 있는 두 가지 방법이 있습니다:

  1. 자체 호스팅 인스턴스에 오픈 소스 플러그인을 설치하세요. 아직 프로덕션 사용을 권장하지는 않지만, 우리는 이미 내부 팀 인스턴스 및 Meta에서 채팅을 실행하고 있습니다.

  2. Meta에서 우리와 채팅을 나누기 위해 채팅 테스터를 위한 비공개 그룹에 가입하세요. 누구나 가입을 요청할 수 있습니다. 자체 호스터들도 여기에 피드백을 공유하도록 장려합니다.

채팅은 12월 말/1월 초에 Meta에서 완전히 공개될 예정입니다.

135개의 좋아요

오, 정말 멋지네요. 제 사이트에는 꼭 필요한 기능인데, 현재 Rumbletalk을 감싸는 커스텀 플러그인을 사용 중입니다. 이 기능이 Discourse 코어에 포함된다면 정말 큰 장점이 될 거예요.

9개의 좋아요

아마도 너무 앞서가는 말일 수 있지만 — 브리징(bridging)에 대한 고려가 있는 건가요?

Discourse를 정말 좋아하지만, 가장 필요 없는 것은 _또 다른 즉각 메시지 출처_입니다. Fedora에서는 현재 IRC에서 Matrix로의 전환을 진행 중입니다. Matrix로 브리징할 수 있다면 매우 유용할 것이고, 그렇지 못하다면 통신 단편화를 더 악화시키는 방향이 될 것입니다.

15개의 좋아요

훌륭한 결정입니다. Discourse 도입에 있어 게임 체인저가 될 것입니다.

8개의 좋아요

브릿징은 제한적인 용량으로 계획되어 있습니다. @merefield 님이 Discord를 위해 구축한 것을 다른 플랫폼에도 적용하는 방법을 검토하고 있습니다.

14개의 좋아요

물론 제 관점에서 가장 흥미로운 것은 새로운 별도의 프로토콜을 사용하는 대신, Discourse 채팅이 Matrix 홈서버이자 클라이언트로 작동하는 것입니다. 하지만 상대적으로 매끄럽게 작동한다면 단순한 브리징도 괜찮습니다.

9개의 좋아요

안녕하세요, 간단한 질문 하나만 드릴게요. 이 플러그인은 디스코urses 전체에 영구적으로 오버레이되는 건가요, 아니면 설정한 위치에 대해서만 적용되나요? 즉, 설치할 경우 커뮤니티 전체가 해당 방식으로 변경되나요, 아니면 선택한 카테고리에서만 변경되나요?

4개의 좋아요

공개적으로 접근할 수 있는 첫 릴리스를 축하드립니다.

양 농부와 치즈 제조업자 커뮤니티를 위해, 제 장기적인 마스터 플랜은 채팅에만 시간을 보내는 일부 사람들을 Facebook에서 우리 Discourse 커뮤니티로 옮기는 것입니다.

제로부터 구축하고 있는 전문 Jai 프로그래밍 언어 개발자 온라인 커뮤니티의 경우, Discord 채팅의 대안으로 Discourse Chat을 선보일 계획입니다.

Slack의 기본 기능만 사용하는 일부 클라이언트의 경우, 이미 프로젝트 관리를 Discourse로 이전하는 데 성공했습니다. 이 플러그인이 안정화되어 프로덕션 환경에서 사용할 수 있는 수준이 되면, 이를 완전한 Slack 대체재로 제안하기 시작할 것입니다.

마지막으로, 제 큰 꿈이자 거의 비현실적으로 보이는 계획은 Toptal 경영진이 Slack을 완전히 포기하고 Discourse로 이전하도록 설득하는 것입니다. Slack은 지식을 검색 가능하고, 공동으로 편집 가능하며, 분류하고, 관찰할 수 있는 스레드로 정리할 수 있는 방법을 제공하지 않아 정말로 불편합니다.

9개의 좋아요

매우 흥미로운 소식입니다. 감사합니다.

제 첫 번째 생각은… 이모지 리액션을 다듬고 공식적으로 지원하는 때가 된 건가 하는 것이었습니다.

진심으로 농담이 아닙니다.

(네, Discourse Retort 이 존재합니다.)

5개의 좋아요

retort와 유사한 공식 플러그인이 있습니다.

10개의 좋아요

제안 사항들. 아직 플러그인을 실제로 테스트해 보지는 않았지만, 브리징(동일하게 유용함)보다 이 항목들이 더 중요하다고 생각합니다:

  • 그룹별로 채팅 접근을 허용합니다.
  • 선택적으로 익명 사용자의 채팅 읽기/쓰기 접근을 허용합니다.
    • 그룹별로 자체 채팅을 가질 수 있도록 합니다
  • 선택적으로 그룹별로 채팅 댓글을 X시간/일/주 후 삭제합니다
  • 선택적으로 채팅에서 태그/그룹의 사이드바 표시를 허용합니다
  • 신뢰 수준/그룹에 따라 댓글을 주제 본문으로 "변환"하기 쉽게 합니다. 플래깅으로 처리할 수도 있습니다.
  • 신뢰 수준/그룹에 따라 기존 주제의 댓글을 답변으로 변환하는 것도 좋습니다. 플래깅으로 처리할 수도 있습니다.
  • 채팅 내 태그
  • 사용자가 가입/가입 요청이 가능한 그룹이 언급되면, 해당 사용자가 채팅 내에서 즉시 그룹에 가입/가입 요청을 할 수 있도록 합니다.
  • 채팅 내에서 Discobot에 직접 연락합니다. 공개적으로 하거나 개인 메시지로 전환할 수 있습니다.
  • 특정 주제/답변/태그와 관련되도록 채팅 가시성을 기간에 따라 지정합니다
  • 사용자가 채팅 내에서 기존 게시물을 빠르게 언급할 수 있도록 합니다.
    • 언급된 게시물이 채팅에서 하트를 받으면, 원본 게시물에도 해당 하트를 추가합니다(해당 기능이 지원된다고 가정하고, ㅋㅋ)

주제/게시물 검색 통합
사용자가 채팅에 게시물을 작성하려고 할 때 자동 검색을 추가하면 흥미로울 것입니다. 예를 들어 Hi, I cannot find music...라고 입력하면 필요한 음악 게시물이 자동으로 링크로 나타납니다.

모더레이션.

  • 채팅에서 과도하게 게시하는 사용자를 늦춥니다.
  • 그룹/신뢰 수준에 따라 채팅에서 사용자/그룹을 영구적으로 무시할 수 있도록 합니다(무시하면 모든 댓글이 더 이상 표시되지 않음)
  • 채팅 내에서 사용자 플래깅 / 무음 처리 / BAN.
  • 블랙리스트에 등록된 단어 제한
  • 그룹별 첨부 파일 허용

다른 사람들이 가입하거나 더 큰 게시물 내에서 더 자세히 설명하도록 장려하는 모든 것이 환영됩니다.
태그 지원은 또한 채팅 통합 플러그인 지원을 가능하게 하여, 기존 Discourse 브리징을 모두 커버합니다.

11개의 좋아요

게시글이 기존 주제에 병합되었습니다: 소규모 기능 요청

선택한 항목에만 적용됩니다! :ballot_box_with_check:

6개의 좋아요

정말 멋진 아이디어네요! 하지만 다른 분들이 지적했듯이, 또 다른 인스턴트 메시징 서비스가 추가되는 것은 문제가 될 수 있습니다. IRC를 좋아하지만, XMPP 연동이 더 나은 선택이라고 생각합니다. XMPP의 연동 범위가 훨씬 넓기 때문입니다. Matrix 방식은 채택하지 않는 것이 좋겠습니다. Matrix 연동이 너무 자원 소모가 크기 때문입니다. Matrix와 ActivityPub, 그리고 XMPP와 ActivityPub 간의 브리지가 잘 개발되고 있으니, 이를 활용하는 것이 더 나을 것입니다.

1개의 좋아요

채팅은 카테고리의 슬러그를 해당 채널의 이름으로 사용합니다. 아마도 이것이 최선의 해결책은 아닐 것입니다.

3개의 좋아요

문제를 다시 정의해 보고 싶습니다.

어떤 이유에서인지 사람들은 이 채팅 기능을 인스턴트 메시징 출처가 +1개 증가하는 것으로 보고 있습니다. 대신, 저는 이 기능(현재 단계에서)을 검색 가능하고, 집단적으로 편집 가능하며, 분류 및 모니터링할 수 있는 스레드로 지식을 조직하는 방법을 제공하지 않는 기존 인스턴트 메시징 플랫폼의 대체재로 우선적으로 보라고 제안합니다.

실제로, Discourse Chats는 기능적으로 기존 플랫폼을 대체할 뿐만 아니라, 기존 플랫폼 자체를 제거할 수도 있어 사용하는 플랫폼의 수를 줄이는 데 도움이 됩니다. 즉, 플랫폼 수를 증가시키는 것이 아닙니다.

예를 들어, Slack의 기본 기능(주로 간단한 채팅)을 사용해 왔다면, 더 이상 사용하지 않고 Discourse Chat을 시작하면 생각해야 할 플랫폼과 통합해야 할 플랫폼이 1개 줄어듭니다.

Discord나 다른 “무거운” 채팅 플랫폼도 마찬가지입니다. 단순히 간단한 용도로만 사용했다면, 이제 Discourse Chat으로 이전하고 기존 플랫폼을 폐기하는 것이 더 좋습니다. 이렇게 하면 사용하는 플랫폼 수를 줄일 뿐만 아니라, 채팅이 포럼/위키/지식 베이스/문서/프로젝트 관리와 더 긴밀하게 통합되도록 할 수 있습니다.

반면에, Facebook과 긴밀하게 통합되는 Facebook Messenger를 사용 중이고 그 통합이 필요하다면, 왜 Discourse Chats를 시작하여 인스턴트 메시지 출처를 하나 더 추가하려 할까요? Discourse Chats가 Facebook Messenger와 통합되어 Discourse Chat을 떠나지 않고도 후자를 사용할 수 있게 될 때까지는 그렇게 하지 않는 것이 좋습니다.

Telegram, Viber 등도 마찬가지입니다.

따라서 제 조언은 문제를 다시 정의하고 Discourse Chat 기능을 다른 관점에서 바라보라는 것입니다. 이는 더 많은 도구가 아니라, 더 적은 도구/플랫폼을 시작하는 좋은 기회입니다. 저는 Discourse 팀의 채팅 기능에 대한 가장 초기의 개념부터 지금까지 이렇게 생각해 왔습니다. 그리고 실제로 매우 흥미로운 일입니다.

26개의 좋아요

이것은 매우 작은 규모를 다루는 경우에만 가능해 보입니다. 저는 동료들과 소통하기 위해 Slack, Matrix, Keybase, Telegram, Signal, Google Chat, Twitter, Discord, Mattermost, Rocketchat을 사용하고 있습니다. IRC는 언급하지 않았지만, Matrix 브리지가 대부분 처리해 줍니다. 아, 그리고 Zulip도 있습니다. 아마도 더 있을 것입니다. 그리고 이것은 친구, 가족, 취미 관련 소통을 고려하지 않은 것입니다. 말하자면, 위 모든 것은 업무 관련 소통을 위한 것입니다.

이 중 대부분은 다른 대부분의 플랫폼을 대체할 '능력’은 있지만, 실제로는 그렇게 하지 않습니다. 대신 그것들은 쌓여만 갑니다.

유명한 말처럼…

괄호 안의 내용을 주목해 보세요. 여기에는 인스턴트 메시징이 직접적으로 언급되어 있습니다. 이것이 바로 제가 매우 강하게 바라는 점인데, 쌓여가는 그 무더기 위에 새로운 것이 추가될 경우, 적어도 서로 통신할 수 있기를 바랍니다 — 그리고 기존 표준을 사용하여 그렇게 하기를 바랍니다.

오해하지 마세요 — 물론 새로운 것을 시도해 볼 수는 있습니다. 하지만 제게는, 이 시점에서 진정으로 매력적인 새로운 것은 상호 운용성(interoperability)뿐입니다.

10개의 좋아요

모두 정확하지만, 내가 전달하려고 했던 아이디어와는 아무런 관련이 없습니다. 설명을 제대로 못 했을 수도 있겠네요. 나중에 다른 표현으로 다시 설명해 보겠습니다.

4개의 좋아요

@RGJ

friend something GIF

진지하게 말씀드리자면: 디스코urs 커뮤니티에 채팅을 통합하는 것은 훌륭한 아이디어라고 생각합니다. 저희 포럼에서는 Communiteq 통합을 통한 Rocket Chat을 내부 소통 및 장기적 가치가 없는 일시적인 질문 처리를 위해 단 하나의 채널만 사용했습니다.

확대를 하지 않는 유일한 이유는 채팅이 다음과 같은 문제를 일으킬 수 있기 때문입니다.
a) 포럼의 활동성을 잠식할 수 있습니다.
b) 채팅이 포럼에 더 적합한 장문 토론으로 이어지는 경우가 많습니다.

개인적 의견(IMHO)으로는, 커뮤니티 내에서 더 복잡하고 광범위한 수요가 있다면 훌륭한 채팅 플랫폼들이 많이 있다고 생각합니다. 따라서 장기적으로 현재 메시지 UX/UI를 대체할 수도 있는 “Private Messages v2” 역할을 할 수 있는, KISS 원칙에 부합하는 더 단순한 채팅 통합을 보고 싶습니다.

8개의 좋아요

채팅을 좋아하는 편은 아니지만, 이건 나 혼자 하는 거라 괜찮아요.

그런데 이걸 돌리려면 얼마나 비쌀까요? RAM, 프로세서, 저장공간 같은 부분에서요.

8개의 좋아요