Blog by Sumana Harihareswara, Changeset founder
How to Teach And Include Volunteers who Write Poor Patches
Hi, reader. I wrote this in 2017 and it's now more than five years old. So it may be very out of date; the world, and I, have changed a lot since I wrote it! I'm keeping this up for historical archive purposes, but the me of today may 100% disagree with what I said then. I rarely edit posts after publishing them, but if I do, I usually leave a note in italics to mark the edit and the reason. If this post is particularly offensive or breaches someone's privacy, please contact me.
You help run an open source software community, and you've successfully signalled that you're open to new contributors, including people who aren't professional software engineers. And you've already got an easy developer setup process and great test coverage so it's easy for new people to get up and running fast. Great!
Some of the volunteers who join you are less-skilled programmers, and they're submitting pull requests/patches that need a lot of review and reworking before you can merge them.
How do you improve these volunteers' work, help them do productive things for the project, and encourage and include them?
My suggestions for you fall into three categories: helping them improve their code, dealing with the poor-quality pull requests themselves, and redirecting their energies to improve the project in other ways.
Thanks to Noah Swartz for starting a conversation at Maintainerati that spurred me to write this post.
05 Apr 2017, 14:38 p.m.
I've also found that it's nice to integrate code correctness and style checks into your test suite. In the pump.io project, if your code doesn't meet our style guide, the Travis build will fail. This reduces the contributor's dependence on the maintainer, which is good on both sides - the maintainer can not even bother to examine style and just focus on the code, and the contributor doesn't have to wait for the maintainer to tell them about cosmetic problems.
This also has a nice side benefit, especially in understaffed projects where there aren't enough people to do code review on all patches, in that it pushes the maintainer to also write better code. I've caught loads of linter and style checker violations that I checked in without noticing, because it broke the build.