Challenging the Pull Request Orthodoxy

A thread showed up in my Twitter feed the other day from Dragan Stepanović about the low efficiency of pull requests for small changes and refactorings.

I think we've all felt that hesitancy to refactor something because it didn't seem valuable enough to push through a whole pull request approval process.

In the comments on Dragan's thread, someone mentioned an article on Martin Fowler's blog called Ship / Show / Ask. The author, Rouan Wilsenach, proposes that instead of requiring every change to be approved before it can be merged into the mainline, we can decide on a case-by-case basis whether to Ship (merge with no discussion), Show (merge and then discuss), or Ask (discuss and then merge).

My experience on teams that use pull requests has always been that every change follows the Ask path. For any change, no matter what it is, we submit a pull request, it has to be approved by one or more other developers, and only then can it be merged. But this process is not really worth the trouble and delay for some changes, depending on context such as who made the change, how much the change is like other changes that have been made many times, and where the change has been made.

As Rouan explains, some good candidates for the Ship option are things like:

• I added a feature using an established pattern
• I fixed an unremarkable bug
• I updated documentation

Some candidates for the Show option would be:

• I would love your feedback on how this code could be better
• Look at this new approach or pattern I used
• What an interesting bug! Look how I fixed it

Finally, the Ask option (a traditional pull request) could be reserved for things like:

• Will this work?
• How do we feel about this new approach?
• I need help to make this better please

Always going with the Ask option, as most teams do, has some downsides that can be avoided with this more flexible model, as the articles explains:

The unavoidable thing about waiting for approval is that it takes time. If too many changes are in the queue for feedback, either the quality of the feedback goes down or progress slows down. 

The reason you’re reliant on a lot of “Asking” might be that you have trust issues. “All changes must be approved” or “Every pull request needs 2 reviewers” are common policies, but they show a lack of trust in the development team.

Pull requests are a great tool for modern software development, especially when contrasted with a free-for-all approach where nothing is reviewed. But it's important to remember that they're not necessarily appropriate for all situations.