오픈소스 프로젝트의 첫 번째 도전은 기여자 간의 최상의 협업 방식을 찾는 것입니다
오픈소스 프로젝트가 직면해야 하는 첫 번째 도전 중 하나는 기여자들 사이에서 어떻게 소통할 것인가입니다. 여기에는 많은 선택이 있습니다: 포럼, 채팅 채널, 이슈, 메일링 리스트, 풀 리퀘스트 등등. 우리는 어떤 것을 선택해야 하며, 어떻게 해야 할까요?
안타깝게도, 프로젝트 자체는 종종 구속력 있는 결정을 내리기를 꺼리고, “위의 모든 것”을 선택합니다. 이것은 파편화된 커뮤니티로 이어집니다: 일부는 Slack/Mattermost/IRC를 사용하고, 일부는 포럼을 사용하며, 일부는 메일링 리스트를 사용하고, 일부는 이슈에 존재하며, 이 모든 경로의 내용을 읽을 수 있는 사람은 거의 없습니다.
내가 내외부 커뮤니티 구축을 돕는 조직에서 이것은 흔한 문제입니다. 우리는 어떤 채널을 선택하고, 어떤 목적으로 할까요? 또한, 언제 그중 하나에 아니라고 말할 수 있을까요?
이것이 내가 여기서 깊이 탐구하고 싶은 것입니다.
구조화와 비구조화
나는 똑똑한 사람이 아닙니다. 따라서, 나는 문제를 작은 부분으로 나누는 경향이 있어, 더 잘 이해할 수 있습니다. 비슷하게, 나는 상황에서 다양한 선택을 더 작은 부분으로 분해하여 그 목적을 더 잘 이해하는 경향이 있습니다. 나는 커뮤니케이션 채널 선택에도 이 방법을 사용합니다.
나는 두 가지 주요 커뮤니케이션 채널 분류가 있다고 생각합니다: 구조화와 비구조화.
구조화 채널은 각 개별 커뮤니케이션 단위에 매우 구체적인 초점이 있습니다. 예를 들어: GitHub / GitLab / Jira의 이슈. 이슈는 버그나 기능과 관련된 매우 구체적인 정보입니다. 초기 이슈 게시물이 게시된 후 발생하는 일련의 토론에서, 보통 해당 특정 주제에 매우 집중하며, 결과가 있습니다 (예: 버그 수정 또는 기능의 최종 계획). 결과는 보통 상태 (예: “FIXED”, “WONTFIX” 또는 “INVALID”)에 반영됩니다. 이것은 중간 내용을 읽지 않고도 커뮤니케이션의 처음과 끝을 이해할 수 있음을 의미합니다.
비슷하게, 풀/병합 리퀘스트도 구조화되어 있습니다. 그들은 특정 유형 (보통 코드)의 기여에 집중합니다. 초기 풀/병합 리퀘스트 후, 토론은 하나의 결과에 매우 집중합니다: 기여가 요구 사항을 충족하고 코드베이스에 병합되도록 하는 것.
또 다른 예는 StackOverflow/AskBot 같은 Q&A 게시물입니다. 이 게시물은 질문으로 시작하고, 편집되고 답변되어 그 질문에 대한 정확한 답을 제공합니다.
이러한 구조화 메커니즘을 통해, 보통 본래 구조에서 거의 벗어나지 않습니다. 이슈, 풀 리퀘스트 또는 Q&A 주제에서 누군가에게 그들의 아이/고양이/강아지/가족이 무엇을 하고 있는지 묻는 것을 보지 못할 것입니다. 주제에서 벗어나는 것은 커뮤니티에서 용인되지 않으며, 이것은 구조화 미디어의 힘의 일부입니다: 집중되고 (보통) 효율적입니다.
반대로, 비구조화 미디어는 채팅 채널과 포럼을 포함합니다. 이러한 환경에서, 보통 주제가 있습니다 (예: 채널 또는 하위 포럼의 주제), 그러나 그 안의 대화는 특정 결과나 결론과의 관계가 훨씬 적으며, 보통 더 일반적일 수 있습니다. 예를 들어, 개발자 메일링 리스트에서, 일반적인 질문, 새로운 기능 아이디어, 아키텍처 논쟁, 커뮤니티 자체 운영과 관련된 토론을 포함한 일련의 토론을 볼 수 있습니다. 각 토론은 참여자가 대화의 초점, 주제, 업무 효율을 유지하기를 바랍니다. 하지만 상상할 수 있듯이, 상황은 종종 그렇지 않으며, 이러한 토론은 생산적인 결과에서 벗어날 수 있습니다.
기록의 영향
구조화와 비구조화 커뮤니케이션의 미묘한 차이 외에도, 기록되는 내용과 그것들이 어떻게 검색되는지의 영향도 중요합니다.
일반적으로, 모든 구조화 채널은 기록됩니다. 사람들은 이전 버그를 참조할 수 있고, StackOverflow의 질문은 반복적으로 재사용될 수 있습니다. 무언가를 검색할 수 있으며, 많은 토론, FAQ, 풀 리퀘스트 또는 질문이 있더라도 최종 결론을 반영하도록 업데이트됩니다.
이것은 핵심입니다: 우리는 오래된 문제/질문/풀 리퀘스트 등을 빠르고 쉽게 찾고, 그것들에 링크하고, 인용하기를 원합니다. 여기서 핵심 부분은 우리가 이 내용을 인용할 수 있는 자료로 변환하여, 이전 지식을 교육하고 알리는 데 사용할 수 있다는 것입니다. 커뮤니티가 성장함에 따라, 우리의 구조화된 커뮤니케이션은 지식 기반이 되어, 이전 경험을 통해 미래를 알릴 수 있습니다.
반면 비구조화 커뮤니케이션은 점점 더 나빠집니다. 한편으로, 포럼 검색은 보통 간단하고 효율적이지만, 물론 비구조화된 대화로 가득 차 있어, 찾고 있는 것이 토론 속에 묻혀 있을 수 있습니다. 예를 들어, 많은 커뮤니티가 포럼을 지원 도구로 사용합니다. 더 강력한 플랫폼이지만, 문제는 질문의 답이 16층이나 340층에 있을 수 있다는 것입니다. 점점 더 많은 정보 출처 (예: Twitter)의 폭격으로, 우리는 대량의 자료를 읽는 데 점점 더 조급해지며, 이것은 비구조화 미디어에 문제가 될 수 있습니다.
흥미로운 특정 사례는 실시간 채팅입니다. 역사적으로, 수년 동안, IRC가 실시간 채팅의 길을 열었으며, 대부분의 IRC 사용자에게 이러한 토론을 기록하려는 생각은 거의 (있다면) 없었습니다. 확실히, 일부 프로젝트 (예: Ubuntu)는 IRC 로그를 기록하지만, 이것은 보통 유용한 자원이 아닙니다. 내 동료 Atwood가 한 번 나에게 말했듯이: “채팅에서 무언가를 검색해야 한다면, 이미 진 것입니다.”
IRC가 기록에 부족함이 있지만, Slack과 Mattermost는 더 낫습니다. 대화는 보관되지만, 문제는 여전히 존재합니다: 왜 대량의 채팅 메시지에서 누군가가 제기한 관점을 찾고 싶을까요? 다른 채널이 이전 토론을 인용하는 데 더 낫습니다.
하지만, 이것은 흥미로운 기회를 만듭니다. 채팅은 다른 미디어에 비해 일관된 이점이 있는데, 이것이 어떤 사람인지 보여줄 수 있다는 것입니다. 구조화 채널, 심지어 포럼과 메일링 리스트 같은 비구조화 채널도 잡담을 거의 장려하지 않습니다. 하지만 채팅은 그렇습니다. 채팅할 때 당신은 묻습니다: “주말 어땠어?”, “이 게임 봤어?”, 그리고 “다음 주에 Testament, Sepultura, Prong 볼 거야?” (좋아, 아마 마지막 질문을 하는 건 나뿐일 것이다.)
따라서, 실시간 채팅은 앞의 방법들보다 덜 효율적일 수 있지만, 사람들의 관계를 증진합니다.
무엇을 마시겠습니까
따라서, 오픈소스 커뮤니티에 대한 우리의 초기 질문으로 돌아가서: 우리는 무엇을 선택할까요?
이 답은 다른 프로젝트에 따라 다르지만, 나는 두 가지 측면에서 생각하고 싶습니다.
첫째, 일반적으로 구조화된 커뮤니케이션을 우선해야 합니다. 이것은 유형 있는 작업이 완료되는 곳입니다: 문제/이슈, 풀 리퀘스트, Q&A 토론 등. 자원이 제한되어 있다면, 이 채널에 집중하면, 더 적은 시간과 비용 지출로 커뮤니티의 효율적인 산출을 얻을 수 있습니다.
둘째, 엔지니어링, 홍보, 번역, 문서 등에 집중할 수 있는 더 넓은 커뮤니티를 구축하는 데 열정이 있다면, 비구조화 채널을 도입할지 탐구하는 것이 의미가 있습니다. 커뮤니티는 단지 작업을 완료하는 것만이 아니라, 관계와 우정을 구축하고, 업무에서 서로 지원하며, 사람들이 커뮤니티에서 성장하도록 돕는 것입니다. 비구조화 커뮤니케이션은 유용한 도구입니다.
물론, 나는 큰 주제를 얕게만 다루었습니다. 하지만 커뮤니케이션 채널의 가치를 평가하고 선택하는 방법에 대해 여러분에게 약간의 분석을 제공했기를 바랍니다. 기억하세요, 적은 것이 더 많은 것입니다: 모든 채널을 가지려는 망상에 유혹되지 마세요, 그렇지 않으면 텅 빈 레스토랑처럼 파편화된 커뮤니티를 얻게 될 것입니다.
포스가 당신과 함께하기를, 어떻게 진행되는지 알려주세요. 내 웹사이트와 이메일 jono@jonobacon.com으로 연락할 수 있습니다.
(제목 이미지: Opensource.com)
저자 소개:
Jono Bacon은 선도적인 커뮤니티 관리자, 연사, 작가, 팟캐스터입니다. 그는 Jono Bacon Consulting의 설립자로, 커뮤니티 전략/실행, 개발자 워크플로 및 기타 서비스를 제공합니다. 그는 이전에 GitHub, Canonical, XPRIZE, OpenAdvantage의 커뮤니티 디렉터를 역임했으며, 많은 조직에 조언과 컨설팅을 제공했습니다.
전재请注明：개발자 관계 »
