Ship / Show / Ask is a methodology to get faster releases with pull requests. With Reviewpad you get a code review platform that allows teams to naturally apply this methodology and extend it to new scenarios that give you greater velocity and team communication by going beyond pull requests.

Pull requests have been widely adopted by software teams as a way to collaborate in codebases. For all their benefits when contributing to open source projects, when it comes to projects where individual contributors have the power to merge their changes, pull requests slow software development.

Pull Requests Are Slowing You Down

The first reason pull requests are slowing you down is that theyare being used to document developer work.

If you need to open a pull request for every change, regardless of whether it is a new feature or a cosmetic change in a file, inevitably pull requests will be a bottleneck to integrate changes into a product.

When you associate “pull request” to “unit of dev work” and combine it with automated CI/CD pipelines, you get an overhead of time + resources that doesn’t always make sense in a fast-paced environment.

The second reason why pull requests are slowing you down is that we have associated code reviews with pull requests to a degree that we now use them interchangeably.

The truth is that not all pull requests need code reviews.

By enforcing processes such as “every pull request must be approved by a team member”, which is not aware of the actual changes, we have created a wait time in the process that is unreasonable in many situations.

This coupling of code reviews with pull requests has another major pitfall.

Because reviewing code is hard and the tooling around code reviews in pull requests is quite limited, it is standard to constraint the number of changes in a pull request. This means that changes that should be pushed together have to be broken up to accommodate this process.

Ship / Show / Ask

Ship / Show / Ask is a methodology to get faster releases by categorising changes into Ship (merge without pull request), Show (merge with pull request + later review) and Ask (standard pull request with review approval).

This methodology is powerful but still relies on the existence of pull requests. This limits you to always having to discuss changes between branches and trigger some automated process even when you just want to ask. It can also happen that you might need to do a later review but the changes were wrongly classified as Ship.

We think there’s a better way.

Code Reviews without Pull Requests

Reviewpad decouples code reviews from pull requests so that you fully embrace the idea that not all pull requests need code reviews and that code reviews can be done without pull requests.

Let’s take a look!

With Reviewpad it is possible to practice the Ship / Show / Ask methodology in a more flexible way. In fact, what we have been practicing at Reviewpad is a Ship / Show / Ask / Revise methodology.

Ship

If you want to push a change to the main branch and you have the confidence to do so, you should just do it.

You shouldn’t have to wait for the CI checks or a review approval on a pull request to do so. Anyway, you typically run some CI pipeline in the main branch so you can always backtrack if something goes terribly wrong. You should have the power and trust to simply push changes.

Show

A Show process is when you run the CI checks over a branch before the merge, merge and only later get a review.

Although you can do this with a pull request, with Reviewpad there is really no need to do so. You can simply wait for the CI pipeline to finish when you push to a feature branch, merge, and then open a code review between those commits in the main branch. You can choose to open this code review to get later feedback between the branches or in the main branch itself.

Ask

The Ask process happens when you want feedback on our ongoing work.

Here we pause. We make our changes on a branch, we open a Pull Request, and we wait for feedback before merging. Maybe we’re not sure we’ve taken the right approach.

Unfortunately, for many developers, the idea of a pull request is more of a “work done” than a “work in progress”. In fact, mixing the two can be quite confusing because sometimes you just want early feedback on code that you know will not pass the CI checks.

Reviewpad allows you to create a code review between commits to get that feedback, revise it, close this code review and then open a pull request kicking off the official merge process in a team. That encourages more collaboration and communication about the code.

You can use the same code review interface regardless if you what you are reviewing is a pull request or just a diff between two commits.

Revise

So what happens if you want to revise some code that went into the main branch? This could be useful in the case of a huge load of pull requests with no time to review them or because you wrongly considered changes to be in “Ship” mode.

By going beyond the limitation of reviewing code with pull requests you can revise code in a single branch.

This allows you to create code reviews that document specific parts of the code, or to keep track of changes when you spend some time away from the project.

If you find issues in this mode, you can always connect to the code host by creating issues from comments.

Conclusion

With Reviewpad, you get a tool that provides the flexibility of new methodologies such as Ship / Show / Ask and beyond so that you can get the full benefits of code reviews and continuous integration without the limitations of pull requests.

You can try now at beta.reviewpad.com.