Removing inactive maintainers
In open source projects, we tend to grant privileges far more often than we remove them. This is understandable, but risky. First, keeping inactive people on the maintainer list means someone may go to them with a question and be frustrated when they don’t get an answer. More importantly, it presents a security risk. Compromised accounts remain a common attack vector, and it’s much easier to escape notice if the account owner isn’t using the account. It behooves the project to keep the maintainer (or other privileged role) list tidy.
There are a few reasons that trimming the maintainer list doesn’t happen. First, it’s boring, tedious work. Who wants to do that? Second, it’s complicated work. What does it mean to be “inactive”? Third, it can lead to hurt feelings. People who earn privileges absorb that role into their identity and they don’t want to let it go. This is a case where the perfect quickly becomes the enemy of the good (or okay-ish). Let’s look at each of the reasons in turn.
Overcoming the objections
Project and community management tasks often end up on the “avoid: no fun” pile. They only seem like no fun because they are. But “fun” and “important for the project” aren’t the same. Changing the air filter in my furnace isn’t fun, but it’s important for the health and safety of my family. Ideally, the inactive maintainer process is automated and runs regularly, but building that automation takes work. So if you go through the list and identify inactive maintainers once or twice a year, that’s better than nothing.
“Inactive” can mean a lot of things. Does one activity in a six month period count? Does the activity have to be “sustained”? You can define it in the way that’s most convenient to you. The goal isn’t to be rigorous and precise, it’s just some spring cleaning. You can start by just asking yourself “have I seen So-and-so around lately?” If the answer is “yes”, then they’re active. Again, it would be nice if you could automate it. You don’t need to wait for that.
The feelings objection is the hardest one. We’re all friends here and we don’t want to hurt our friends’ feelings. Unlike the other two, you can’t really half-ass this one, so you need a policy that treats people with kindness. Let’s move on to that.
Creating an inactive maintainers policy
Here are some features of a good inactive maintainers policy:
- Define “inactive” unambiguously. “We will remove maintainers who have not been active in N months, where ‘active’ means having done X, Y, Z.” Six or twelve months is probably a good place to start. Be sure to include as many activities as you can reasonably determine. Think about what’s important to keep that status: commits, issues opened/closed/commented/reviewed, pull requests, mailing list posts, and so on.
- Define “inactive” generously. For the most part, the bigger concern is “is this person still in control of their account?” not “is this person earning enough points to keep their privileges?” So if someone’s activity isn’t what you’d want for them to initially earn maintainer status, that’s probably okay.
- Check for inactive maintainers at a set time. If you have calendar-based releases, check at a given point in the release cycle. Right after the release is a good starting point.
- Automate what you can. The time spent really does pay off pretty quickly. Fedora is a large and complicated project, so evaluating activity requires checking half a dozen services. Mattia Verga wrote a script that handles the checks and creates issues in a repo to track the inactive packagers.
- Don’t remove anyone without notice. This is a big part of the “don’t hurt your friends’ feelings” requirement. Give people a chance to respond. Some will respond by being more active. Some will respond by saying “yeah, I no longer have the time and/or interest, so go ahead and drop me.” Some won’t respond at all. If someone wants to remain, let them.
- Conspicuously acknowledge the people you’re removing. Add people as a “maintainer emeritus”. Mention them in a blog post, release notes, or other vehicle for public praise.
- Allow easy reinstatement. If someone lapses and later wants to return, let them. Don’t make them go through the whole process again. It’s much easier to let a role go if you know you can easily get it back later.
- Leave some privileges for people on emeritus status. Keeping their name on a list of historical maintainers, letting them keep a project email address, giving them voting privileges on certain issues, and other privileges will help people who are inactive still feel valued in the project.
It will take a few tries to get the policy just right. Don’t be afraid to try it.