A measurement study of named, held, and exercised approval authority in kubernetes/kubernetes (names contributors; feedback welcomed before it's posted)

[Jordan Allen]

Hi all,

I’m one of three authors of a short measurement paper about approval authority in Kubernetes that we intend to publish on arXiv. It's a pretty small contribution, but we think it's possibly interesting enough to share even though it's largely done by AI. Also, it names eleven current and former approvers alongside, so I’d rather you heard from us first and had a chance to tell us anything we got wrong.

We looked at stated, held, and exercised authority, from public sources:

1. OWNERS coverage per person. By traversing all OWNERS files in kubernetes/kubernetes at v1.30.0 with Prow’s inheritance and `no_parent_owners` logic, seven people can approve in more than half of the 501 owner-ruled directories; liggitt can in 98.6%. 148 people have an approval right in at least one directory.

2. Eligibility versus actual approvals per merged PR. For the 1418 merged k/k PRs in our window (2023-10 to 2024-05) with a parsed `/approve`, we reconstructed the OWNERS state at the time of merge and calculated the set of people who could have approved the PR individually. liggitt was eligible for 98.4% of them and approved 20%; it took four approvals to cover half the merged PRs in this set; 42 had exactly one possible sole approver, and three had none (scheduler code changed together with instrumentation testdata).

3. sigs.yaml versus approval stream. In 11 of 19 SIGs the busiest approver holds no chair or tech-lead seat in that SIG. Of the nine people who top a SIG's stream, eight held a seat somewhere in the project during the window, and the ninth was made a tech lead in another SIG right after it.

The contributor guide already says a handful of people can approve across most of the repo, so it's certainly not framed as good or bad; we're putting numbers on it. We name people explicitly because its all public data and makes the claims checkable: the full pipeline, data, and adversarial-review record are at doi.org/10.5281/zenodo.22115990. If a number about you is wrong, let us know so we can correct it.

A few items where we’d appreciate specific feedback from people who know the machinery better than the casual reader:

- OWNERS semantics. We implemented inheritance, `no_parent_owners`, `filters`, and aliases, excluded emeritus approvers, and cross-checked our per-file logic against Prow's `repoowners` and `approve` plugin source; they agree on every PR in our data. If there's a case we've modeled wrong, we'd rather know.
- Approval channels. We parse `/approve` from issue comments, review bodies, and inline review comments, and report GitHub "Approve" reviews with no command text separately, since Prow honors them only from OWNERS-eligible reviewers. If Prow accepts approvals through a channel we've missed, that needs fixing before this goes up.
- Anything a named person wants said differently. The paper reports seat status only per public register and time window, and says nothing about anyone's qualifications. If a line reads otherwise to you, tell me and I'll fix it.

The paper also discloses that the analysis code and first drafts were written by AI; the framing, review decisions, and final text are ours, and every figure was checked against the public data.

Thanks,
Jordan Myska Allen (on behalf of Jordan, Brian Raszap, and Emin Göbütoğlu)