TF? distinguishes structure changes and behavior changes. Structure changes are (usually) reversible and behavior changes are not. How can you use this distinction?
Here’s an experiment your team (or even just you yourself) could try today. Constrain PRs to only contain one kind of change or the other. Never both. Label the PRs somehow, so reviewers (assuming you still have reviewers, we’ll get to that another day) know what to expect.
That’s it. What you may find (comment below and tell me what really happens) is:
PRs will be smaller. What used to be one big PR will now be a sequence.
Structure PRs will be approved quickly.
Sometimes you will make a change that is a jumble of structure and behavior changes and you’ll have to untangle it (even recode it altogether) to get your stream of segregated PRs.
Try it for a week. See what happens.
This reminds me of Arlo’s commit notation: https://github.com/RefactoringCombos/ArlosCommitNotation
This is part of the essence of go/small-cls https://google.github.io/eng-practices/review/developer/small-cls.html one of the most foundational engineering practices at Google.