오픈소스 프로젝트 번역 기여 과정 정리

발단

이전부터 오픈소스에 기여해보고 싶다는 생각을 항상 하고 있던 중에 동기/비동기에 대해 공부를 하면서 기여를 할 수 있는 기회가 생겼다.

비동기 아키텍처의 핵심인 메인 루프와 스레드 풀에 대해 자세히 설명되어 있는 node.js의 공식 문서가 한국어 번역이 되어 있지않은 것을 확인하였다.

 

500줄에 가까운 문서였지만 해당 문서를 번역하면서 공부할 수 있는 내용이 많을 것이라는 확신이 들어 꽤 긴 시간을 할애하여 번역을 하기로 결심했다.

 

과정

Issue와 PR 확인

오픈소스에 기여하기로 결심하였다면 가장 먼저 해야할 것은 이미 누군가가 해당 이슈를 다루고 있는지 확인하는 것이다.

해당 프로젝트 리포지토리에 들어가 이슈 탭과 PR 탭을 확인하며 해당 내용을 다루고 있는지 먼저 확인을 한다.

 

본인은 번역하고자 하는 문서의 이름인 dont-block-the-event-loop.md, Korea, Korean 등과 같은 키워드로 검색하여 해당 문서를 다루고 있는 사람이 없다는 것을 확인 후 번역을 진행하였다.

 

포크하여 프로젝트 가져오기

본인이 처음 그 문제를 다루는 것이 확인되었다면 그 이후에는 오픈소스 리포지토리를 포크하여 본인의 리포지토리로 가져와야 한다.

 

포크한 리포지토리 내에서는 어떠한 파일도 생성하고 수정, 삭제 등을 할 수 있으며 이후에 PR시에 머지하고자 하는 모든 변경점에 대한 리뷰를 받게 된다.

 

포크한 본인 리포지토리 내에서 번역 진행

컨벤션을 완벽히 따르는 것이 최우선적으로 선행되어야 한다. 해당 프로젝트의 컨벤션을 읽어보았을때 특별히 따라야 하는 점이 보이지 않았으므로 큰 걱정없이 진행할 수 있었다.

 

브랜치는 따로 생성해도, 생성하지 않고 진행해도 상관없으나 translation 브랜치를 생성하여 해당 브랜치에서 작업을 진행하였다.

 

문서의 큰 틀을 그대로 따르기 위해 원본 파일을 그대로 복사하여 기존 경로인 nodejs.org/locale/en/docs/guides/dont-block-the-event-loop.md에서nodejs.org/locale/ko/docs/guides/dont-block-the-event-loop.md로 새로운 파일을 생성하였다.

 

이제 큰 흐름을 놓치지 않으면서 최대한 자연스러운 말투로 번역을 시작하면 된다.

직역을 최대한 지양하며 먼저 스스로가 내용을 이해한 후에 미래에 읽게 될 독자를 생각하며 이 말이 이해가 될까? 어색하진 않은가? 등을 생각하며 번역을 진행하였다.

 

번역 소요 시간은 5~6시간 가량 걸렸던 것으로 기억한다.

 

번역이 끝난 이후

번역이 완료되고 변경된 내용이 본인의 포크된 리포지토리에 잘 반영이 된걸 확인하였다면 해당 내용을 오픈소스 프로젝트에 적용해달라는 PR을 날려야 한다.

 

PR의 제목은 짧고 간결하게 누가 읽어도 이해할 수 있도록 작성하여야 한다.  본인은 Translated into Korean dont-block-the-event-loop.md라는 제목으로 PR을 작성하였다. 

 

PR을 하게 되면 해당 오픈소스에서 설정한 깃허브 액션을 통해 컨벤션과 린팅을 잘 따랐는지 검사를 받게 된다.

본인의 경우 'Remove trailing whitespace                '라는 린팅 경고를 여러 개 받으며 거절되었는데 문장이 종료된 이후에 따라오는 '    '과 같은 공백이 존재한다는 경고였다.

 

경고를 받게 되면 새로 변경한 이후에 또 PR을 날릴 필요없이 해당 PR에서 경고받은 부분만 수정하면 알아서 또 깃허브 액션을 통해 검사를 받을 수 있고 이렇게 직접 PR을 수정하여 검사를 통과하게 되었다.

 

기다리기

이제 해당 내용은 본인의 손을 떠났으므로 메인테이너에 의해 리뷰를 받고 PR이 approve 될 때까지 기다려야한다. 

 

본인의 경우 PR 요청과 검사 통과 이후 몇 시간도 되지 않아 메인 메인테이너가 해당 PR을 리뷰하기 위한 한국어 메인테이너를 ping해주었다.

 

그리고 2주 정도 지난 오늘 한국어 메인테이너에 의한 리뷰를 받게 되었다!!

몇 가지 어색한 말투를 짚어내어 이에 대한 변경을 요청함과 동시에 PR을 approve해주었다.

 

 

이후 본인은 변경 요청에 대해 수용할 것인지 말 것인지 결정해서 수정하면 되었는데 모든 요청 사항이 합당하다 생각하여 모두 수정하였다.

수정을 진행하면 위에서와 같이 다시 깃허브 액션을 통해 검사받게 된다.

 

리뷰를 받아 approve 받고 나면 자동으로 머지가 진행되는 것인지 메인 메인테이너가 바로 나타나서 머지를 진행해주었고 최종적으로 머지가 완료되었다!

 

 

머지가 되고나면 새롭게 빌드를 하고 릴리즈를 하는데 시간이 어느 정도 소요되므로 느긋하게 기다리면 된다.

 

결과

 

이벤트 루프와 워커 풀을 막지 마세요!

이벤트 루프와 워커 풀을 막지 마세요! | Node.js

 

결론

코드 기여가 아니었던 점은 아쉽지만 해당 문서를 번역하며 비동기에 대해 공부한 내용도 정말 많았고 깃허브의 PR, 리뷰, 머지 과정을 직접 체험해볼 수 있어 정말 좋은 경험이었다.

 

본인의 시간을 할애하여 리뷰해주는 메인테이너님들 항상 감사합니다!