이 글은 기존 운영했던 WordPress 블로그인 PyxisPub: Development Life (pyxispub.uzuki.live) 에서 가져온 글 입니다. 모든 글을 가져오지는 않으며, 작성 시점과 현재 시점에는 차이가 많이 존재합니다.
작성 시점: 2018-11-06
This article is a korean-translated version of the original post, 'The Minimum Viable Pull-request' by Jean-Michel Fayard.
이 글은 Jean-Michel Fayard가 투고한 The Minimum Viable Pull-request의 한국어 번역본입니다. 의역이 많습니다. 오탈자는 댓글로제보 부탁드립니다.
오픈 소스 프로젝트에 기여하는 것이 복잡할 필요가 전혀 없습니다.
여러분은 우리들 중 많은 사람이 하루에 적은 수의 오픈 소스 기여를 하고, 몇몇 행복한 사람들은 같은 하루에도 10개나 100개 이상의 기여를 하고 있는 것을 알아채셨나요?
그런 사람들이 구직자들이 말하는 'Rock-Star Ninja Developer' 일까요, 아니면 어떻게 기여를 효과적으로 할 수 있는지 알고 있는 것 뿐일까요?
문제점
새 오픈 소스 프로젝트에 기여할 생각이 있으신가요? 오픈 소스니 마음대로 해도 되겠죠? 당신이 해야 할 것은 프로젝트를 포크(fork) 하고 기능을 추가하고 제안하고 모든 것이 끝.
끝? 절대 아니죠!
혼자서 일하는 악덕 업자의 접근방법이 좌절감에 대한 레시피입니다!
물론, 아래의 사항에 해당할 수도 있죠.
- 프로젝트가 더 이상 관리되지 않거나,
- 오픈소스 관리자가 해당 방법 대신 다른 방법에 관심을 가지거나,
- 같은 것을 구현하는 데에 5배나 더 쉬운 방법이 있거나,
- 이미 있는 기능을 구현했거나,
CONTRIBUTING.md에 있는 내용을 따르지 않았거나,- 모든 테스트 케이스가 정확히 작동하는지 CI 체크를 살펴보지 않거나, (물론, 이 때에 빌드는 실패하게 됩니다)
- 프로젝트의 네이밍이나 코드 컨벤션을 따르지 않거나,
- 몇 주가 지나 포크한 것과 마스터에 엄청난 차이가 발생했거나,
- ... 또는 당신의 일화 ...
저는 최근에 다수의 오픈 소스 프로젝트에 기여했습니다. 처음에는 다소 떨렸지만, 실전을 통해 점점 좋아졌습니다. 제가 당신과 공유하고 싶은 주요 내용은 실현 가능한 최소의 Pull-Request(Minimum Viable Pull-request) 입니다.
WIP Pull-request
여러분이 모를 수 있는, WIP Pull-request는 개발팀 내부의 의사소통을 개선하기 위한 확립된 관행 및 협약입니다.
- 준비되었을 때가 아닌 기능이나 오류 수정을 시작할 때 Pull Request를 요청합니다.
- Pull-Request의 이름을
WIP: XXX라고 정합니다. 이 뜻은 여러분이 이 작업을 진행중이고, 조기 피드백에 답할 준비가 되었음을 말합니다. - 작업이 거의 끝나면,
WIP접두어를 제외하고, 파이널 리뷰가 필요함을 알립니다
MVP + WIP = Minimum Viable Pull-request
여러분의 첫 오픈 소스 프로젝트 기여를 어렵게 만드는 요소가 있습니다. 그 것이 바로, 해당 프로젝트에 대해 잘 모른다는 점입니다. 기여한 사람들을 모르고, 코드 기반을 모르고, 규칙이나 문맥 까지도 모릅니다. 그리고 기여자는 여러분을 모릅니다. 물론, 여러분이 탐사 모드(exploration mode)에 있는 것도 한 몫을 합니다.
충고: MVP로서 당신의 (WIP) pull request를 생각하세요.
MVP(Minimum Viabl Product) 컨셉은 린 스타트업 방법론(Lean Startup)에서 언급되는 것으로, 다수의 불분명한 것이 있는 미지의 환경에서 학습을 가속하는 것입니다. 이제 어떻게 이 방법론에서 영감을 얻을지에 대해 알아봅시다.
규칙 1: 당신의 아이디어를 확실하게 전달하기 위해 필요한 작업만 진행하세요.
규칙 2: 기여자와의 대화에 최대한 빠르게 집중하세요.
(편리하게도, MVP는 Minimum Viable Pull-request의 약자이기도 합니다! 그래서 여러분은 새로운 약자를 배울 필요가 없습니다.)
Minumum Viable
여기서 주의해야 될 점은 훌륭한 개발자들은 미덕으로 게을러지는 경향이 있고, 최소(이봐, 작업을 덜 하는 것이 좋은 것이라고!) 에 집중한 나머지 실현 가능한 부분을 건너뛰기도 합니다.
그렇지 않습니다! 여러분의 일은 기여자가 여러분을 쉽게 안내할 수 있도록 만드는 것입니다. 물론, 이 것에 코드를 적게 작성하는 것 또한 포함되어 있지만, 평소보다 더 많은 대화를 하는 것이 포함됩니다.
- 여러분의 사용처(Use-case) 를 설명하고, 왜 변화를 원하는지 설명하세요.
- 원하는 기능을 어떻게 구현할 지에 조언을 구하세요.
CONTRIBUTING.md파일을 정독하세요.- 프로젝트가 어떻게 작동하는지에 대해 다른 사람의 pull-request를 살펴보세요. CI가 어떻게 구성되었는지도 살펴보세요.
- 가장 중요한 것은, 작업을 하는 데에 시간을 보내기 전에 변화에 대한 권한을 승인 받으세요.
- 이 모든 것을 해냈다면 추가 점수가 있습니다 :P
How?
방법은 없습니다, 단지 pull-request를 시작하기 전에 이슈를 여는 것입니다.
제가 과거에 사용한 전략은 코드 베이스에 불합격되는 테스트를 작성하는 것입니다. (역주: 해당 PR의 첫 커밋인 854f32c 에 일부러 CI에 실패한 커밋을 작업했습니다)
비슷한 아이디어로는 구현하려는 변경사항으로 프로젝트의 문서를 변경하는 것이 있습니다.
아니면 제가 이 글을 쓰게 된 경험을 생각해보세요. 저는 종속성 관리로 인해 겪었던 문제점을 해결하는 Gradle 플러그인을 막 출시했습니다.
저는 갑자기 많은 프로젝트에 잠재적으로 기여할 수 있었습니다. 잠재적으로요. 하지만 많은 프로젝트는 그들이 사용하고 있는 솔루션으로도 괜찮습니다. 어느 것을 찾을 수 있을까요? Pull-request를 열고 플러그인을 적용한 다음, 제 솔루션이 어떻게 영향을 미칠 수 있는지 보여줄 수 있을 만큼만 업데이트 했습니다.
이 MVP 접근 방법은 저에게 큰 도움이 되었습니다. 저는 관심이 있는 사람과 없는 사람을 빠르게 구별하는 방법을 배웠습니다. 그들이 관심을 가지지 않을 때 많은 시간을 헛되게 투자하지 않아도 되어 관리자에게 조용히 화를 내지 않았습니다. 그들이 관심을 가질 때 제 시간과 노력을 기여에 투자하는 것이 훨씬 더 좋은 결과를 가져오고, 헛되지 않았을 것입니다.
이 글을 보고 어떤 점을 배웠나요? 감사를 표현하기 위해 :clap: 를 누르고 다른 사람이 이 글을 찾을 수 있게 도와주세요.
저와 나누고 싶은 이야기가 있으신가요? 댓글에 달아주시면 매우 기쁩니다!
