[cesnja]

Due to (async) code reviews slowing down the development, we've adopted some workflows described at https://martinfowler.com/articles/ship-show-ask.html and it's working out pretty great. The committer decides how many approvals they need to merge a pull request, based on how confident they are about the code they wrote. This allows us to quickly merge small incremental improvements that would otherwise be bundled in a crowded feature pull request.

[kageiit]

I feel like the number of reviewers should be predicated more on how well the reviewers understand the relevant part of the code review.

Most code review tooling is too coarse in the sense that it expects a small number of reviewers to know the full context of the change or has too many reviewers that slow down things.

Tools to show relevant parts of the change to specific reviewers and potentially break apart a large change into smaller ones automatically will go a long way especially in large scale codebases or when team sizes are large enough that the full context is not understood by everyone on the team

[ozim]

This is wrong direction IMO.

That is a technical solution to something that could be handled by the team. While tooling might help people in the team still have to make same and sound decisions like unblocking team member that needs to do a quick fix.