Who can approve Kubernetes

Kubernetes writes down who holds authority twice, on purpose. A public file called sigs.yaml names the chairs and tech leads of every department (the SIGs). A separate system of OWNERS files grants the right to approve changes, path by path. These two records name different people, and that separation is the documented design of the project, not a secret.

We measured both records against a third: eight months of the public approval stream, the /approve comments that actually gate merges.

Over those eight months, 390 people approved at least one pull request. The busiest approver touched fewer than one in ten of the approved pull requests, and covering half of them takes between 19 and 20 people. The permission files are much tighter than that: at release v1.30.0, seven people each held the approval right over more than half of the 501 directories carrying an ownership rule, and one of them over 98.6 percent of them.

The right to approve is held tightly. The work of approving is not. Every number in this article reproduces from public data, and we show you how.

What was already known

We want to concede the folk version up front, because the Kubernetes project itself has said it plainly. The contributor guide has stated since April 2023 that "there are a handful of people who can approve changes across large portions of the repository." CNCF's DevStats counts per-person approvals from the same public archive we use. And the project audited its own root-approver concentration in 2022 (issue #112867, filed by dims, one of the people this article counts). What we add is the measurement: the per-person share of the repository each approver can reach, the spread of one person's approvals across departments, and the gap between authority held and authority used.

Who could approve: the keys are held by very few

OWNERS files inherit downward: an approver listed at a directory covers everything under it unless a deeper file cuts inheritance. We parsed every OWNERS file in kubernetes/kubernetes at release v1.30.0 (commit 7c48c2bd, April 2024, inside our window), honored the inheritance and cut rules, excluded vendored code and emeritus entries, and computed each person's reach over the 501 directories that name an owner.

Before the table, the objection it invites. A root OWNERS file exists, so of course somebody can approve a lot; the interesting quantity is not whether a person can approve something but what share they can approve. And in this repository the shares do not come from the root file. Root approval is deliberately non-recursive: 45 directories cut parent inheritance, and fifteen of those are top level, including every directory holding the bulk of the code. pkg/OWNERS says so in a comment, # make root approval non-recursive. The root file grants approval to nine people, and only three of them appear in the table below; three others in that table are listed at root as emeritus and hold no current root authority at all. The coverage arrives instead by explicit relisting: the same six people are named, as plain handles rather than through an alias, in the approvers list of pkg, cmd, staging, plugin and test, each of which has six or seven approvers of its own. Kubernetes cut root approval off from the code, and the same people appear immediately below each cut. We are describing what the files do, not guessing why.

Seven people clear 50 percent. 148 people hold an approver bit anywhere in the repository. The picture is stable: at v1.29.0 no figure moves more than 1.7 points and the top seven are the same people in the same order.

Two guards on reading this table. Approval is one of two required signals: a change also needs a /lgtm, and this table counts the approval right only. And directory coverage is an unweighted count of the permission surface, not of code volume, PR traffic, or risk.

Who did approve: the work is spread much wider

Over October 2023 through May 2024, 390 people approved at least one pull request in the corpus. The busiest, dims, covered 9.88 percent of all approved PRs. The top twenty approvers together account for just under half of all approval acts. Covering half of the approved PRs takes between 19 and 20 people: no set of 18 can do it, because the 18 largest individual shares do not add up to half, and a set of 20 does. The Gini coefficient over approvers is 0.74, concentrated as review work always is. Review concentration in Kubernetes has been measured with a Gini coefficient before, by Mirsaeedi and Rigby, over reviewer workload rather than approvals.

Seven people hold the approval right over half the directories; nineteen or twenty are needed to cover half the approved work, and hundreds carry the rest. These are two different measures over two different things, a permission graph at one commit and a stream of pull requests over eight months, so we are not ranking one against the other and a directory count is not a risk score. What the pair shows is that reading either record alone will mislead you about the other.

The leadership roster against the approval stream

The original version of this article compared the sigs.yaml roster to the approval stream and framed the gap as hidden authority. Readers who know the project's governance would have correctly objected, and our own follow-up checks agreed: the gap is a design property, since merge rights live in OWNERS, not in the leadership file. The corrected comparison is still informative. It shows how far apart the two records sit, and which roles actually show up in merge traffic.

For each SIG we rank approvers by distinct pull requests carrying that SIG's label on which they left a surviving /approve. The roster column uses the roster as it stood during the window, including seats the current file no longer shows. Three SIGs, chosen as large, central, and differently shaped:

SIG Node

In-window roster: chairs SergeyKanzhelev and mrunalp, tech leads dchen1107, derekwaynecarr, and mrunalp.

One named leader (dchen1107) appears. The stream is led by dims and liggitt, who hold no Node seat but do hold documented authority here: dims holds repo-wide approval rights through root OWNERS aliases and is a named approver of the cri-api Node subproject, and liggitt holds repo-wide rights the same way. Counting /lgtm as well changes this table more than any other: bart0sh (88 pooled, zero approves), kannon92, and pacoxu enter on review volume, and all three are reviewers, not approvers, in the Node OWNERS aliases. pacoxu also chaired the project's Steering Committee during the window, a seat our original roster never parsed.

SIG API Machinery

In-window roster: chairs deads2k and fedebongio, tech leads deads2k, jpbetz, sttts.

The roster holds up well here: jpbetz, deads2k, and sttts all rank. The busiest approver by a wide margin is liggitt, who holds no API Machinery seat but is named directly in the apimachinery and apiserver OWNERS files, and chaired WG LTS during the window. Chair fedebongio does not appear, which reads as a role split rather than a gap: chairing is coordination work that leaves no trace in this stream.

SIG Storage

In-window roster: chairs saad-ali and xing-yang, tech leads jsafrane and msau42.

Three of four named leaders appear. Chair saad-ali is absent. Storage is also the one SIG where the counting unit changes who is busiest: by distinct PRs pooled with lgtm, jsafrane leads; by approve-only or by raw act count, dims does. We state both rather than picking the flattering one.

Three results

1. The busiest approver usually holds no seat in that SIG, but always holds one somewhere. In 12 of the 19 SIGs with enough labeled traffic, the busiest approver held no chair or tech lead seat in that SIG during the window (10 of 19 counting lgtm). Count Steering Committee and working group chairs and it drops to 8. Count any formal leadership anywhere in the project and it reaches zero: all nine people who top a SIG's approval stream were named leaders somewhere. Authority and its paperwork sit in different units, by design. Nothing here is hidden.
2. A few people approve across most of the project, with a caveat we quantified. dims ranks in the top three approvers of 12 to 18 of the 19 SIGs, and liggitt of 6 to 14, depending on how you credit a PR that carries several SIG labels. Their PRs carry 2.2 and 3.0 labels each against a corpus average of 1.6, so single-counting shrinks their spread. Under every credit rule tested, both remain the only two people in the top ten of all three SIGs above, and docs is the only SIG where neither is top-three.
3. The roster is real signal. 41 percent of in-window leadership seats rank in their own SIG's top ten approvers, and 73 percent appear somewhere in its approval ranking (44 and 86 percent counting lgtm). Tech leads show up; several chairs do not. The file is incomplete about merge authority because it was never meant to record it.

Methods

• Window. 2023-10-01 to 2024-06-01, set by where the public archive is dense, not by design. The archive we query begins 2023-01, so no claim in this article extends past that horizon.
• Approve vs lgtm. They are different powers: OWNERS-gated approval vs a review signal any project member can give. The original version pooled them. This version leads with approve-only everywhere and reports pooled as a variant, and says which one every number uses.
• Roster versioning. The original compared eight months of activity to a roster snapshot taken two years later; 56 of its 116 rows were wrong for the window, and Steering Committee and working group seats were never parsed. This version uses the union of all 114 in-window revisions of sigs.yaml on the main branch, plus Steering Committee and working group chairs.
• SIG attribution. By the sig/* labels the project's automation applies. 38.1 percent of raw command rows carry one. Labeling is effectively a per-repo switch: the 13 core repositories are about 95 percent labeled and the satellite repositories about zero, so every per-SIG claim here is scoped to the core repositories. A PR counts once per SIG label it carries; the fan-out ranges above quantify what that does.
• SIG gate. SIGs with at least 50 labeled PRs in the window: 19 of 24. We cannot reconstruct whether that threshold predates the first results, so we publish the 24-SIG variant too. Including the five thin SIGs strengthens the off-roster share and weakens the spread and recall numbers, so the gate was not flattering us in one direction.
• Bots. Excluded on both sides, as approvers and as PR authors. No non-human appears in any table we report.
• Retractions. A trailing /approve cancel or /lgtm cancel drops the act. 169 cancel rows exist, 0.65 percent of the corpus, and they move no ranking.
• Identity. One GitHub login, one person, no merging. A scan of all 727 approver logins found two plausible duplicate pairs; merging them changes nothing.
• Ties. Every ranking breaks ties by count, then login. The original Storage table printed a tie row the query resolves the other way today; the query below is deterministic so yours will match ours.
• AI assistance. Analysis and drafting were AI-assisted. Every number was checked against public data or a pinned commit, and the queries and parser are published below so you do not have to take our word for any of it.

Sensitivity checks

• A second attribution channel (mapping repositories to SIGs through subproject OWNERS files, no labels involved) confirms the off-roster direction: 14 of 19. It cannot test the seven SIGs whose traffic lives inside kubernetes/kubernetes, so it does not cover those.
• The ranking is stable across every window the archive supports, including one that shares no data with ours, and dims and liggitt hold identical ranks in all three SIGs when the whole 16.6-month dense span is used instead of our eight months. The roster side has no such test, so we make no claim that the gap itself is stable over time.
• The top-ten cutoff sits on a plateau: seat recall moves smoothly from 20 percent at top-3 to 71 percent at top-50, with no cliff at ten.
• Weakened by our own checks and corrected above: the original "top three in 18 of 19" is now a range with fan-out stated; the original off-roster count of 13 of 19 is 12 of 19 on the corrected roster and approve-only measure, and 0 of 19 on the widest reading of "holds a formal position"; and the original claim that the named individuals held no formal positions in these SIGs was wrong and has been corrected on this page since August 4.

Check our work

The approval stream is public in the GitHub event archive, queryable for free at play.clickhouse.com. This returns the SIG Node table above, exactly:

SELECT
  actor_login AS gatekeeper,
  uniqExact((repo_name, number)) AS prs_approved
FROM github_events
WHERE event_type = 'IssueCommentEvent'
  AND (repo_name LIKE 'kubernetes/%' OR repo_name LIKE 'kubernetes-sigs/%')
  AND created_at >= '2023-10-01' AND created_at < '2024-06-01'
  AND actor_login NOT LIKE '%[bot]%'
  AND actor_login NOT LIKE '%-bot'
  AND actor_login NOT LIKE '%-robot'
  AND has(labels, 'sig/node')
  AND match(body, '(?m)^/approve(\\s|$)')
  AND NOT match(body, '(?m)^/approve\\s+cancel')
GROUP BY gatekeeper
ORDER BY prs_approved DESC, gatekeeper ASC
LIMIT 10

Swap the label for any SIG, or restore the lgtm clause for the pooled variant. The leadership roster is one public file in kubernetes/community. For the coverage table, our parser is published at github.com/jaamm/owners-coverage. It clones the repository at a ref you name and prints the table, and its README carries the output we got so you can tell a real disagreement from a flag difference:

pip install pyyaml
python3 owners_coverage.py --clone v1.30.0

Corpus totals, for the record: 138 repositories with at least three attributable approval acts (171 appear in the raw stream), 4,570 people who approved a PR or authored an approved one, and 17,797 surviving approval acts after joining each command to its PR author, dropping self-approvals, and keeping each person's last command per PR.

What our engine adds

Everything above is counting on public records. None of it needs our technology, and no claim in this article rests on it. What the UpTrust engine adds, shown here as product rather than evidence: it turns the same records into personal, explainable trust rankings, finds community structure (run over this corpus it recovers eight groups that track real Kubernetes structure, from core maintainers to SIG Docs to Kubespray, without being told SIGs exist), and lets you read the graph from any member's point of view. For an organization, that means seeing your own two records, the stated one and the enacted one, on data you already have: code review, document comments, ticket handoffs. Aggregate views first, governance controls from day one. If you want the second reading of your organization, talk to us.

FAQ

Is this just the difference between sigs.yaml and OWNERS, which Kubernetes separates on purpose?

Yes, and the article now says so in the second sentence; the original framing implied otherwise and was wrong. The contribution is the measurement: how concentrated the OWNERS side is (seven people over half its directories), how far the two records sit apart (12 of 19 busiest approvers hold no seat in that SIG), and how held authority compares to used authority.

Only 38 percent of approval acts carry a SIG label. Does that invalidate the rankings?

It scopes them. Labeling is a per-repo switch, not a random sample: core repositories are about 95 percent labeled with near-uniform coverage across approvers, satellites near zero. So the SIG tables are close to a census of the core repositories and say nothing about satellite review, where the corpus's single busiest approver works almost entirely.

Approvals are not authority. What about people who set direction through KEPs and design review?

Fully conceded. This method reads design authority, escalation, and roadmap work as absence, which means some share of what we call off-roster is an artifact of measuring only the merge gate. The error runs one way: it understates the authority of exactly the coordination roles the roster names.

Why eight months?

That is where the public archive is dense; it begins 2023-01 and thins after 2024-05. The ranking is stable in every window the data supports, including one with zero overlap with ours, but we make no claim beyond the archive's horizon.

Why top ten?

A reporting choice on a plateau, not a threshold that manufactures the result: recall rises smoothly from 20 percent at top-3 to 71 percent at top-50 with no cliff at ten.

Why were 5 of 24 SIGs excluded?

They fell under a floor of 50 labeled PRs in the window (the largest excluded SIG had 46). We cannot reconstruct whether the floor predates the first results, so the 24-SIG numbers are published alongside, and they cut both ways: off-roster share goes up, spread and recall go down.

Were bots filtered?

Yes, as approvers and as PR authors, and two independent audits found no non-human in any table.

Were /approve and /lgtm treated the same?

In the original, yes, which was a mistake this revision corrects: they are different powers. Every headline number here is approve-only, with pooled shown as a variant and labeled wherever it appears.

Is it fair to name individual contributors?

The names are public, deliberate governance acts performed under a public protocol, reported as aggregate counts, reproducible from the query above, and scoped to one project. These are public merge-gate acts, and the volume is the thing being measured. We publish no private edges, no cross-domain profiles, and no scored person pages; that last one is a hard line for what UpTrust builds anywhere. The names are also load-bearing: an anonymous claim cannot be checked, and a named one can be falsified in ten minutes. One asymmetry we take seriously: a claim that someone holds no formal position is far more damaging, and far easier to get wrong, than a count of what they did, so we state seat status only per register and per window.

How do I reproduce this?

Paste the query above into play.clickhouse.com (no account needed) for any SIG table. Fetch sigs.yaml from kubernetes/community for the roster. Run our published parser for the coverage table. Every number in this article traces to one of those three, and if your coverage figures disagree with ours we would rather hear it than not: the repository takes issues.

Was this written by an AI?

Yes, AI-assisted, both the analysis and much of the drafting. The queries, the parser and the data are public, so you can check any number here yourself.

Everyone knows org charts are fiction. What is new here?

Folk wisdom is equally compatible with a 5 percent gap and a 70 percent one, so the contribution is measurement rather than sentiment. Concentration in Kubernetes review, ownership per module per person, and the stated-versus-revealed comparison have all been published before, and the prior work section names who did each. What we have not found published is the permission surface reduced to a per-person share, computed from the approval right rather than review participation, set against how much of it gets used.

Is this an ad for UpTrust?

It is a company blog post, so yes. The defense is that every claim reproduces from public data with the published queries, and none of it touches anything of ours.

Prior work

Comparing a maintainer file to the record of who actually reviews code is an established genre, and measuring concentration in Kubernetes is not new. These are the works closest to ours, including the ones that overlap it most.

Kubernetes' own records and dashboards.

• Kubernetes contributor guide, pull requests states the qualitative version of our headline: "there are a handful of people who can approve changes across large portions of the repository." Added April 2023, before our window opens.
• Kubernetes contributor guide, OWNERS is the specification we implemented: approver inheritance, filters, and no_parent_owners.
• CNCF DevStats computes per-person approval counts from the same public archive we query, in hist_approvers.sql, served on the developer activity dashboard. Its groups are groups of repositories, so a SIG-named group bundles that SIG's separate repositories and cannot resolve which SIG a change inside kubernetes/kubernetes belongs to. That is where our per-SIG view sits, and it does not aggregate one person across groups.
• The CNCF Kubernetes annual report for 2021 published per-group reviewer scarcity, including groups with ten or fewer unique reviewers.
• The project audited its own root approver concentration in issue #112867 (2022), filed by dims, and restructured the top-level files in PR #112952.

The same comparison, done elsewhere.

• Jonathan Corbet, "MAINTAINERS truth and fiction" (LWN, 2021), compares the Linux MAINTAINERS file against actual review trailers across thousands of subsystems. Daniel Vetter's maintainer statistics (2018) does per-subsystem reviewer counts. The idea is theirs; what differs here is the project and the signal. Both note that git trailers under-record review, because a maintainer whose sign-off is already required often skips a separate review trailer. A Prow /approve is an explicit, machine required act, so it does not carry that confound.
• Lulla, Kula, and Treude, "Automated Code Review Assignments: An Alternative Perspective of Code Ownership on GitHub" (arXiv:2512.05551) runs the stated-versus-revealed comparison at scale on CODEOWNERS files across 222 repositories and 844,492 pull requests, and reports that 79 percent of declared individual code owners, as opposed to team owners, were not among their repository's top hundred committers. CODEOWNERS is the direct analogue of Kubernetes OWNERS: a path-to-person authority mapping. Its unit is the pull request and it does not measure concentration over that mapping. Kubernetes does not appear in their sample; since Kubernetes grants approval through Prow OWNERS files rather than GitHub CODEOWNERS, we read it as falling outside their selection criteria, but that inference is ours rather than something they state.
• Thongtanunam, McIntosh, Hassan, and Iida, "Revisiting Code Ownership and its Relationship with Software Quality in the Scope of Modern Code Review" (ICSE 2016) builds review-based ownership per module per developer, at directory granularity, and finds that most of a module's contributors participate only through review. This is the closest existing work to our per-directory, per-person view. It credits review participation, measured from review comments rather than from approval votes, and its projects are Qt and OpenStack.
• Mirsaeedi and Rigby, "Mitigating Turnover with Code Review Recommendation" (ICSE 2020) measures reviewer workload concentration with a Gini coefficient, on a dataset that includes Kubernetes, and reports that the top fifth of reviewers perform 75 to 84 percent of reviews. Concentration in Kubernetes review has therefore already been measured this way. Their reviewer events fold approvals together with comments and change requests, and the result is one figure per project rather than a per-directory breakdown, so their numbers and ours are not comparable.
• Aufiero, Vaccargiu, Bartolucci, Caccioli, and Destefanis, "Coordination at Scale in Large Distributed Development: The Case of Kubernetes" (MSR 2026), open access, builds a co-commenter network over 46,768 Kubernetes issues and 339,332 comments across eleven years. It reports a Gini coefficient of 0.69 over contributor connections, with 7.74 percent of contributors holding half of them, and finds 602 emergent modules that align with the project's own labels, SIG labels among them. Their closing suggestion is close to ours in spirit: that comparing detected modules against formal labels tests whether intended structure matches actual practice. The difference is the signal. Their corpus is issues and comments, with no pull requests, reviews or approval commands in it, and they name the consequence themselves in their threats to validity: focusing on issues rather than pull requests "may underrepresent review activity". That is the gap this article measures.
• Vaccargiu, Aufiero, Bartolucci, de Souza Santos, Tonelli, and Destefanis, "Efficiency for Experts, Visibility for Newcomers" (EASE 2026), from the same group, does work on pull requests: it compares area/ labels against the files a pull request actually changes, across 18,020 Kubernetes pull requests. The subject is label accuracy rather than authority, and approval rights are not part of it.

So the narrow version of what is new here. Not concentration in Kubernetes review, which Mirsaeedi and Rigby measured. Not ownership per module per person, which Thongtanunam and colleagues built. Not the stated-versus-revealed comparison, which the CODEOWNERS study did at scale and which Aufiero and colleagues propose as a diagnostic. What we have not found published is the permission surface reduced to a per-person share, computed from the approval right rather than review participation, set beside how much of it gets used. If that is taken too, tell us and we will say so here.

On bus factor, which is the framing we are not using. Avelino, Passos, Hora, and Valente's truck-factor method (arXiv:1604.06766) estimates how many people a project cannot afford to lose, from file authorship in commit history, and reports that 65 percent of the 133 projects it studied have a truck factor of two or less. Kubernetes is not among them, and as far as we can tell it is not in any of the canonical truck-factor datasets. That measure and ours also answer different questions: it counts who wrote the code, from commits, and reports one number per project with no named people. Ours counts who is permitted to approve changes, per directory. Cury and Avelino's Knowledge Islands (SBES 2024) comes nearest to our shape in that family, computing a truck factor for every folder and file, still from commit authorship. By the authorship measure Kubernetes looks robust, which is one more reason we report a permission surface and how much of it gets used rather than a risk score.

Corrections

Corrected August 4, 2026: an earlier version of this article said dims and liggitt held no formal positions in the SIGs where they lead the approval stream. That was false. Both hold approval rights through root OWNERS aliases, dims is a named approver of a SIG Node subproject, and liggitt is named directly in several API Machinery OWNERS files. Two demo screenshots centered on a named contributor were removed at the same time. Headline figures no longer pool /approve with /lgtm, and the leadership roster is now read per window rather than from a single later snapshot. Published July 13, 2026 as "The org chart vs. the merge log", which is why the address reads that way.