Streamlined SCM for routine, non-breaking changes

[preston]

(Entering as an issue for tracking/discussion per today's DQIC call. CC @marciantemark @brynrhodes)

Today, every change goes through the same gate of a PR plus manual peer review. The process is appropriate for strategic, breaking, or specification-aligned changes, but works less well for operational and low-risk maintenance work where debate is rarely needed and the cost of delay creates downstream friction, such as:

1. Operational / infrastructure changes — e.g. Drone/CI pipeline tweaks, Docker images, build tooling, internal-only regression tests, documentation, general repo hygiene.
2. Routine dependency / core library updates — bumping packages versions, security patches, and similar updates where the intent is clear, the impact is limited, and there is little-to-no substantive debate to have.
3. Non-breaking bug fixes and small enhancements — fixes that restore expected behavior, or additive improvements that do not change existing contracts. These also sit in the same queue as items that genuinely need community discussion.

What's happened is that low-risk work shares the limited attention cycles of more significant issues, that can delay merges for months. I think we can address this by a clearer split with what actually needs review.

Proposal

• Tier A (streamlined): Core committers may make non-breaking bug fixes, small additive features, CI/ops, dependency bumps, docs. Still a PR, but with looser controls and/or some sort of timeout on the order of days and not weeks.
• Tier B (status quo): behavioral, breaking, strategic, or spec-aligned changes, with stricter review to merge as it is today. Default process for one-off contributions.

[preston]

Also note that with CQL Tests Runner being hosted at https://cql-tests-runner.quality.hl7.org/ , it is especially important that anything that may affect environment security be easily rolled into a patch release.