[오픈소스 첫 기여 가이드] 오픈소스 멘토링에서 10명 넘는 오픈소스 컨트리뷰터가 첫 기여를 성공할 수 있었던 방법
적절한 이슈 선정이 가장 중요합니다!
안녕하세요! 저는 “GDG(구글 개발자 그룹) 송도” 라는 개발자 커뮤니티 에서 “오픈소스 멘토링” 을 리드하고 있는 개발자 입니다.
- 오픈소스 멘토링 소개: https://medium.com/opensource-contributors/d1ed1a802247
- 리드 소개: https://github.com/injae-kim (스프링, 스프링배치, 리액터, 아르메리아 컨트리뷰터)
저는 오픈소스 첫 기여가 막막하신 분들을 도와 하루만에 원하는 오픈소스에 PR을 열 수 있게 도움을 드리는 “오픈소스 멘토링” 을 GDG 송도에서 리드하고 있습니다.
이 글에선 오픈소스 멘토링에서 사용하고 있는, 누구나 원하는 오픈소스에 첫 기여를 시작할 수 있는 가이드를 소개 드리고자 합니다!
⭐적절한 이슈 선정이 99% 를 결정한다
오픈소스 기여를 처음 하실때 제가 가장 중요하게 생각하는건 “적절한 이슈 선정” 입니다.
적절한 난이도의, 단기간에 해결 할 수 있는 말 그대로 지금 나에게 적절한 이슈를 고르는 것이죠!
- 기여의 명확한 동기부여가 있는 오픈소스의 이슈 선정
- 이슈 안에서 해결해야할 목표, 제안하는 해결 방법과 예시 코드, 관련된 소스 코드들, 테스트 코드 등 재현 방법 이 포함되어 있을 것
제가 생각하는 첫 기여에 적절한 이슈란 위와 같은데요! 예시로 살펴보겠습니다.
위 이슈는 제가 스프링에 올려두었던 이슈인데요! 정확히 어떤 현상이 왜 이상하고, 어떤 코드가 의심되며 재현할 수 있는 테스트 코드와 결과 까지 스크린샷으로 첨부해두었습니다.
스프링 배치에 올라온 버그 이슈 입니다. 어떤 버그 인지와 어떤 상황에서 발생하는지, 어떤 소스 코드가 관련 있는지와 버그를 재현할 수 있는 테스트 코드, 제안하는 수정 방안 이 이슈에 모두 포함되어 있습니다.
첫 기여에선 이러한 이슈를 고르는게 중요하다고 생각합니다. 첫 기여 니까요!
위의 이슈도 첫 기여에 적절한 이슈의 좋은 예시 입니다.
이슈에서 어떤 문제가 발생하고 있고, 어떤 상황에서 재현되는지가 자세히 설명되어 있습니다.
첫 기여 이슈가 꼭 난이도가 낮아야 하는 건 아닙니다. 위의 이슈에선 Polly라는 오픈소스의 써킷 브레이커에 새로운 기능을 추가하자는 제안 입니다.
써킷 브레이커라는 메인 피쳐에 새로운 기능을 추가하자는 제안이라 난이도가 높지만, 이슈 내용에서 무엇을 구현하고자 하는지 명확히 설명되어 있고 예시 코드도 친절히 남겨두어서 기여하고자 하는 의지와 동기부여가 명확하다면 충분히 도전할 수 있습니다! 오픈소스 멘토링에서 실제로 첫 기여로 이 이슈를 해결하셨습니다 :)
이슈 라벨을 잘 활용하자
하지만 오픈소스의 이슈 탭을 가보면 위처럼 보통 이슈가 수백 개가 열려 있습니다. 이 중 적절한 이슈를 고르는 것도 쉽지 않은 일입니다.
제가 사용하는 방법은, waiting-for-triage 라벨 처럼 아직 메인테이너가 이슈 내용을 확인하지 않은 이슈는 라벨을 필터링할 수 있습니다.
위의 리액트의 이슈들을 보면 알 수 있듯이, 대부분의 오픈소스 에서는 메인테이너가 확인하기 전 상태의 이슈에 라벨을 아무것도 달지 않거나 Status: Uncofirmed 으로 표시해둡니다.
따라서 저희는 이러한 라벨을 제외하면 도전해볼만한 이슈들을 볼 수 있는거죠!
또한 위처럼 bug나 core, enhancement 처럼 대부분의 오픈소스에서 사용하고 있는 대표적인 분류 라벨들만으로 이슈를 필터링 하면 올라와 있는 이슈들 중 메인테이너가 일차적으로 내용을 확인하고 분류해서 진행해도 괜찮을 만한 이슈들 을 확인해볼 수 있습니다.
- (팁 1) 댓글이 20개 이상 or 0개 인건 피한다 (아직 방향을 논의중일 확률이 높다)
- (팁 2) 이슈 내용이 명확해야 하고, 이슈 댓글로 메인테이너가 방향을 확인해준 이슈 일수록 좋다
- (팁 3) 메인테이너가 작성한 이슈라면 댓글이 없어도 좋다! (메인테이너는 Member 뱃지가 달려있습니다)
핵심은 “해당 오픈소스의 메인테이너가 이슈 내용을 확인했고 진행해도 괜찮다고 분류 해놓은 이슈 중에서 선정 할 것” 입니다.
이슈 안에 댓글로 아직 논의가 진행중이거나 진행 방향이 명확히 정해지지 않은 이슈는 첫 기여로는 적절하지 않습니다.
이렇게 적절한 이슈를 고르면 어떤 소스코드를 어떻게 고치거나 추가해야할지는 저절로 따라오기 때문에 PR이 바로 나오게되고, 이는 첫 기여로 자연스럽게 이어집니다. 불명확한 부분이 없기 때문이죠!
🔥실제 멘토링 참여자분들의 이슈 선정기
위에서 설명드린 이슈 선정 방법을 사용한다면, 누구나 2시간 정도만 집중하시면 당장 해결이 가능한 이슈 2~3개를 선정할 수 있습니다! 명확한 이슈 선정 기준이 있기 때문이죠. 또한 한번에 완벽한 이슈를 선정할 필요도 없어요!
실제로 오픈소스 멘토링 에서도 모든 멤버분들이 해볼만한 이슈 선정을 하루만에 해서 공유주셨고, 제가 바로 이슈가 진행 해볼만한지 / 아닌지 간단히 확인해드리면서 해결 방향 논의도 하며 재밌게 이슈 선정이 진행되었습니다.
이슈 선정이 가장 막막한 부분인건 당연하지만, 누군가 함께 고민해본다면 이슈 선정 과정 자체를 재밌게 즐길 수 있습니다! 한번에 좋은 이슈를 찾긴 어려워서, 함께 고민해줄 사람이 있다면 이슈선정에서 바로 기여까지 이어질 확률이 정말 많이 올라갑니다.
코드 구현과 PR 열기까지는 오픈소스 멘토링의 도움 받기!
적절한 이슈를 골랐더라도, 오픈소스 에 PR 을 열기까지의 과정은 모두 처음 해보는 영역이고 쉽지 않습니다.
코드를 포크해서 빌드하고, 적절한 테스트와 주석, 문서까지 수정해야하는 경우가 있기 때문이죠!
이 과정은 각자 진행하면 누구나 시행착오를 가장 많이 겪는 부분입니다. 오픈소스 마다 다르게 구현되어 있어 통일된 가이드가 있을 수가 없는 부분이죠!
이미 머지된 PR의 내용들을 참고하거나, 수정하고 있는 소스코드의 히스토리를 타고가서 머지된 커밋들을 참고하는것이 큰 도움이 됩니다. 이미 코드리뷰 후 머지된 답안지를 참고하는 것이죠!
이때 혼자 하기보다, 오픈소스 기여를 해본 경험이 있는 분의 도움을 받는다면 그 과정을 바로 넘어갈 수 있습니다!
이 부분이 제가 오픈소스 멘토링을 운영하는 이유이기도 합니다 :)
오픈소스 멘토링에서 선정한 이슈의 해결 방법에 대해 함께 고민하고, 소스코드 어디를 어떻게 고쳐야할지 함께 논의할 수 있다면 이 과정들은 오히려 재밌어 집니다!
결국, 여러분은 오픈소스 기여를 왜 하고 싶으신가요?
오픈소스 첫 기여를 할 때 가장 중요하지만, 많은 분들이 쉽게 넘어가시는 부분이 바로 오픈소스 기여에 대한 동기부여 인 것 같습니다.
여러분은 왜 오픈소스 기여를 하려고 하시나요?
- 재미있어 보여서
- 개인의 커리어, 좋은 직장, 명예, 부 에 도움이 되려고
- 평소에 사용하고 도움 받은 오픈소스가 있어서 이에 기여로 보답하고자
- 개발자라면 한번쯤은 오픈소스 기여를 해봐야한다고 들어서
위의 이유 말고도 각자 다양한 오픈소스 기여의 이유가 있습니다.
어떤 이유든 좋습니다! 다만 기여하고 싶은 명확한 동기부여가 있는 상태인지 기여 하기 전에 한번쯤은 점검해보시는게 좋습니다.
오픈소스 기여를 하게되면 오픈소스를 포크하고, 직접 빌드한 후 소스코드 수정과 수많은 테스트 추가, 커뮤니케이션 등 가끔은 힘든 과정들을 필연적으로 지나가게 됩니다.
이러한 과정에서 오픈소스 기여에 대한 명확한 동기부여가 없다면, 누군가 아무리 도와주더라도 더 나아갈 수 없습니다. 오픈소스 기여는 결국 본인이 두 손으로 직접 하는거니까요!
오픈소스 기여할 이유가 아직 명확히는 없는것 같다면, 당장 하실 필요는 없습니다. 언제나 원할때 도전할 수 있고, 누구에게나 열려있는게 오픈소스 니까요!
이 블로그에 꾸준히 업로드 될 다양한 분들의 오픈소스 기여를 보고 재밌어 보일때 도전해보셔도 됩니다 :)
감사합니다!
