This page draws on content from GitHub’s Open Source Guide.
Every part of the open source contribution process is a continuous series of communications with community members. First, keep the following points in mind for effective communication.
Communicate Your Intent Precisely
If you are reporting an error, explain precisely what task it occurred during and how to reproduce it. If you are proposing a new idea, explain why you think it would be useful to the project.
| Good Example | Bad Example |
|---|---|
| “X does not work when I try to do Y.” | “X doesn’t work. Please fix it.” |
Do Not Just Ask; First Try What You Can Do Yourself
Before asking for help, look for the answer in the project’s documentation such as the README, in issues, in the mailing list, or through a search. It is good to show this kind of effort.
| Good Example | Bad Example |
|---|---|
| “I’m not sure how to implement X.I checked the README and the mailing list history but couldn’t find anything about it.” | “How do I do X?” |
Keep Conversations as Concise as Possible
Every contribution you submit has to be reviewed by someone. Some projects accumulate so many contributions and requests that they are difficult to review. Therefore, the more concise your request, the more likely it is to be accepted.
| Good Example | Bad Example |
|---|---|
| “I’d like to help with writing the API tutorial.” | “The other day I was driving on the highway and stopped at a gas station.That’s when an amazing idea about what we should do came to me. Before I explain the idea, there’s one thing I want to show you.” |
Make All Communication Public
Contacting maintainers privately is not a good practice. Keep all conversations public. This allows more people to learn and benefit.
| Good Example | Bad Example |
|---|---|
| (As a comment) “@maintainer Hello, how should I proceed with this PR?” | “(By email) Hello, when will you review my PR?” |
Once You’ve Asked, Be Patient
Even maintainers cannot handle everything perfectly. They also need time to review.
| Good Example | Bad Example |
|---|---|
| “Thank you for reviewing this error.I followed your suggestion, but this time these errors appeared.” | “Why can’t you solve my problem?Aren’t you the maintainer?” |
Respect the Community’s Decisions
Your ideas may differ from the project’s priorities or vision. The community may decide not to adopt your idea. You must accept this. If you cannot find a compromise, or can never agree, you should consider forking and starting your own new project.
| Good Example | Bad Example |
|---|---|
| “I’m sorry the use case I submitted wasn’t adopted, but thank you for explaining the reasons in detail.I understand.” | “Why won’t you support my use case? This is unacceptable.” |
Above All, Maintain Your Dignity
In open source projects, you collaborate with members from all over the world. Depending on language, culture, region, and time zone, there are differences in communication styles. Also, because you communicate through writing rather than face to face, it can be difficult to convey tone and mood accurately. A good way to overcome these difficulties is to always interpret others’ writing in good faith. When declining someone’s proposal, be polite, and express your own position clearly. Conduct yourself with dignity in the online space that is open source.