pull_requests
The orthodoxy is taking to the internet to decide whether pull requests are gatekeepey. They are, and that is only part of what PRs are about. Considered holistically, everything about how pull requests work is unnecessary.
Pull requests apply to data, but commonly to text documents. They're commonest in software development, and I do that, so this is what I mean: pull requests embody changes to software systems. The model is a static software system maintained (as in, preserved) by a core team that's often one person but also often more. Suddenly, a wild author that's often one person but sometimes more appears, advocating for a change that they have already written to be incorporated into this peaceful system. The conservators argue against incorporation, until all arguments are dispensed with and finally the author gets to contribute the change that they've already written.
Pull requests encode a social dynamic. The author of a pull request has some change to "upstream", and there's a person or people with editing rights over the "upstream" repository who get to decide whether to accept the pull request by merging the change. The pull request author may be, but usually isn't, a member of that group who can decide whether to accept the pull.
The author has:
- an ability to make a change to code
- access to an existing change
- a desire to see that change taken in "upstream"
- potentially the ability to make the change directly to "upstream"'s version, but probably not.
- the right to abandon a change at any time: the change is already made, it will never be adopted.
The upstream editors have:
- a repository of code
- a view of proposed changes
- power to choose whether to adopt any of the proposed changes
- ability to reject proposals outright, or suggest meta-changes
- usually the ability to make changes directly to the repository
- the right to abandon a change at any time: the change is already made by someone else, it will never be adopted.
The social dynamic has power on only one side, and effort on the other side, therefore the pull request encodes a power imbalance. If someone has the right to "request changes" or "block" a pull request, and that person isn't the author, then pull requests are gatekeepey. If your team's workflow depends on using the pull request as a gate to reject or rework changes, then it is a gatekeepey workflow. That might not be bad but it is true.
There are many other models. A "push announcement" model, where upstream declares that they've created a change and _downstream_ get to decide whether to incorporate it or not. A "wikicode" model, where anyone can write changes to the upstream repository. A "paired-wiki" model, where anyone can propose a change and anyone else can review and accept it upstream. A "user's council" model, where the people who use the software vote, or send representatives to vote, on whether changes get accepted. An "anarchic bazaar" model where there's no upstream or downstream, just individuals negotiating on which of their changes to swap with other people. A "mentor request" model, where once a pull request is made, it's the editor's responsibility to rework it until it lands, and coach the author on their meta-changes.
It's true that pull requests offer a convenient opportunity for code review, because you have a single place where a single concept in the software is pulled out and available for inspection. Again other models are possible. A "review after" model, in which pull requests are incorporated and then reviewed. A "peer review" model, where an author reviews another author's pull request. A "periodic" model, where the code gets reviewed every Friday afternoon. A "developer certificate of quality" model, so authors self-affirm the worthiness of their change in the way that developer certificates of origin have them affirm the authorship. A "review never" model. A "review when a bug gets reported" model. A "review upfront" model, where the people involved design the code before the author writes the pull request. A "newer is better" model, where the author proposes one change and reviews the existing code in the area they want to change. A "by the numbers" model, where the code is acceptable if it passes automated tests.
It's now that you need to jump down another rabbit hole. Pull requests are being used for code review, so you need to know what the code review is being used for. If your reason is "I feel important when I reject other contributions" then you'll be a super awesome Googler and an even better Xoogler. Another reason is "so the team has a handle on the whole code base" but then why have pull requests ever, just have your team write the code. "To meet the quality bar", a computer can check that, remember the "by the numbers" model. Actually you probably have code review because "everybody else has code review", that's really why anything is done in coding. If it's hard enough to support we call it software engineering and it sounds fancy so nobody questions it. You should question it, more if you're spending money on it.
Pull requests embody two things: the change, and the advocacy for accepting the change. Those can be split. A "negotiation" model, where the pull request represents the desire to see a change, and once it's approved someone starts working on the code. A "predetermined" model, where the list of changes is advocated for in advance and all that needs doing is the programming.
You probably recognize the predetermined model from your workplace. Every two weeks the team (a "self organizing team", as each individual gets their selves organized by the product owner) decides which tickets to pull from "the backlog" into "the sprint", then each individual takes a ticket and writes the change. If they go ahead and make a pull request containing that change, you're wasting effort, as you've already done half the pull request work.
Clearly pull requests are a bad model for open source, too. Freedom to use the software for any purpose, to study how the software works, to change it to suit my needs, and to share my improvements with my neighbors are all freedoms that can only be curtailed by the imposition of gatekeepers. The right model is the anarchic bazaar. I use my software which does what I want. I make a change that improves it for me: rather than arguing with some preservatives over whether everyone should take that change, I announce that change. You take it or leave it. You announce your changes. I take them or leave them. ActivityPub for patches.
Home