The Pull Request Hack is not enough

Years ago, I read The Pull Request Hack, a blog post advocating for a radical way of collaborating on FOSS: “Whenever somebody sends you a pull request, give them commit access to your project.” The post is really worth a read. More than a decade later, I think it aged well: a lot of FOSS projects would benefit from granting permissions to contributors more proactively.

You might argue that the situation has changed: since that blog post, some pretty traumatizing social engineering attacks have happened, such as the XZ Utils backdoor or the event-stream incident. In both of those examples, malicious actors abused write accesses that maintainers granted them willingly, after seeing a track record of well-intended contributions. It can be tempting to react to those attacks by raising the bar for granting privileges in FOSS projects, but I think it’s misguided. In both cases, the maintainers were particularly vulnerable to social engineering because they were isolated and overworked.¹ Intuitively, growing a project team proactively helps reduce this risk, both by having more eyes to scrutinize things and by those eyes being less strained. In other words:

If you don’t onboard contributors proactively, then you effectively select project members for their social engineering abilities.

So, I want to reflect here on my attempts to practice the Pull Request Hack in the past years. I want to share what I have learned from many experiences, either in the positions of maintainer or of new contributor. Needless to say, those are rules that I unfortunately still often fail to follow myself.

Communication is key

Granting project accesses is great, but it’s important to explain to the new project member what they are invited to do with it. I have often made the mistake of just sending an invite to the GitHub project (for instance, OpenRefine), without much other form of process.

First, people might just not see the invitation or not understand where it came from. Second, they might not be sure which accesses they’ve been granted exactly, and under which conditions they are supposed to use them. Most people are actually pretty careful and won’t exercise those rights because they don’t want to break things.

It can be useful to explain why you are granting those accesses: is it because you generally trust them to use those well if you were to disappear from the project (so, as a means of increasing the bus factor), or is it because you’re actively looking for help in a specific area right now? Having clarity on that might increase the chances that people use the permissions you grant.

Granting meaningful rights

So you granted this contributor full write access to the Git repository for this Python library that you’re tired of maintaining. Good job! But if making releases involve manually uploading the library to PyPI and you are the only owner of the package on that platform, then they need you to stay reactive to make those releases. Similarly, if the repository is still stored under your own GitHub account and not under an organization one, they won’t be able to invite other contributors themselves.

It’s completely legitimate (and even advisable) not to immediately grant full owner rights to random contributors. Those initial permissions can still be really heartwarming for newcomers. But more advanced rights are often withheld indefinitely from onboarded contributors, with the understanding that they remain the prerogative of a sort of BDFL. Personally, signs of this dynamic discourage me pretty fast from contributing.

Expiring memberships

If you’re serious about using that Pull Request Hack in your project, then you quickly end up with a lot of project members, most of whom have just contributed a couple of things in the past but moved on to other activities since. The fact that someone did not use the privileges they were granted is not a problem on its own: it’s even expected that it makes up the majority of cases. Those cases are just there to enable the occasional miracle of someone taking up the offer and climbing higher up on the contributor ladder.

But that has downsides: the list of project members is cluttered and it’s hard to know who is actually participating. It’s also more risky, as dormant accounts could get compromised and damage the project.

So you also need to clean up those members in one way or another. And that’s tricky to do well. Ideally, you want to:

• Reach out to the contributors before removing them, so that they have a chance of letting you know if they have any interest in contributing again. That’s a great occasion to remind them of your project and could lead to retaining them. It also avoids giving them the bad taste of discovering it after the fact from a cold system notification.
• Have a criterion to decide who to remove, so that it doesn’t feel like there is resentment behind it. With bonus points if the criterion is implemented in some system that generates notifications for those expirations. I find it very hard to remove project members on my own initiative, because they are (almost always) valuable contributors that I am thankful to, or even befriended with. So it helps if there is some sort of system supporting me for that.

Get a governance model!

All of those principles are a lot easier to follow if you have adopted a governance model for your project. If there is a document describing the different roles people can have in your project and how one can get from one to the other, then:

• Communicating about the expectations around how permissions are used is a lot easier: you can point people to that document.
• Granting meaningful rights is a lot easier, because your governance document defines your own role in the project too, and how contributors can expect to reach it (if at all).
• The criteria for expiring memberships should of course also be documented there, which serves as a useful anchoring, making it clear that cleaning up the project members list is not a personal vendetta against inactive contributors.

If you are looking for inspirations, why not take a look at the model we use in Mergiraf? It is tailored to small projects and is easy to adopt. The FOSS Governance Collection contains a lot of useful examples from more established projects. The OSS Watch website also offers useful advice and templates.