Preventing gradual growth of issues through small changesets

Sonarqube currently does not enforce all measures on a quality gate where a change-set is under a certain size - currently hard-coded to 20 lines. This allows for issues to be gradually introduced into a code-base by making small changes that don’t meet all the relevant standards (e.g. missing code coverage) which effectively allows gradual ‘rot’ of a code-base.

I’d raised a Pull Request with a proposed solution for this, but have had it rejected because it can have some unexpected impact and it was suggested I raise a topic here to agree an approach. Given my initial approach was rejected, I’d like to start a discussion on how we should be overcoming this issue, as I don’t particularly agree that giving individual administrators the option of managing this value will cause problematic impacts, and would ideally like to resolve this issue to prevent the gradual creep of problems in code-bases I manage.

Note: SONAR-10485 was the ticket I’d raised my change against, which spawns from a previous community thread and has since had various other discussion linked to it, but without any obvious work-around for anyone who wants to enforce clean-code with lower thresholds, hence me raising this.

Surely being configurable through the quality gate would be the easiest way?
The harder way would be a new mathematical metric that estimates effort required to add missing coverage for the lines. If the effort is over some sort of threshold compared to the code changes then ignore it (similar to tech debt calculation i guess)

For us the 20 lines limit never applies because our release process does changes that cause over 20 lines of changes, about 50 line changes to poms.

Additionally currently if someone submits a massive new test, but someone else submits a single line code change that single line gets full checks because the test counts against the 20 lines limit.

Additionally I wonder if it should be configurable per rule type. Aka allow missing new code coverage to be skipped but still fail on all new code smells for example.