오픈소스에 기여하는 모든 과정은 커뮤니티 멤버들과 커뮤니케이션의 연속이다. 먼저 효과적인 커뮤니케이션을 위해 다음 사항을 기억하라.
오류 보고라면 어떤 작업에서 발생했는지, 재현 경로는 어떻게 되는지 정확히 설명하라. 새로운 아이디어 제안이라면 아이디어가 프로젝트에 유용하다고 생각하는 이유를 설명하라.
좋은 예 | 나쁜 예 |
---|---|
“Y를 하는 과정에서 X가 동작하지 않습니다.” | “X가 안 돼요. 고쳐주세요.” |
도움을 요청하기 전에 프로젝트의 README 등의 문서, 이슈, 메일링 리스트 또는 검색을 통해 답을 찾아보라. 이런 노력을 보여주는 게 좋다.
좋은 예 | 나쁜 예 |
---|---|
“X를 구현하는 방법을 잘 모르겠습니다.README 와 메일링 리스트 이력을 확인했지만, 내용을 찾지 못하였습니다.” | “X는 어떻게 하는 거죠?” |
내가 생성한 모든 기여는 누군가는 검토해야 한다. 어떤 프로젝트는 검토하기 어려울 정도로 많은 기여나 요청이 발생한다. 따라서 가능한 한 간결하게 요청해야 접수될 가능성이 커진다.
좋은 예 | 나쁜 예 |
---|---|
“API 튜토리얼 작성하는 일을 지원하겠습니다.” | “얼마 전에 고속도로를 운전하다가 주유소에 들렀습니다.그때 우리가 해야 할 일에 대한 놀라운 아이디어가 떠올랐습니다. 아이디어를 설명하기 전에 한 가지 보여드릴 게 있습니다.” |
메인테이너에게 개인적으로 연락하는 것은 좋지 않다. 모든 대화를 공개하라. 이를 통해 더 많은 사람이 배우고 혜택을 받을 수 있다.
좋은 예 | 나쁜 예 |
---|---|
(Comment로) “@maintainer 안녕하세요, 이 PR을 어떻게 진행해야 할까요?” | “(이메일로) “안녕하세요, 나의 PR을 언제 확인해줄 건가요?” |
메인테이너라도 모든 부분을 완벽히 대응할 수 없다. 그들에게도 확인해야 할 시간이 필요하다.
좋은 예 | 나쁜 예 |
---|---|
“이 오류를 검토해주셔서 감사합니다.당신의 제안을 따랐지만, 이번에는 이러한 오류가 나타났습니다.” | “왜 내 문제를 해결할 수 없나요?당신이 메인테이너 아닌가요?” |
여러분의 아이디어가 프로젝트의 우선순위나 비전과 다를 수 있다. 커뮤니티에서 우리의 아이디어를 채택하지 않기로 할 수 있다. 이를 받아들여야 한다. 만약, 이에 대해 타협점을 찾지 못하거나, 결코 동의할 수 없다면 Fork 하여 여러분 자신의 프로젝트를 새롭게 시작하는 것을 고려해야 한다.
좋은 예 | 나쁜 예 |
---|---|
“내게 제출한 Use Case가 채택되지 않아서 유감이지만, 그 이유를 자세히 설명해주셔서 고맙습니다.잘 이해했습니다.” | “왜 내 Use Case를 지원하지 않나요? 용납할 수 없습니다.” |
오픈소스 프로젝트에서는 전 세계의 구성원과 협업을 한다. 언어, 문화, 지역 및 시간대에 따라 소통 방법에 온도 차이가 있다. 또한, 직접 대면해서 대화하는 게 아니라 글로써 의사소통하기 때문에 어조나 분위기를 정확히 전달하기가 어려울 수 있다. 이런 어려움을 극복하는 좋은 방법으로는 항상 상대방의 글은 좋은 의도라고 가정하는 것이다. 상대의 제안을 거절할 때도 정중히 하고, 자신의 입장은 명확히 표현하는 것이 좋다. 오픈소스라는 인터넷 공간에서 자신을 품위 있게 유지하라.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.