http://radek.io/ 의 How to use Github issues to attract new contributors 라는 글을 번역했습니다. 길지 않으니 오픈소스 하시는 분들이라면 한 번쯤 읽어보면 좋을 것 같습니다.
많은 오픈소스 프로젝트들은 새로운 컨트리뷰터들이 필요하지만 이들을 찾는데 애를 먹고 있다.
반대로, 많은 컨트리뷰터가 되기를 희망하는 사람들은 어떻게 작업을 해야하는지를 찾는데 어려움을 겪는다.
뭐가 문제일까? 개발자로서, 우리는 코드 자체에만 대부분 초점을 두고 커뮤니티 작업은 접근성이 잘 갖춰져야 할 필요가 있다는 것을 망각할 때가 많다.
많은 프로젝트들은 깃헙의 이슈 리스트가 사용자와 개발자 사이의 주요 접촉 포인트가 된다. 사람들은 각각 버그를 리포팅하거나 질문하거나 컨트리뷰트하는 등 각각 다른 목적과 수준으로 트래커에 들어온다. 어떻게 그들이 필요로하는 것들을 찾아낼 수 있도록 할 수 있을까?
좋은 라벨들을 사용하라
라벨들은 깃헙의 이슈들을 관리하는 유일한 방법으로 각각의 라벨들에 이름과 색상을 할당해줄 수 있다. 매우 직관적이고 유연하게 이슈들을 분류할 수 있다.
하지만 라벨을 잘 사용하는 것과 과용하는 것은 종이 한장의 차이이다. 너무 라벨이 많거나 시스템이 복합하면 사람들은 금새 라벨들을 무시하게 된다. 그렇다면 어떻게 사용하는 것이 좋을까?
일의 종류
완전히 새로운 일인가? 기존에 있던 부분에 대한 작은 개선인가? 아니면 버그 픽스?
아마도 문서에 대한 수정이 필요하거나 홈페이지에 새로운 디자인이 필요할 수도 있을 것이다.
모든 작업에서 반드시 개발이 수반되지는 않을 것이고, 모든 컨트리뷰터들이 개발자일 필요는 없다. 이슈에 태킹할 때 코딩을 다른 작업들과 분리하게 되면 당신의 프로젝트에 관심을 갖고 있는 기술 문서 작성자나 디자이너들로 하여금 끌리게 할 수 있다. 아래에 예가 있다.
- Design
- Docs
- Code
만약 당신의 프로젝트에 문서가 아직 없거나(이슈를 만들 좋은 기회다!) 홈페이지나 디자이너가 필요없는 터미널 앱이라면 코드를 몇 가지 카테고리로 나누어서 사람들로 하여금 어떤 부분에 참여할 수 있는지 알게 할 수 있다.
- Bugfix
- Enhancement
- New feature
- Refactoring
- Tests
말할 필요도 없이, 뭔가 오버랩된다. 모든 작업은 새로운 기능이 추가될 때마다 테스트를 작성해야 필요가 있을 것이다. 작업이 커지고 모호해질수록, 모든 라벨들을 할당하고 싶은 유혹을 이겨내야 한다. 대신 그걸 세분화하거나 가장 적당한 것으로 골라야 한다. 너무 완벽한 정확성을 추구하는 것은 때로 관리의 어려움때문에 덜 조직화되도록 만든다.
난이도
각 이슈의 난이도를 추정하는 것은 특별히 당신의 프로젝트에 새로 들어오는 이들에게 유용하다. 나는 아래 세 개의 라벨을 사용한다.
- Beginner
- Intermediate
- Bigger project
이렇게 하면 태클당하는 것을 두려워해서 문제들의 해결을 회피하는 사람들로 하여금 확신을 갖고 문제를 해결하도록 할 수 있다. 깃헙의 필터를 사용해서 초심자에게 적당한 이슈들에 바로 접근할 수 있는 링크를 README 에 둘수도 있을 것이다.
우선순위
반면에 우선순위는 아마도 소프트웨어 티켓을 카테고리화하는 거의 공통된 방식으로, 나는 이게 오픈소스에 있어서 얼마나 유용한지는 잘 확신할 수 없다. 회사들의 경우, 개발자들이 투자하는 시간의 우선순위를 정하는데 사용해서 비즈니스적으로 급한 문제를 먼저 처리하게 할 수 있을 것이다.
오픈소스 프로젝트의 경우, 사람들은 자기들이 하고 싶을 때에만 작업한다. 각 사람마다 어플리케이션을 어떻게 사용하는지 또 어떤 부분이 중요한지에 따라 모두 우순선위를 다르게 볼 것이다.
또한 이슈에 낮은 우선순위 혹은 하찮은 불편함이라고 표시하는 것은 사람들로 하여금 일을 시작하도록 만들 수 없다. 이런 것들은 정확하게 처음 찾아온 이에게 태클을 하는 것과 같고 그래서 그들이 프로젝트를 떠나게 되기 때문에 하찮은 일이라고 표기하는 것은 잘못된 것이다.
만약 중요한 이슈라고 마킹하는 방법이 필요하다면, 그냥 하나의 'Critical'이라는 라벨을 사용하라.
README 에 설명하라
README 에 이슈들이 어떻게 구성되어 있는지에 대해 짧게 설명하는 것을 절대 잊지말아야 한다. 논문처럼 3 페이지 길이로 써서는 안된다. 사실 이 설명이 짧을 수록 더 나은 시스템이다.
특별히 초보자들을 겨냥해 각 카테고리별로 필터링된 이슈 리스트의 링크를 포함해서 사용중인 태그들의 카테고리에 대해 언급하는 것도 필요하다.
정리
이슈 트래커는 당신의 컨트리뷰터들이 만나는 장소 중 하나다. 어떤 프로젝트의 경우, 유일한 장소일 수도 있다. 코드를 유지할때 처럼 같은 기준으로 운영한다면 굉장한 커뮤니티를 만드는데 도움이 될 것이다.
마지막으로 하고 싶은 말은, 티켓들은 그 프로젝트 자체를 위해 있는 것이 아니고 오히려 그 티켓을 만든 사람을 위해 있다는 것이다.
