기여 제출 세부

일반적인 오픈소스 프로젝트에 기여물을 제출하는 방법과 절차에 대해 설명합니다.

커뮤니케이션

오픈소스 프로젝트에 기여하는 과정은 커뮤니케이션의 연속입니다. 효과적인 커뮤니케이션을 위해 다음 사항을 기억하세요.

구분

설명

정확한 의사를 전달하세요

오류 보고라면 어떤 작업에서 발생했는지, 재현 경로는 어떻게 되는지 정확히 설명하세요.

새로운 아이디어 제안이라면 아이디어가 자신에게만 아니라 프로젝트에 유용하다고 생각하는 이유를 설명하세요.

(좋은 예) “Y를 하는 과정에서 X가 동작하지 않습니다.” (나쁜 예) “X가 안 돼요. 고쳐주세요.”

질문하기 전에 먼저 스스로 할 수 있는 걸 하세요

도움을 요청하기 전에 프로젝트의 README, 문서, 이슈, 메일링 리스트 또는 검색을 통해 답을 찾아보세요. 이런 노력을 보여주는 게 좋습니다.

(좋은 예)"X를 구현하는 방법을 잘 모르겠습니다. 도움말 문서를 확인했지만 언급이 없습니다." (나쁜 예) “X는 어떻게 하는 거죠?”

간단 명료하게

모든 기여는 누군가가 검토해야 합니다. 어떤 프로젝트는 검토하기 어려울 정도로 많은 기여나 요청이 발생합니다. 따라서 가능한 간결하게 요청하는 것이 접수될 가능성이 커집니다.

(좋은 예)"API 튜토리얼 작성하는 일을 지원하겠습니다." (나쁜 예) “얼마 전에 고속도로를 운전하다가 주유소에 들렀습니다. 그때 우리가 해야 할 일에 대한 놀라운 아이디어가 떠올랐습니다. 아이디어에 관해 설명하기 전에 한 가지 보여드릴 게 있습니다.

모든 커뮤니케이션은 공개하세요

Maintainer에게 개인적으로 연락하는 것은 좋지 않습니다. 모든 대화를 공개하세요. 이를 통해 더 많은 사람이 배우고 이익을 얻을 수 있습니다. 토론 자체도 하나의 기여입니다.

(좋은 예) (Comment로) "@maintainer 안녕하세요, 이 PR을 어떻게 진행해야 할까요?"

(나쁜 예) (이메일로) “안녕하세요, 나의 PR을 언제 확인해줄 건가요?”

질문을 하되 기다려야 합니다.

Maintainer라도 모든 부분을 완벽히 대응할 수 없습니다. 그들에게도 확인해야 할 시간이 필요합니다.

(좋은 예) "이 오류를 검토해주셔서 감사합니다. 당신의 제안을 따랐지만, 이번에는 이러한 오류가 나타났습니다."

(나쁜 예) "왜 내 문제를 해결할 수 없나요? 당신이 Maintainer 아닌가요?”

커뮤니티의 결정을 존중하세요.

우리의 아이디어가 커뮤니티의 우선순위나 비전과 다를 수 있습니다. 커뮤니티에서는 우리의 아이디어를 따르지 않기로 결정할 수 있습니다. 우리는 이에 대해 타협점을 찾거나, 결코 동의할 수 없다면 fork 하여 자신의 프로젝트를 새롭게 시작하는 걸 고려할 수 있습니다.

(좋은 예) ) "내게 제출한 Use Case가 채택되지 않아서 유감이지만, 그 이유를 자세히 설명해주셔서 고맙습니다. 잘 이해했습니다."

(나쁜 예) "왜 내 Use Case를 지원하지 않나요? 용납할 수 없습니다."

무엇보다도 품위를 유지하세요.

오픈소스에서는 전 세계의 구성원과 협업을 합니다. 언어, 문화, 지역 및 시간대에 따라 소통 방법에 온도 차이가 있습니다. 또한, 직접 대면해서 대화하는 게 아니라 글로써 의사소통하기 때문에 어조나 분위기를 정확히 전달하기가 어려울 수 있습니다.

이런 어려움을 극복하는 좋은 방법으로는 항상 상대방의 글은 좋은 의도라고 가정하는 겁니다. 상대의 제안을 거절할 때도 정중히 하고, 자신의 입장은 명확히 표현하는 것이 좋습니다. 오픈소스라는 인터넷 공간에서 자신을 품위 있게 유지하세요.

이 자료 확인

무엇이든 시작하기 전에 먼저 이전에 다뤄진 적이 있는지 과거 자료를 확인하세요. 프로젝트의 README, 이슈, 메일링 리스트를 살펴보세요. 모든 문서를 다 확인할 필요 없이, 몇 가지 키워드를 검색하면 쉽게 확인할 수 있습니다.

과거 자료에서 관련 내용을 찾을 수 없다면 이슈를 열거나 Pull Request를 통해 커뮤니케이션을 시작할 단계입니다. GitHub에서는 Issues와 Pull Request 기능을 제공합니다.

  • Issues : 대화나 토론을 시작할 수 있습니다.

  • Pull Request : 문제에 대한 솔루션을 기여합니다.

Issue 또는 Pull Request를 열기 전에 프로젝트가 제공하는 문서 (일반적으로 CONTRIBUTING 또는 README)를 확인하여 기여 절차 및 방법을 확인하세요. 예를 들어 특정 템플릿을 따르도록 요구하거나, 사전 테스트를 요구할 수 있습니다.

기여를 위한 작업을 시작하기 전에 먼저 Issues를 오픈해서 커뮤니티 구성원에게 먼저 어떤 작업을 하려고 하는지 알리는 것도 좋은 방법입니다. 때에 따라 불필요한 작업을 진행하지 않도록 도움을 받을 수 있습니다.

Issue 생성

일반적으로 다음 상황에서 Issue를 생성합니다.

  • 스스로 해결할 수 없는 오류 보고

  • 새로운 기능 또는 아이디어 제안

  • 커뮤니티 비전, 또는 정책에 대한 토론

Issue에 대한 커뮤니케이션 Tip

  1. 다루고자 하는 오픈된 Issue가 있다면, 먼저 comment를 남겨서 다른 사람들이 중복으로 작업하지 않게 하세요.

  2. 오래전에 오픈된 Issue라면, 이미 해결된 것일 수 있습니다. 작업을 시작하기 전에 comment로 해결이 된 것은 아닌지 확인하세요.

  3. Issue를 오픈했지만, 나중에 스스로 답을 알아낸 경우, 해당 Issue에 대한 답을 다른 사람도 알 수 있도록 comment를 작성하고 이슈를 close 하세요. 이렇게 문서화하는 것조차도 프로젝트에 기여하는 것입니다.

Pull Request

기여할 파일이 모두 준비가 되다면, Pull Request를 통해 기여를 제출하세요.

Pull Request 시기

일반적으로 다음 상황에서 Pull Request를 오픈합니다.

  • 사소한 수정 사항 제출 (예: 오타, 링크 오류 등)

  • Issue에서 이미 논의가 된 사항에 대한 작업 시작

Pull Request는 작업이 완료된 이후에 해야 하는 것은 아닙니다. 일반적으로 Pull Request를 일찍 오픈하여 다른 사람들의 피드백을 받는 게 좋습니다. 제목 줄에 "WIP" (Work in Progress)라고 표시하여 아직 진행 중인 작업이라고 표시하고, 나중에 언제든지 더 많은 Commit을 추가할 수 있습니다.

GitHub 사례

GitHub에 있는 프로젝트라면 Pull Request를 제출 시 다음 사항을 참고할 수 있습니다.

방법

설명

Repository Fork

"Upstream"의 변경 사항을 수시로 당겨와서 (Pull) 항상 최신 상태를 유지합니다. 이는 나중에 변경 사항을 Merge 할 때 Conflict 되는 걸 줄여줍니다.

Branch 생성

PR에 관련 Issue 번호 추가

PR (Pull Request) 오픈 시, 관련된 Issue의 번호나 참조하는 문서를 표시하세요. (예: "Closes #37")

전후 스냅샷 추가

수정 사항이 HTML/CSS를 변경하였다면, Pull Request에 전후 스냅샷 이미지를 추가하세요.

수정 사항 테스트

수정 사항을 반영하여 기존 테스트를 실행하세요. 필요할 경우 새로운 테스트 케이스를 작성하세요. 어느 경우라도 수정 사항이 기존 프로젝트를 손상시켜서는 안 됩니다.

프로젝트 스타일 유지

들여쓰기 (Indent), 세미콜론, 또는 주석 등을 프로젝트 스타일대로 따르세요. 그래야 Maintainer가 Merge 하기 쉽고, 나중에 다른 사람들이 이해하고 유지하기 수월합니다.

  • Pull Request가 처음이라면 Make a Pull Request(비디오 강의)를 참고하세요. 또한, First Contributions 에서 Pull Request 만드는 것을 연습할 수 있습니다.

  • 참고로, Kubernetes는 다음과 같은 Github workflow에 대한 설명 문서를 제공합니다. : github_workflow.md

Feedback 받기

기여를 제출하면 프로젝트로부터 Feedback을 받게 됩니다.

일반적으로 Feedback은 개선이나 변경 사항이 어떤 방식으로 동작하는지, 왜 그런 방식을 채택하였는지 등에 대한 설명을 요구합니다. 이 Feedback은 때로는 대응하기 어려울 수도 있지만, 기여의 수준을 높이는 과정이라고 받아들이는 것이 좋습니다.

Feedback은 보통 다음 네 가지 중 하나에 해당합니다.

1) 응답이 없다?

기여하기 전에 프로젝트가 활발한지 먼저 확인하는 게 좋습니다. 어느 정도 활발한 프로젝트에서도 기여에 대해 응답을 받지 못할 수도 있습니다.

일주일 이상 응답을 받지 못한 경우, 동일한 스레드에 정중하게 누군가에게 검토를 요청하는 것이 좋습니다. 적절한 사람의 이름을 알고 있다면 @-멘션 기능을 이용하세요.

단, 개인적으로 연락하지는 마세요. 오픈소스 프로젝트에서 공개 커뮤니케이션은 필수입니다.

그럼에도 여러 가지 이유가 있겠지만 아무도 반응하지 않을 수도 있습니다. 썩 좋은 기분은 아니지만 낙담할 필요는 없습니다. 이는 누구에게나 일어날 수 있는 일입니다. 기여할 수 있는 다른 방법이나 다른 프로젝트를 찾아보세요.

2) 수정을 요청한다?

아이디어에 대한 설명이나 코드를 수정하라는 요청을 받는 것은 일반적입니다. 이렇게 누군가 수정을 요청했다면 바로 응답하세요. 그는 자기 시간을 내서 우리 기여를 검토했습니다.

PR을 오픈한 상태로 응답하지 않고 남겨두는건 결례입니다. 더 이상 문제를 해결할 여건이 아닌 경우라면, Maintainer에게 더 진행할 수 없다고 알리세요. 그렇게 PR을 Close 하거나 다른 사람이 인수하여 추가로 진행할 수도 있습니다.

3) 거절됐다?

우리 기여는 결국 수락될 수도 있고, 수락되지 않을 수도 있습니다. 수락되지 않은 이유가 잘 이해되지 않을 경우, Maintainer에게 설명을 요청하는 것도 합리적입니다. 그러나 이것이 그들의 결정임을 존중해야 합니다. 논쟁하거나 적대적으로 행동하지 마세요. 끝까지 이견이 조율되지 않으면, 언제든지 Fork 하여 자신의 프로젝트에 작업할 수 있습니다.

코드가 승인되기까지 여러 차례의 반복적인 수정 과정을 거쳐야 할 수도 있으며, 때에 따라서는 거부될 수도 있습니다. 이때는 낙심하거나 포기하기보다는 거부된 이유에 대해 자세히 알아보고, 다음 기여가 향상되는 기회로 삼는 것이 좋습니다.

4) 수락됐다!

축하합니다! 드디어 오픈소스 기여에 성공했습니다.

Previous기여에 앞서Next오픈소스 공개하기

Last updated

Was this helpful?