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