Strengthen governance criteria for incubation and graduation

[angellk]

Summary

Based on governance review findings across 71 graduated and incubating projects, this PR proposes strengthening the governance criteria in the incubation and graduation application templates.

Incubation changes (Suggested to Required)

• I-1: Clear and discoverable governance documentation
• I-2: Governance documents vendor neutrality
• I-3: Maintainer lifecycle process documented and demonstrated
• I-4: Contributor ladder with multiple roles
• I-5: New: Maintainer affiliations updated within 30 days of employment changes

Graduation changes

• G-1: Org diversity verified through LFX Insights data, not just MAINTAINERS file
• G-2: New Required: Org-balance mechanism for governance decisions (org-balanced voting, steering committee with org caps, or equivalent)
• G-3: Contributor ladder moved to Required, must demonstrably produce external maintainers
• G-4: New Suggested: Annual governance health check on maintainer org composition

Rationale

• Documentation without structural mechanisms often fails to prevent concentration. Multiple projects with well-written governance docs experienced maintainer concentration because their governance lacked org-balance voting or steering committee caps.
• 20% of graduated projects now show post-graduation governance concentration, all lacking org-balance mechanisms at incubation.
• 70 of 71 evaluated projects already have governance docs, making I-1 effectively codifying existing practice.
• Projects with intermediate roles (contributor ladders) produce more diverse maintainer pools.
• Stale maintainer affiliations make diversity assessment during DD impossible.

Companion PR

• cncf/project-template governance template updates (separate PR) adds the Org-Balanced Voting module referenced in G-2, plus template updates for maintainer lifecycle, emeritus process, and transition guidance.

Transition

Projects currently in the DD pipeline would not be held to new Required items retroactively. New criteria apply to applications submitted after this PR merges.

[mesutoezdil]

you would like to add an LFX Insights verification requirement to I-5 too, since G-1 has one but I-5 doesn't, it just says "documented"?

for G-1, would it be worth having the LFX Insights check look at contribution volume (commits/reviews) by org, not just maintainer headcount? A project could satisfy "2+ orgs" with a token maintainer from the second org while nearly all the work still comes from one.

and last one: since the rationale here comes from reviewing 71 existing projects and found ~20% with post-graduation concentration, could G-4 (or something like it) also apply to already-graduated projects, not just future applicants?

[brandtkeller]

Adding some thoughts - none I would consider blocking.

[brandtkeller]

For reviewers - the proposed Org-Balanced Voting doc is in a PR.

[angellk]

Addressed review feedback. See details in individual comment replies.

[angellk]

Thanks for the thoughtful questions @mesutoezdil.

LFX Insights at incubation (I-5): The affiliation requirement at incubation is about having a current maintainer list and a policy for keeping it current. At this stage, many projects are still single-org, so LFX org dependency data would just confirm what everyone already knows. LFX verification becomes more meaningful at graduation (G-1) where the claim is multi-org maintainership. That said, if LFX data is available and useful at incubation, nothing prevents DD reviewers from referencing it.

Contribution volume vs. maintainer headcount (G-1): Yes, this is exactly the gap the updated G-1 language is trying to address. The rewording (per @brandtkeller's feedback, pushed in ca29dd8) now says: "Use LFX Insights where available to corroborate organizational contribution patterns; explain any unavailable or conflicting data." Contribution patterns includes commit and review volume, not just headcount. A token maintainer from a second org with no meaningful contribution activity would not satisfy the intent, and DD reviewers can flag this using the LFX data.

G-4 for already-graduated projects: Absolutely. The G-4 item in this PR is scoped to the application template (what projects commit to at graduation), but a separate proposal for post-graduation monitoring is in progress. That proposal covers all currently graduated projects through automated monitoring and biennial refresh, not just future applicants. It connects to #1496 and the existing governance remediation process.

[mesutoezdil]

Thanks for the thoughtful questions @mesutoezdil.

LFX Insights at incubation (I-5): The affiliation requirement at incubation is about having a current maintainer list and a policy for keeping it current. At this stage, many projects are still single-org, so LFX org dependency data would just confirm what everyone already knows. LFX verification becomes more meaningful at graduation (G-1) where the claim is multi-org maintainership. That said, if LFX data is available and useful at incubation, nothing prevents DD reviewers from referencing it.

Contribution volume vs. maintainer headcount (G-1): Yes, this is exactly the gap the updated G-1 language is trying to address. The rewording (per @brandtkeller's feedback, pushed in ca29dd8) now says: "Use LFX Insights where available to corroborate organizational contribution patterns; explain any unavailable or conflicting data." Contribution patterns includes commit and review volume, not just headcount. A token maintainer from a second org with no meaningful contribution activity would not satisfy the intent, and DD reviewers can flag this using the LFX data.

G-4 for already-graduated projects: Absolutely. The G-4 item in this PR is scoped to the application template (what projects commit to at graduation), but a separate proposal for post-graduation monitoring is in progress. That proposal covers all currently graduated projects through automated monitoring and biennial refresh, not just future applicants. It connects to #1496 and the existing governance remediation process.

1 more thing: "or equivalent structural protection" in g-2 has no definition. reviewers could read this very differently. maybe add a minimum, like no org over 50% voting/veto power, for consistency (?)

[angellk]

Good catch @mesutoezdil. The "equivalent structural protection" language is intentionally flexible - CNCF projects use a range of governance structures, and prescribing a single mechanism would not work across the ecosystem:

• some projects use supermajority thresholds,
• some use rotating chair roles with org limits,
• some use consensus with explicit org-balance tiebreakers.

That said, if this comes up repeatedly during DD reviews as hard to evaluate, we should revisit and add more specific guidance to the DD TOC Guide.

[kevin-wangzefeng]

LGTM, thanks