At Van Patten Media, we release a lot of open source code. As a consequence, we receive a lot of suggestions and feedback, along with “pull requests” — submissions of code from other developers.
There are a lot of blog posts devoted to being better contributors to open source, but very few on being better leaders of open source projects (or, at least, better code reviewers).
Recently I’ve encountered several situations where people running open source projects haven’t handled pull requests in a way I thought was appropriate. Of course, to a degree this is all subjective, but I still think it’s worth sharing a few of the tips I use to make our open source projects more welcoming and leave developers happy.
Start with gratitude
The fact that someone wants to use your open source software should make you feel pretty good. But the fact that someone likes it so much that they want to help you make it better? That’s worth of applause! Before you’ve even looked at the code, start with a simple “thank you”. It goes a long way to making contributors feel valued.
Try to understand the problem
The code might be a mess—badly formatted, poorly developed—but don’t worry about that just yet. Before you go any further, try to understand why the user is submitting this fix. What’s the problem they’re trying to solve? Forming premature opinions based on the quality of the code can subconsciously position you against a developer who may have a valid issue even though they’re not a skilled developer.
Offer guidance
If the problem is valid, but the code is weak, offer some suggestions on how the pull request can be improved. If you can, make yourself directly available to help the contributor, or point them toward documentation or examples that might help improve their work.
Be clear in rejection
Don’t give vague reasons for rejecting code submissions. Don’t close pull requests because the code is sloppy without giving the developer a chance to improve their work. Have a clear, thoughtful understanding of why the problem being solved is invalid, redundant, or just not something within the scope of your vision for the software. Communicate this with empathy, stating your case professionally and reasonably, so they don’t feel like they’ve been sentenced without due process.
Be open to changing your mind
Don’t shut the door once you close the request. Be gracious (see point 1); invite the contributor to make future improvements, or to rethink their problem and try again with a submission that tackles the problem from another angle. And, above all, don’t get entrenched and restrained by your own biases. Open source software is, in many ways, a shared experience. If other users or developers show support for a new idea, don’t let pride dictate your response. Be receptive to new ideas.
If you keep these five things in mind, you’ll be on your way to happier contributors, a better community tone, more thoughtful discussion, and better code. Without it, you risk alienating users and isolating yourself.
And if you’re not prepared to keep these in mind? Well, maybe you should re-consider open-sourcing that project in the first place!