[Feature] State the bus factor and the review situation honestly (QA.06/QA.07) #554

New issue

Closed

opened 2026-07-22 13:44:19 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 13:44:19 +00:00

Owner

Two rows of the light-weight attestation (#549) cannot be ticked, and both are about people rather than code:

QA.06 — projects should have more than one active contributor.
QA.07 — projects with more than one active contributor should require that every change is reviewed by at least one human non-author.

AUTHORS.md lists one person under Contributors. Changes are merged by their author. There is no CI runner on the forge, so the checks that do exist are not enforced by anything outside the maintainer's machine. That is a bus factor of one, and it is the single largest risk in the project — larger than any finding a scanner has produced.

Why this gets written down instead of quietly skipped. The whole point of a voluntary attestation is that a reader can trust it. A checklist that hides its weakest row teaches the reader to distrust the rows that are true. And QA.07 is conditional — it only bites once there is a second contributor — so the honest entry is not a failure, it is a description.

What is actually in place, and deserves to be said next to the two blanks:

make check gates analysis, conventions, the full suite, a coverage floor, method length, file size and dead code, and it must be green before a merge. A machine reviews what a machine can review.
The ratchets only move one way; a baseline that is allowed to grow is not a baseline.
make sast, make check-secrets and mutation testing exist as separate gates.
Work lands through pull requests with a written description, so the change history is reviewable after the fact even when it was not reviewed before it.

None of that is four eyes. It is worth stating precisely because it is not the same thing.

Deliverable

A short, plain paragraph — in CONTRIBUTING.md and referenced from COMPLIANCE.md — saying: one active maintainer, self-merge, the automated gate is what stands in for peer review, and here is what would change if a second maintainer appears.
Say what a contributor can expect: their pull request is reviewed by a non-author, because the maintainer is not its author. The gap is one-directional and that is worth naming.
Note the CI-runner situation rather than leaving it implied. A reader who sees pull requests with permanently pending checks will otherwise draw a worse conclusion than the truth.

Deliberately not in scope: recruiting a second maintainer. That is not a ticket.

Two rows of the light-weight attestation (#549) cannot be ticked, and both are about people rather than code: - **QA.06** — projects should have more than one active contributor. - **QA.07** — projects with more than one active contributor should require that every change is reviewed by at least one human non-author. `AUTHORS.md` lists one person under Contributors. Changes are merged by their author. There is no CI runner on the forge, so the checks that do exist are not enforced by anything outside the maintainer's machine. That is a bus factor of one, and it is the single largest risk in the project — larger than any finding a scanner has produced. **Why this gets written down instead of quietly skipped.** The whole point of a voluntary attestation is that a reader can trust it. A checklist that hides its weakest row teaches the reader to distrust the rows that *are* true. And QA.07 is conditional — it only bites once there is a second contributor — so the honest entry is not a failure, it is a description. **What is actually in place**, and deserves to be said next to the two blanks: - `make check` gates analysis, conventions, the full suite, a coverage floor, method length, file size and dead code, and it must be green before a merge. A machine reviews what a machine can review. - The ratchets only move one way; a baseline that is allowed to grow is not a baseline. - `make sast`, `make check-secrets` and mutation testing exist as separate gates. - Work lands through pull requests with a written description, so the change history is reviewable after the fact even when it was not reviewed before it. None of that is four eyes. It is worth stating precisely because it is *not* the same thing. **Deliverable** - A short, plain paragraph — in `CONTRIBUTING.md` and referenced from `COMPLIANCE.md` — saying: one active maintainer, self-merge, the automated gate is what stands in for peer review, and here is what would change if a second maintainer appears. - Say what a contributor can expect: their pull request *is* reviewed by a non-author, because the maintainer is not its author. The gap is one-directional and that is worth naming. - Note the CI-runner situation rather than leaving it implied. A reader who sees pull requests with permanently pending checks will otherwise draw a worse conclusion than the truth. **Deliberately not in scope:** recruiting a second maintainer. That is not a ticket.

brenno added the

docs

triage

enhancement

labels

2026-07-22 13:44:19 +00:00

brenno referenced this issue from a commit

2026-07-22 15:40:44 +00:00

docs(contributing): noem de busfactor van één, en wat er wél voor staat

brenno referenced this issue from a pull request that will close it,

2026-07-22 15:40:45 +00:00

docs: de CRA-attestatietros — rentmeester, EOL, feed, geheugenveiligheid, busfactor en COMPLIANCE.md #566