<div id="readability-page-1" class="page"><div><div><h2 id="f0c5">누구나 할 수 있는 오픈소스 코드 기여</h2><div><p><a rel="noopener" href="/?source=post_page-----2ce4b0138b1e--------------------------------"><img alt="Gemini Kim" src="https://miro.medium.com/fit/c/56/56/1*a1SLLhbCAdY2TloLXekPhg.jpeg" width="28" height="28"></a></p></div></div><p id="95b6">오픈 소스 기여에는 다양한 방법이 있지만, 개인적으로 가장 재미있는 것은 코드 기여인 것 같습니다. <br>저의 경우는 코드 기여를 어떻게 진행했고 하고있는지 간단히 기록해보려 합니다.</p><h2 id="ec0b">프로젝트 찾기</h2><ul><li id="4e08">관심 있는 분야의 프로젝트를 찾아서 목록을 만든다.</li><li id="b66e">최근 커밋 활동이 없는 프로젝트를 제외한다.</li><li id="298c">PR이 쌓여있지만 리뷰가 진행이 전혀 안되는 프로젝트를 제외한다.</li><li id="9ea2">테스트 코드가 없는 수준인 프로젝트를 제외한다. <br>(각종 문서도 도움이 되지만 코드 작성 시에는 테스트만큼 도움이 되는 게 없었던 것 같습니다.)</li></ul><h2 id="c4b0">준비하기</h2><ul><li id="8c4c"><code>CONTRIBUTING.md</code> 문서가 있는 경우 읽어본다.<br>(그 외 코드 컨벤션이나 프로젝트 설정 문서가 있다면 읽어본다)</li><li id="625d">프로젝트를 받고 문서에서 안내하는 프로젝트 구성 설정을 한다.<br>(단순한 경우 문서가 없을 수도 있으니 요령껏 설정한다!)</li><li id="ae3e">구성 설정이 끝나면 프로젝트의 테스트를 일괄 돌려본다.<br>(궁금한 부분에 대하여 분석하기 위해서 기존 테스트를 사용하면 빠르게 접근할 수 있으므로 우선 모든 테스트가 정상적으로 돌아가는지 설정 빠진 게 없는지 체크한다.)</li></ul><h2 id="af00">기여할 것 찾는 법</h2><ul><li id="124e">열심히 사용해보기<br>(보통 써봐야 이슈나 버그를 찾을 수 있어서..)</li><li id="5071">최근 이슈 둘러보기</li><li id="e297">최근 커밋 둘러보기</li><li id="921c">최근 머지 된 PR 둘러보기</li><li id="87ad">테스트 코드 돌려보며 프로젝트 분석하기</li></ul><h2 id="a947">기여하는 방식</h2><ul><li id="179a">버그가 있는 경우 개선하기</li><li id="bd63">기존 기능을 향상시키기</li><li id="3fc7">신규 기능 추가하기</li><li id="cb25">다른 사람이 등록한 이슈&amp;버그 리포팅 개선하기</li><li id="64d7">초보자 이슈 해결하기<br>(꽤 체계가 잡힌 프로젝트들은 첫 기여자나 프로젝트 초보자를 위해 Label을 설정해놓습니다 그런 이슈 먼저 시작하면서 프로젝트와 친해지는 게 좋을 것 같아요!)</li></ul><h2 id="debd">PR 날리기</h2><p id="263f">가능한 자기 생각 및 의견을 상세하게 써주는 게 좋은 것 같다, 그리고 만약 모르는 부분이나 애매한 부분이 있다면 추가로 설명을 달거나 코드 부분에 직접 코멘트를 하는 것도 좋을 것 같다.</p><h2 id="3a34">리뷰를 기다리며</h2><ul><li id="cc03">PR 올려놓고 재촉하지 않는다 (그분들도 여러 일정이 있으므로)</li><li id="8227">언제 Merge 되나 집착하지 않으며 다른 PR 날릴 거리를 찾거나, 다른 프로젝트를 둘러본다.</li><li id="88e1">그러나,, 시간이 꽤 지나도 응답이 전혀 없다면 예의 있게 멘션을 날려본다.<br>(재미있는 부분은 리뷰어도 기여자가 리뷰에 대해 응답이 없다면 이렇게 멘션을 날려준다.)</li></ul><h2 id="b89c">Reject PR</h2><p id="cab9">PR을 올리더라도 항상 Merge 되는 것은 아니다, 프로젝트의 방향과 맞지 않거나 프로젝트 오너의 판단에 의해서 언제든지 반려당할 수 있다.</p><p id="8662">보통 반려 시에는 충분한 이유를 설명해준다. 이럴 때 프로젝트의 방향이나 관점을 들을 수 있는 기회가 되는 것 같다, 그러니까 너무 고민만 하지 말고 일단 PR을 날리자.</p><h2 id="5c83">시작하는 팁</h2><p id="df54">사<span id="rmm"><span id="rmm">실</span></span> 위의 내용 같은 부분을 빼도 기여하는 것은 어렵지 않은 것 같다. 더욱이 글을 적다 보니 대단한 프로세스나 방법이 있지는 않은 것 같다.</p><p id="da7e">굳이 가장 중요한 것을 꼽으라면 관심 있는 프로젝트를 찾는 게 가장 중요한 것 같다.</p><p id="6540">관심 있는 프로젝트를 찾았다면 잘 모르겠더라도 용기를 내서 작업을 해보고 PR을 보내보고 리뷰도 받으며 프로젝트를 조금씩 알아가게 되는 것 같다.</p><p id="a2fb">정리하자면 시작하는 팁은 <strong>그냥 일단 시작하라는 것</strong>이다. 리젝 당하면 어떻고 리뷰에서 까이면 어떤가 맨날 생각만 하고 안 하는 것보다 일단 하는 게 무조건 좋은 것 같다.</p><h2 id="4fc5">마무리 및 소외</h2><p id="a15a">글을 쓰며 이 글의 정체는 무엇을 위해 생각해보니, 오픈소스에 기여를 시작하는 것을 어려워하지 말라고 말하고 싶었던 것 같다, 누구나 할 수 있게 열려있고 재미도 있고 의미 있으니까.</p><p id="9a31">나의 경우는 운이 좋아서 오픈소스를 오래 하고 계신 형을 알게 되어 많은 얘기를 듣고 옆에서 지켜보면서 이런 거구나 하고 오픈 소스에 관심이 많아졌고 또 기회가 있어서 몇 번 해보니 이게 전혀 어려운 게 아니구나 싶었다.</p><p id="f177">아래는 오늘 본 글인데 참여자 분의 인터뷰 부분이 공감이 많이 갔어서 여러분도 한번 읽어보시면 좋을 것 같습니다!</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/2400/1*uim155KTZ3U0-6I9Ju2gag.jpeg" width="1200" height="627" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*uim155KTZ3U0-6I9Ju2gag.jpeg?q=20"></p></div></figure></div></div>

Stories by Gemini Kim on Medium

오픈 소스 기여에는 다양한 방법이 있지만, 개인적으로 가장 재미있는 것은 코드 기여인 것 같습니다. 
저의 경우는 코드 기여를 어떻게 진행했고 하고있는지 간단히 기록해보려 합니다.
프로젝트 찾기
관심 있는 분야의 프로젝트를 찾아서 목록을 만든다.
최근 커밋 활동이 없는 프로젝트를 제외한다.
PR이 쌓여있지만 리뷰가 진행이 전혀 안되는 프로젝트를 제외한다.
테스트 코드가 없는 수준인 프로젝트를 제외한다. 
(각종 문서도 도움이 되지만 코드 작성 시에는 테스트만큼 도움이 되는 게 없었던 것 같습니다.)
준비하기
CONTRIBUTING.md 문서가 있는 경우 읽어본다.
(그 외 코드 컨벤션이나 프로젝트 설정 문서가 있다면 읽어본다)
프로젝트를 받고 문서에서 안내하는 프로젝트 구성 설정을 한다.
(단순한 경우 문서가 없을 수도 있으니 요령껏 설정한다!)
구성 설정이 끝나면 프로젝트의 테스트를 일괄 돌려본다.
(궁금한 부분에 대하여 분석하기 위해서 기존 테스트를 사용하면 빠르게 접근할 수 있으므로 우선 모든 테스트가 정상적으로 돌아가는지 설정 빠진 게 없는지 체크한다.)
기여할 것 찾는 법
열심히 사용해보기
(보통 써봐야 이슈나 버그를 찾을 수 있어서..)
최근 이슈 둘러보기
최근 커밋 둘러보기
최근 머지 된 PR 둘러보기
테스트 코드 돌려보며 프로젝트 분석하기
기여하는 방식
버그가 있는 경우 개선하기
기존 기능을 향상시키기
신규 기능 추가하기
다른 사람이 등록한 이슈&버그 리포팅 개선하기
초보자 이슈 해결하기
(꽤 체계가 잡힌 프로젝트들은 첫 기여자나 프로젝트 초보자를 위해 Label을 설정해놓습니다 그런 이슈 먼저 시작하면서 프로젝트와 친해지는 게 좋을 것 같아요!)
PR 날리기
가능한 자기 생각 및 의견을 상세하게 써주는 게 좋은 것 같다, 그리고 만약 모르는 부분이나 애매한 부분이 있다면 추가로 설명을 달거나 코드 부분에 직접 코멘트를 하는 것도 좋을 것 같다.
리뷰를 기다리며
PR 올려놓고 재촉하지 않는다 (그분들도 여러 일정이 있으므로)
언제 Merge 되나 집착하지 않으며 다른 PR 날릴 거리를 찾거나, 다른 프로젝트를 둘러본다.
그러나,, 시간이 꽤 지나도 응답이 전혀 없다면 예의 있게 멘션을 날려본다.
(재미있는 부분은 리뷰어도 기여자가 리뷰에 대해 응답이 없다면 이렇게 멘션을 날려준다.)
Reject PR
PR을 올리더라도 항상 Merge 되는 것은 아니다, 프로젝트의 방향과 맞지 않거나 프로젝트 오너의 판단에 의해서 언제든지 반려당할 수 있다.
보통 반려 시에는 충분한 이유를 설명해준다. 이럴 때 프로젝트의 방향이나 관점을 들을 수 있는 기회가 되는 것 같다, 그러니까 너무 고민만 하지 말고 일단 PR을 날리자.
시작하는 팁
사실 위의 내용 같은 부분을 빼도 기여하는 것은 어렵지 않은 것 같다. 더욱이 글을 적다 보니 대단한 프로세스나 방법이 있지는 않은 것 같다.
굳이 가장 중요한 것을 꼽으라면 관심 있는 프로젝트를 찾는 게 가장 중요한 것 같다.
관심 있는 프로젝트를 찾았다면 잘 모르겠더라도 용기를 내서 작업을 해보고 PR을 보내보고 리뷰도 받으며 프로젝트를 조금씩 알아가게 되는 것 같다.
정리하자면 시작하는 팁은 그냥 일단 시작하라는 것이다. 리젝 당하면 어떻고 리뷰에서 까이면 어떤가 맨날 생각만 하고 안 하는 것보다 일단 하는 게 무조건 좋은 것 같다.
마무리 및 소외
글을 쓰며 이 글의 정체는 무엇을 위해 생각해보니, 오픈소스에 기여를 시작하는 것을 어려워하지 말라고 말하고 싶었던 것 같다, 누구나 할 수 있게 열려있고 재미도 있고 의미 있으니까.
나의 경우는 운이 좋아서 오픈소스를 오래 하고 계신 형을 알게 되어 많은 얘기를 듣고 옆에서 지켜보면서 이런 거구나 하고 오픈 소스에 관심이 많아졌고 또 기회가 있어서 몇 번 해보니 이게 전혀 어려운 게 아니구나 싶었다.
아래는 오늘 본 글인데 참여자 분의 인터뷰 부분이 공감이 많이 갔어서 여러분도 한번 읽어보시면 좋을 것 같습니다!
오픈소스 Armeria의 기여자를 위한 이벤트를 진행하였습니다 - LINE ENGINEERING

누구나 할 수 있는 오픈소스 코드 기여

댓글