오픈소스 프로젝트 서버

오픈소스 프로젝트가 기여자를 못 얻는 이유는 코드가 어려워서가 아닙니다. 어디서부터 손대야 할지 안 보여서죠. 이 설계도가 첫기여 채널을 따로 둔 것은 그 지점을 정확히 짚은 구성입니다.

처음 기여하는 사람은 입구를 못 찾습니다

기여 카테고리에 이슈·첫기여·pr이 있고, 이슈가 포럼입니다.

처음 기여하는 사람은 무엇부터 봐야 할지 모릅니다. 활성화봇으로 그 입구를 만드세요.

/역할선택셋업 으로 관심 분야 역할을 고르게 해두시면, 새 이슈가 올라왔을 때 그 분야 사람만 부를 수 있습니다. 서버 전체를 울리면 얼마 안 가 다들 알림을 꺼 버립니다.

첫기여 채널에 쉬운 이슈 목록을 고정해두세요. 오타 수정, 문서 번역, 테스트 추가 같은 것들이요. 첫 PR 을 넘기면 두 번째는 훨씬 쉽습니다.

이슈 포럼에 난이도를 붙이세요

태그를 난이도와 분야로 만드세요. 처음 오는 사람이 자기가 할 수 있는 걸 찾아야 합니다.

「누가 맡고 있는지」도 표시하시면 좋습니다. 두 사람이 같은 이슈를 동시에 고치는 일이 실제로 생깁니다.

pr 채널은 리뷰가 오가는 자리입니다. 리뷰가 느리면 기여자가 떠납니다. PR 이 2주 방치되면 그 사람은 다시 안 옵니다.

행동강령 채널이 있는 것이 중요합니다

오픈소스에서 행동강령은 형식이 아닙니다. 리뷰가 인신공격으로 번지는 일이 실제로 잦거든요.

「코드를 말하고 사람을 말하지 않는다」를 명시하시고, 위반 시 어떻게 되는지도 적어두세요. 적혀 있지 않으면 조치할 근거가 없습니다.

그리고 신고 창구를 분명히 만드세요. 메인테이너에게 직접 말하기 어려운 경우가 있습니다.

라이선스를 명확히 해두세요

오픈소스에서 가장 자주 생기는 분쟁입니다.

• 프로젝트 라이선스가 무엇인지 문서에 명시
• 기여물이 그 라이선스로 들어간다는 것을 기여자가 알아야 합니다
• 남의 코드를 가져와 PR 을 올리는 경우가 있습니다 — 출처와 라이선스 확인이 필요합니다

특히 AI 가 생성한 코드를 어떻게 다룰지 정하시는 편이 좋습니다. 요즘 반드시 나오는 문제입니다.

메인테이너 카테고리를 공개할지 정하세요

의사결정 과정을 공개하느냐가 이 프로젝트의 성격을 정합니다.

공개하면 기여자가 방향을 이해하고 맞춰 옵니다. 닫아두면 메인테이너는 편하지만, 기여자가 「어차피 안 받아줄 것」이라 생각합니다.

적어도 왜 거절했는지는 남기세요. 이유 없는 거절이 반복되면 기여가 끊깁니다.

로드맵 채널은 앞으로의 방향입니다. 이게 보이면 기여자가 지금 뭘 하면 도움이 되는지 압니다.

문서 카테고리가 가장 기여받기 좋은 곳입니다

문서는 코드를 몰라도 기여할 수 있습니다. 그래서 첫 기여로 가장 좋아요.

번역 채널이 특히 그렇습니다. 한국어 문서가 없어서 못 쓰는 프로젝트가 많고, 번역은 명확한 기여입니다.

예제 채널은 「이걸로 뭘 할 수 있나」를 보여주는 자리입니다. 사용자를 늘리는 데 문서보다 효과가 큽니다.

질문 채널과 이슈를 구분하세요

「안 돼요」는 질문이고 「버그입니다」는 이슈입니다. 섞이면 이슈 목록이 사용법 질문으로 찹니다.

질문 채널에서 확인한 뒤 실제 버그면 이슈로 올리는 흐름을 만드세요.

쇼케이스 채널은 이 프로젝트로 만든 것을 올리는 자리입니다. 메인테이너에게 이게 가장 큰 보상이기도 합니다.

컨트리뷰터 역할을 기록으로 주세요

역할에 메인테이너·컨트리뷰터·유저가 있습니다.

PR 이 하나라도 병합되면 컨트리뷰터로 주세요. 문턱을 낮게 두는 것이 맞습니다.

이 역할이 붙는 순간 그 사람은 이 프로젝트를 자기 것으로 여기기 시작합니다. 두 번째 기여가 훨씬 쉽게 옵니다.

메인테이너는 여럿 두세요. 한 명에게 몰리면 그 사람이 지칠 때 프로젝트가 멈춥니다. 오픈소스가 사라지는 가장 흔한 이유입니다.

처음 온 사람이 첫 PR 을 올리기까지의 길이 짧을수록 기여자가 늘어납니다.