I started CodeApprove (https://codeapprove.com) because I saw from the inside how big tech companies (Google, Meta, etc) optimize PR review. Rather than try to automate, replace, or artificially speed up the process, instead they've made great interfaces that allow reviewers and authors to always know whose "turn" it is in a code review and quickly find what they need to address. The goal is to get to resolution (or in other words, consensus) in as few rounds as possible and to make code review painless to the rounds themselves are short. A good tool goes a long way here.
Last year I also wrote a quick survey of other tools which I've seen in the space and think are promising: https://medium.com/codeapprove/the-best-modern-code-review-t...
That list is already a bit out of date, I can think of some newcomers (Planar, Pullpo) which would also be on the list if I was writing it today.
I've helped a bunch of teams make their code review process better (tools aside) and if you're looking for free advice on how to help your team review better I'm always happy to talk to people about this. Email is in my bio.
For the most part they loved the open-source work (a lot more flexibility than internal systems) but they all complained about the code review! It just didn't give them the same rapid drive to consensus they got with Google's internal tools. And I think they were right.
So after I left Google I was very inspired to work on a better code review system for developers on GitHub. And that's how CodeApprove was born!
The first code comments still happen in GitHub, but then those comments go to slack (with the code context) so that the code review conversation happens there.
We disabled pullpo for these people. However they can still collaborate with the people that use pullpo. The comments they send to github are brought to slack too and viceversa.
Still, code reviews take 2 to 3 times less
In this approach, PR authors are considered free of trust to evaluate themselves if:
- The code doesn’t require a code review since the changes are trivial (Ship)
- They’d like to show the code changes to colleagues and get their feedback (Show); This mode can sound totally counternatural as the feedback can be provided after the merge. This is part of the paradigm shift.
- The code requires a review (Ask)
So, instead of adding more people to review the code, we reconsider the necessity for each PR to be approved. This is how we positively impacted the lead time for change.