What makes for a great open source colleague?
Another question I get asked a lot is “how can I participate better in open source?”.
Different projects need different input. Everything comes down to the fact that people run things in different ways. Some people like getting issues, others like getting pull requests. Some want documentation fixes, others would rather 3rd party documentation.
Understanding these differences can be crucial in how your interactions are perceived by the community.
The first calling point should always be about communication, not code. Reach out the project owner. See if they have a dedicated chat channel, or Twitter. If the project is big enough, the people involved in that community will be able to guide you to the right place. If a project is small, opening an issue is a fine first step. Explain what you want to do and why. Take a look at their other bug reports, and try to follow the style the other bug reports used. If there aren’t any, a good default is “problem — expected — actual — solution”. Explain the problem, show what you expected, demonstrate the actual response, and provide a suggestion solution if you’ve thought of one. If you want to make a PR, ask them if they want one.
What happens from here is entirely up the project owner and community. If they don’t want a PR, your job is done — opening an issue can sometimes be more helpful than submitting any code.
Let’s imagine they do want a PR. Now that you have a communication channel open with the owner, you can more easily ask for feedback on a proposed solution. Get stuck implementing something? Open a work-in-progress PR and ask. Not sure about the ideal API? Ask.
This communication bridge serves two main purposes: 1) it lets the project owner know what you are going to do and help guide you the right way 2) it protects you from spending any time going down the wrong direction.
A common pitfall people do is to open a PR out of the blue on projects that don’t want to be take in that direction, and then feeling disappointed when it’s not merged. Open source is all about working together to make something better. If I never talked to my colleagues before doing something, we’d all be confused and a little bit lost.
Adding someone’s contribution to a project involves a two-way trust binding. The contributor must trust the project owner to do the right thing, and the project owner must trust the contributor’s submission to fit their project.
tl;dr
Being a good contributor to open source projects is more about talking and discussion than it ever is about code. Different projects have different needs. Each interaction should open with a discussion, and end with a discussion.
