A Proposal for Topic Maintainers

This post originally appeared on the Software Carpentry website.

I can lift ten pounds. I can even still lift a hundred pounds, though my back won't thank me, but I can't lift a thousand pounds. Similarly, while I was able to review changes to our lessons when only half a dozen people were contributing, there are now almost sixty pull requests queued up, some of which have been waiting for attention for several months.

The solution we'd like to try, which is borrowed from other open source projects, is to give specific people authority to maintain specific parts of our core material. These maintainers will not be responsible for developing lessons themselves, though they may of course do so. Instead, their job will be to keep issues and pull requests moving by reviewing, managing discussion, merging into the master branch, and so on.

In fact, what we'd like to try is to have both a lead maintainer and a backup maintainer for each topic. The backup will give the lead someone to bounce ideas off, and will pick up the slack when the lead is busy (because we all get busy sometimes). The backup may become the next lead, but we won't worry about that until we know whether this idea works or not.

To be a maintainer, a person should:

• be knowledgeable in the topic area (though not necessarily an expert);
• know how to wrangle pull requests on GitHub;
• be a good communicator;
• have about an hour a week to spend on this (most topics don't need this much attention most of the time, but some do get busy, and people get discouraged if their pull requests languish); and
• have taught often enough to be able to evaluate whether proposed additions are suitable for our students. (Many of our contributors, including me, are prone to over-estimating what most of our learners are ready for.)

We'll put this to a vote at the end-of-September lab meeting. If it passes, I'll invite a few people to be maintainers for our core novice lessons for the next six months. If it looks like this is working, we'll then come up with a way for the community as a whole to decide who should maintain what.