커뮤니티는 어렵습니다. 구축도 어렵고, 유지 관리도 어렵고, 성장도 어렵습니다. 하지만 커뮤니티를 구축하는 것은 내 경력에서 가장 보람 있는 일 중 하나였습니다. 왜냐하면 저는 너무나 많은 훌륭한 사람들을 만났고 제가 익숙한 곳에서 벗어나 배우고 일을 해야 했기 때문입니다.
저는 10년 전에 베를린에서 열린 첫 번째 소규모 기술 컨퍼런스인 CouchConf에 참석했던 것을 기억합니다. 운 좋게도 비슷한 시기에 BerlinJS Meetup이 열렸고 저는 커뮤니티와 사람들에게 깊은 인상을 받았습니다. 그들은 웹사이트를 위한 GitHub 저장소를 설정했고 강연은 GitHub 이슈로 제출되었습니다. 프로세스의 단순성과 투명성에 놀랐기 때문에 몇 주 후에 저장소를 포크하고 BarcelonaJS를 설립했습니다. 이것이 나의 조직자들의 여정의 시작이었습니다.
정기적이고 매우 실망스러웠던 경험에 대한 작은 일화: 훌륭한 이벤트를 준비하기 위해 몇 시간을 준비하고, 소통하고, 연사를 찾고 초대하고, 날짜와 장소를 찾고 확보하고, 음식과 음료에 대해 후원자와 대화하는 데 시간을 보냈습니다. 그리고 때가 되면 거기에 혼자 앉아 있거나 올 것이라고 생각한 소수의 사람들과 함께 앉아 있을 것입니다. Meetup에서 "150명이 회신했습니다"라고 말했기 때문입니다. 그리고 아주 드물게 날씨가 좋지 않아서 그런 일이 있었지만 나중에 사람들과 이야기를 나눌 때 이런 말을 자주 듣게 되었습니다.
정말 놀랍습니다. 제가 그곳에 가보고 싶었지만 몰랐습니다!
이 문구는 제가 GitHub를 커뮤니티 도구로 탐색하기 시작하게 된 동기였습니다. GitHub는 자동화를 위한 가장 놀라운 플랫폼 중 하나이고 그것이 주최자로서 해야 할 일이기 때문입니다. Eventbrite에 이벤트를 게시하기 위해 모든 일을 자동화하고, Meetup, Twitter, Facebook, Telegram Groups, WhatsApp, 이메일, 캘린더 등 등 이벤트 2주 전, 1주 전, 3일 전, 1일 전, 1시간 전에 아무도 나중에 말할 수 없도록 하세요. : "나는 이것에 대해 몰랐습니다." 결국 이 일을 하는 것은 자신을 위해서가 아니라 공동체를 위해서이기 때문입니다.
여행하는 동안 Meetup에서 수천 명의 회원이 있는 Node.js 및 JavaScript 커뮤니티를 발견했지만 예정된 이벤트나 최근 이벤트는 단 한 건도 없었습니다. 이는 여러 가지 이유로 발생할 수 있지만 주최자가 시간이 없거나 다른 일로 넘어갔기 때문에 발생하며, 일을 계속 운영할 후임자를 찾기가 어렵기 때문인 경우가 많습니다. Meetup 및 기타 플랫폼은 커뮤니티와 이벤트를 발견하는 데는 좋지만 주최자가 더 이상 활동하지 않는 경우 회원이 커뮤니티에 연락하고 커뮤니티를 인수/부흥시키기 어렵게 만듭니다.
개발자로서 저는 GitHub에서 많은 시간을 보내고 도구와 작업 흐름에 익숙하므로 GitHub를 커뮤니티 플랫폼으로 사용하는 방법을 탐색하기 시작했습니다.
첫 번째이자 가장 분명한 이점은 GitHub의 공개 저장소가 오픈 소스라는 것입니다. 이는 모든 콘텐츠, 이슈 및 토론이 공개되어 누구나 포크, 복사 및 재사용할 수 있음을 의미합니다. 이는 커뮤니티가 포기되면 누구나 이를 포크하고 작업을 계속할 수 있다는 것을 의미하기 때문에 커뮤니티에 좋습니다. 이는 또한 새로운 커뮤니티를 시작하려는 경우 기존 커뮤니티를 포크하여 필요에 맞게 조정할 수 있음을 의미합니다.
GitHub에는 사용자/팀/조직 관리 기능이 내장되어 있으므로 직접 구축할 필요가 없습니다. 누군가를 조직에 초대하거나 조직의 다른 권한을 가진 팀을 추가하는 것은 쉽습니다.
우리 대부분은 GitHub를 사용하고 매일 사이트를 방문하는 방법을 알고 있으므로 데이터베이스 관리, 콘텐츠 관리 또는 기타 도구를 위해 추가 사이트를 북마크에 추가할 필요가 없습니다. GitHub Actions를 사용하면 일정에 따라 또는 필요에 따라 자동화된 작업을 실행할 수 있고, GitHub 페이지를 사용하면 커뮤니티 웹사이트를 무료로 호스팅할 수 있습니다.
저에게 있어 GitHub에서 커뮤니티를 구축할 때 얻을 수 있는 가장 중요한 이점 중 하나는 완전한 투명성과 개방적인 커뮤니케이션입니다. 모든 것[1]은 공개되므로 누가 무엇에 액세스할 수 있는지 걱정할 필요가 없습니다. 이는 누구나 커뮤니티에 기여할 수 있고, 진행 상황을 누구나 볼 수 있음을 의미합니다. 이는 신뢰를 구축하고 모든 사람을 포용하고 환영하는 커뮤니티를 구축하는 데 좋습니다.
BarcelonaJS, CDC 등과 같은 커뮤니티에서 나의 목표는 개발자들이 공유하고 연결할 수 있는 자유롭고 개방된 공간을 만드는 것이었습니다. 그리고 "무료"는 투명성이 들어오는 곳입니다. 과거에는 항상 재정적 기부에 손을 대지 않았습니다. 회사에서 후원을 원하면 행사장에 직접 음식이나 음료를 주문할 수도 있지만 저는 그렇게 하지 않을 것입니다. Open Collective 덕분에 이 작업이 훨씬 쉬워졌으며 이제 재정적 기부를 받고 이를 커뮤니티에 투명하게 만들 수 있습니다. 예를 들어 도메인 비용을 지불하고, 음식과 음료를 구입하고, 광고 캠페인을 실행하는 데 사용됩니다.
[1] 물론 내부 주최자 토론 등을 위한 비공개 저장소를 만들 수도 있습니다.
GitHub는 Meetup과 같은 커뮤니티/이벤트 플랫폼이 아니므로 몇 가지 주의 사항이 있습니다. 저는 이슈를 "이벤트" 또는 "대화 제안"으로 처리하고 GitHub 이슈 양식을 사용하여 제출을 구조화하는 데 익숙해졌습니다. 하지만 이는 이상적이지 않으며 신규 이민자가 "발표를 제출하려면 이슈 생성"을 이해하는 데 시간이 걸립니다. 날짜, 지도상의 위치 등을 선택하고 수백 명의 사람들에게 간단한 이메일 알림을 보내는 "편안한 기능"은 없습니다.
이 전체 개념은 GitHub 및 IssueOps를 중심으로 발전함에 따라 주로 개발자와 엔지니어에게 초점을 맞추고 있습니다. 이전 경험에 대한 아이디어를 제공하기 위해 제가 구축하는 데 도움을 준 몇 가지 커뮤니티와 컨퍼런스는 다음과 같습니다.
이를 구축하는 동안 저는 조직자의 삶을 더 쉽게 만들기 위해 일련의 도구, 워크플로 및 자동화에 지속적으로 노력해 왔습니다. 왜냐하면 이 작업은 너무 힘들고 종종 감사할 일이 아니기 때문입니다. GitHub에서 공개 커뮤니티를 구성하는 방법에 대한 개방형 커뮤니티 개념은 다음과 같습니다.
첫 번째 단계는 GitHub 조직을 설정하고 두 개의 저장소를 만드는 것입니다.
이름은 분명합니다. 이벤트 저장소에는 새 이벤트를 생성하기 위한 템플릿이 있고, 강연 저장소에는 강연 제안 제출을 위한 템플릿이 있습니다. 대화를 이벤트에 연결하여 의제를 구축할 수 있으며, 커뮤니티의 참여를 이끌어낸다면(기억하세요: 어렵습니다!) 👍 또는 ❤️과 같은 댓글과 반응을 사용하여 대화에 투표할 수 있습니다.
또한 GitHub 프로젝트를 사용하여 제안, 일정 및 발표 단계를 통해 이벤트 수명 주기를 관리할 수도 있습니다.
키프로스에서는 섬의 다양한 지역에 대한 라벨을 추가했지만 가장 중요한 것은 "승인됨" 라벨이 필요하다는 것입니다. 모든 새로운 이슈는 "이벤트" 라벨로 생성되지만 "분류" 권한이 있는 사람(주최자 팀)만 이벤트를 "승인"할 수 있습니다. 이는 스팸을 방지하고 이벤트가 관련성이 있는지 확인하는 데 중요합니다.
이제 조직, 문제가 있는 일부 저장소, 일부 구조가 있으므로 자동화할 때입니다.
GitHub의 GitEvents / GitEvents는 2014년에 런던 노드 사용자 그룹(LNUG)과 Barccelona Node.js 그룹 간의 공동 작업 "해킹 주말"로 gitup
이라는 이름으로 시작되었습니다. 그 당시에는 GitHub Actions가 존재하지 않았고 우리는 Meetup.com 데이터를 기반으로 GitHub 호스팅 웹사이트에 대한 구조화된 데이터를 구축하기 위해 문제에 대해 Webhooks를 사용하려고 했습니다. 설정이 번거로워 프로젝트가 한동안 중단되었습니다.
현재 GitEvents는 이슈 워크플로우를 자동화하는 간단한 GitHub Actions 세트입니다. 모임과 이벤트를 위한 "Git Ops". 필요한 것은 GitHub 조직과 GitHub 앱뿐입니다. 일부 기능은 다음과 같습니다.
iCal
캘린더 이벤트의 표준입니다. 사람들은 이것을 자신의 캘린더에 구독으로 추가하여 커뮤니티 이벤트에 대한 최신 정보를 얻을 수 있습니다. 우리는 github 파일에 대한 리디렉션을 만들었으므로 사람들은 https://calendar.cdc.cy 라는 간단한 링크를 통해 캘린더를 구독할 수 있습니다.
모든 것이 "플러그 앤 플레이"이므로 원하는 작업을 선택할 수 있으며 작업 흐름으로 구성하는 것이 상대적으로 쉽습니다. 예를 들어 키프로스 개발자 커뮤니티 워크플로를 확인하세요.
GitEvents를 시작하고 싶고 도움이 필요하다면 Discord Server 에 문의하세요. GitEvents는 진행 중인 작업이며 특히 다른 플랫폼과의 통합 등과 관련하여 항상 할 일이 많습니다 . 도움을 주고 싶으시면 연락하세요.
이슈 양식은 아직 GitHub에서 상대적으로 잘 알려지지 않은 기능입니다. 일반 Markdown 템플릿 대신 양식 구성과 함께 YAML 파일을 제공할 수 있습니다 .
이것은 구조화된 입력을 얻는 데 매우 유용하지만 일단 "Issue"로 저장되면 데이터는 단지 Markdown이기 때문에 의미상 쓸모가 없습니다. 날짜, 위치 등과 같은 의미 정보를 문제에 추가하기 위해 마일스톤, 마크다운 헤더, 라벨 등을 실험했지만 제대로 작동하지 않았습니다. 그래서 저는 GitHub Issue Forms Body Parser를 만들기 시작했습니다. 이는 양식을 통해 생성된 이슈를 구문 분석하여 날짜, 링크, 이미지, 목록 등을 추출하고 이를 구조화된 JSON 데이터로 변환하는 데 도움이 됩니다. 이는 Discord, EventBrite, Meetup 등과 같은 다른 플랫폼으로 직접 전달되거나 메일링, 트윗 등에 사용될 수 있습니다.
Issue Forms Body Parser는 Markdown 텍스트를 구문 분석하기 위한 라이브러리로 npm
에서도 사용할 수 있습니다 . 최근에야 웹사이트의 데이터 구조화를 위해 전체 README.md
파일을 구문 분석할 수 있다는 사실을 깨달았습니다.
query ($organization: String!, $repository: String!) { repository(owner: $organization, name: $repository) { id name object(expression: "main:README.md") { ... on Blob { text } } } }
이것은 저장소의 main
분기에서 파일 콘텐츠를 검색하는 쿼리이며 이를 "본문 파서"에 전달할 수 있습니다.
const structuredData = await bodyParser(readmeFile()?.repository.object.text)
커뮤니티 설명의 또 다른 사본을 보관하는 대신 이제 README.md
파일에서 About
섹션을 가져와 웹사이트에서 사용할 수 있습니다.
최신 https://cdc.cy 웹사이트를 통해 이슈, README.md
파일 및 구조화된 JSON 데이터로 가능한 것의 경계를 탐색하고 확장하고 싶었고 그 결과에 상당히 만족합니다.
README.md
또는 .json
파일에서 가져옵니다. 누구나 편집할 수 있으며 CMS나 계정 등은 필요하지 않습니다.events
저장소에서 승인된 이벤트 및 이벤트 라벨이 지정된 문제)를 기반으로 합니다.
이러한 모든 기능은 GraphQL API 를 통해 그리고 본문 파서로 Markdown 파일을 구문 분석함으로써 가능했습니다.
나는 한동안 이 개념을 연구해 왔지만 여전히 가끔씩 모양이 바뀌고 있습니다. 그러나 내가 BerlinJS에서 채택한 기본 아이디어는 변경되지 않았습니다.
이 모든 것을 구축하는 데는 많은 시간과 에너지가 소요되었으며 아직 시간이 없어서 부족한 부분이 많이 있습니다.
이것이 귀하와 귀하의 커뮤니티에 도움이 될 수 있다고 생각하고 함께 퍼즐을 맞추는 데 참여하고 싶다면 gitevent Discord Server , GitHub 토론 또는 GitHub 문제 중 하나에 직접 문의하세요.
키프로스 나 바르셀로나 에 거주하고 계시다면 현지 개발자 그룹에 가입하여 지원해 주세요.