Thanks, great addition!

Hi Michele, thanks for your compliment. Appreciate it. I created an awesome code review checklists github repository. You can already find a couple of checklists. Also, feel free to add new ones that you deem good: https://github.com/mgreiler/awesome-code-review-checklists

Hi Mike, thanks for letting me know. Unfortunately, I did not find a new version of this blog post anymore.

Hi Mark, this information comes from studies on software inspection. Yet, also, when analyzing open-source software and asynchronous modern peer reviews, Peter Rigby found that the medium number of reviewers is 2. This represents self-selected reviewers. Here is a good article from Peter that mentions the 2 reviewer findings: Contemporary Peer Review in Action: Lessons from Open Source Developmenthttps://ieeexplore.ieee.org/abstract/document/6148202

can you cite these studies? I’d love to share this with my team.

Do you know of an alternative way to access Grayson Koonce’s post? It seems to be unavailable now. 🙁

The developer opens stacked PRs, similar to how you described. Code gets reviewed in the order the PRs were opened, and gets merged in the order the PRs were opened.

In fact, there should be an emphasis to get PRs merged into the trunk/main/master branch asap.
The goal here is not only to get the code reviewed in smaller chunks, but also let it become part of the code base in smaller chunks.

This approach is very scalable, and is easy to adopt because it’s very rare to have more than 2 stacked PRs (since PRs are merged asap).

[1]: https://trunkbaseddevelopment.com/

Thank you, Marco!

Hi Nicolas,

you review the changes from bottom to top (as you suggested), but you merge them from top to bottom. The reason for this is merely a technical one (how git and branches work). But, you are right, if git or the tooling around would support it more easily, it would make sense to merge the PR right after you reviewed it and thus bottom to top. But this will create more merge conflicts and hassle with the branches for you. So, that’s the reason why I recommend merging only after you reviewed the whole stack. Then, you integrate and merge the stacked together.

Yes, you are right. It’s not trivial. It’s a workaround that helps us improve code comprehension for the reviewer. Unfortunately, the current tools such as GitHub, Gitlab, and Bitbucket do not support this use case natively. I hope over time, it will be easier for the developer by using tooling to do this.

What you measure, that’s what you’re likely to get.

I would be afraid that if we reward developers for rejecting PR’s, then the culture will start providing PRs that can be rejected on superfluous grounds, to make it look like everyone is becoming a much better code reviewer. But the end product won’t be any better, and business value will suffer.

About merging stacks of PRs, I’m surprised you advise to merge top to bottom, while doing the reverse seems more logical to me.
For example, if doing so, when starting by merging fb-ui -> fb-businesslogic, someone willing to review the changes brought by fb-businesslogic, would have then to take into account the aggregated diff of the two branches, while the fb-ui part has already been reviewed and considered ready for being merged. And even if aware of this, the reviewer would see a diff, polluted by already reviewed changes.
What’s more, between the time fb-ui has been merged into fb-businesslogic, the develop branch can have changed in a way that makes fb-ui not mergeable into it anymore.

That’s why in this kind of situation, we tend to encourage doing the contrary, that is reviewing then merging fb-database first. the fb-businesslogic PR will get retargeted automatically by tools like bitbucket (but it can be done manually too).
This approach allows to really split the reviewing / merging process into smaller, more independent chunks IMHO. But of course, it relies on each individual branch being robust enough to not break develop until the 2 other PRs can be merged.