We arrived at a similar concept, though ours it the negation of this: we have a series of deterministic checks that can potentially add the `needs-human-review` tag to a PR. If that tag isn't present, you can merge your own PR; otherwise you need at least one human.
I think we're probably around 50/50 needing human review vs not.
Our rules for whether something needs a human review are currently mostly filepath-based: are you touching the api, or an important internal contract, or adding db migrations? Though I'd like to make it a bit smarter as we're definitely getting false positives.
I introduced a similar change at work for Terraform changes. One big PR can create many planned changes in many different root modules; one tiny requested change in that PR can thus hold up a lot of stuff that doesn't need to be held up. So I added Claude rules/skills that instruct AI to break up the PR into the smallest possible functional/mergeable units of work, make one PR for each, and stack PRs on inter-dependencies. The result may be 40 PRs, but 38 of them can be approved and merged immediately. This lands more changes sooner, so work being started by others incorporates more current work, leading to less rework/refactoring/rebase fixes. It's Continuous Integration on autopilot. (https://martinfowler.com/articles/continuousIntegration.html)
The author is only seeing 10% as small-change, but my version has 80% as small-change. This is due to Terraform forcing you to be intentional about the borders of functional software. There is a minimum-viable-deployable component in Terraform called a Resource: you can add more resources to your module (increasing the scope), but you can't get any smaller than one resource. So it's relatively easy to define what makes a module functional, and reason about how big it gets, before deciding to break the module up. (Technically you can -target specific parts of a single resource but it's quite frowned upon)
Compare to traditional software design, where there is no absolute minimum functionality. You can make "minimum functional software" as huge or as tiny as you want. Different people design their software different ways (often unintentionally) resulting in low cohesion and a very large scope of changes required for minimum function. If you want smaller changes, you have to intentionally design your software for it.
> Something is a small-change if it meets all of these criteria it is less than 1,000 lines of code
Only my personal view but even 1000 LoC is not a "small change".
We arrived at a similar concept, though ours it the negation of this: we have a series of deterministic checks that can potentially add the `needs-human-review` tag to a PR. If that tag isn't present, you can merge your own PR; otherwise you need at least one human.
I think we're probably around 50/50 needing human review vs not.
Our rules for whether something needs a human review are currently mostly filepath-based: are you touching the api, or an important internal contract, or adding db migrations? Though I'd like to make it a bit smarter as we're definitely getting false positives.
I introduced a similar change at work for Terraform changes. One big PR can create many planned changes in many different root modules; one tiny requested change in that PR can thus hold up a lot of stuff that doesn't need to be held up. So I added Claude rules/skills that instruct AI to break up the PR into the smallest possible functional/mergeable units of work, make one PR for each, and stack PRs on inter-dependencies. The result may be 40 PRs, but 38 of them can be approved and merged immediately. This lands more changes sooner, so work being started by others incorporates more current work, leading to less rework/refactoring/rebase fixes. It's Continuous Integration on autopilot. (https://martinfowler.com/articles/continuousIntegration.html)
The author is only seeing 10% as small-change, but my version has 80% as small-change. This is due to Terraform forcing you to be intentional about the borders of functional software. There is a minimum-viable-deployable component in Terraform called a Resource: you can add more resources to your module (increasing the scope), but you can't get any smaller than one resource. So it's relatively easy to define what makes a module functional, and reason about how big it gets, before deciding to break the module up. (Technically you can -target specific parts of a single resource but it's quite frowned upon)
Compare to traditional software design, where there is no absolute minimum functionality. You can make "minimum functional software" as huge or as tiny as you want. Different people design their software different ways (often unintentionally) resulting in low cohesion and a very large scope of changes required for minimum function. If you want smaller changes, you have to intentionally design your software for it.