Blog by Sumana Harihareswara, Changeset founder

04 Apr 2017, 12:37 p.m.

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.

Teaching them to improve their code

Dealing with poor patches themselves

Using their knowledge and curiosity to improve the project in other ways

  • Ask these developers to write "discovery reports". They're already user-testing your developer onboarding process; ask them for their experiences, so you can find and fix pain points.
  • Ask them to run through some manual testing (example manual testing guide from Zulip), and to tell you how long certain kinds of tests took, so you can get bug reports and improve the docs.
  • Ask them to teach about your project in their communities -- to develop learning and presentation materials and speak at meetups. You may have just found your most enthusiastic marketer.
This list is absolutely not the be-all and end-all for this topic; I'd like to know what approaches others use.


Thanks to Noah Swartz for starting a conversation at Maintainerati that spurred me to write this post.

Comments

AJ Jordan
https://strugee.net
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.