Governance template updates: org diversity, lifecycle, and voting module

GOVERNANCE-elections.md

@@ -144,14 +144,22 @@ There are two ways to raise issues to the steering committee for decision:
 
 ## Composition
 
-The steering committee has [TODO: Number] seats. These seats are
+The steering committee has [TODO: Number, recommend minimum 5] seats. These seats are
 open to any project contributor. See
 [candidate eligibility](#candidate-eligibility) for a definition.
 
-Steering Committee members serve for [TODO: Service Period] terms, staggered in order to
+Steering Committee members serve for [TODO: Service Period, recommend 2-year] terms, staggered in order to
 preserve continuity. Every year either [TODO:Number] or [TODO:Remainder]
 contributor seats are elected.
 
+### Term Renewal
+
+Steering Committee terms must be actively renewed through elections. If an election is not held within 30 days of scheduled term expiration, all expiring seats are considered vacant and a special election must be called. Lapsed governance - where terms expire without renewal - undermines the accountability that elections are designed to provide.
+
+### Governance and Code Alignment
+
+The Steering Committee should periodically assess whether governance diversity is reflected in the project's contributor and maintainer composition. A diverse steering committee paired with a single-organization maintainer pool indicates that governance protections are not yet translating into contributor pipeline diversity. The committee should track this and take action to grow the contributor base when divergence is observed.
+
 ## Election Procedure
 
 ### Timeline

GOVERNANCE-maintainer.md

@@ -175,6 +175,17 @@ existing maintainers.
 <!-- Example: "No single organization's employees may cast more than 1/3 of   -->
 <!-- the total votes on any decision." -->
 
+## When to Evolve This Governance
+
+The Maintainer Council model works well for focused projects with a small, cohesive group of contributors. As the project grows, watch for these signals that a governance transition may be needed:
+
+* **Decisions stall.** When the maintainer group is too large for lazy consensus to work, or when decisions affect subgroups differently, a delegation structure (working groups, SIGs) helps.
+* **New contributors cannot find a path in.** If the only path to influence is "become a maintainer," the project needs intermediate roles (reviewer, approver). Projects with intermediate roles produce more diverse maintainer pools because they give external contributors a visible progression path.
+* **A single organization dominates.** When one company holds a majority of maintainer seats, consider adding [org-balanced voting](governance/ORG-BALANCED-VOTING.md), company representation caps, or transitioning to an [elected steering committee](GOVERNANCE-elections.md).
+* **Subprojects diverge.** When parts of the project develop their own contributor communities or release cadences, consider [federated subproject governance](GOVERNANCE-subprojects.md).
+
+These transitions are a sign of project growth, not governance failure.
+
 ## Modifying this Charter
 
 Changes to this Governance and its supporting documents may be approved by 

GOVERNANCE-org-balanced-voting.md

@@ -0,0 +1,37 @@
+# Org-Balanced Voting
+
+This module can be adopted by any CNCF project governance model to prevent organizational concentration of governance decisions. It is designed to be added to an existing governance document, not used standalone.
+
+<!-- template begins here -->
+
+## Org-Balanced Voting for [TODO: PROJECTNAME]
+
+To ensure that governance decisions reflect the interests of the broader community and not just the largest contributing organization, [TODO: PROJECTNAME] uses org-balanced voting for the following decision types:
+
+- [TODO: List applicable decision types, e.g. governance changes, steering elections, strategic direction, roadmap priorities]
+
+### How It Works
+
+Each organization (employer) gets [TODO: one / up to two] vote(s) on org-balanced decisions, regardless of how many maintainers that organization employs. Independent contributors each receive one vote.
+
+**Determining organization:** A maintainer's organization is their current employer as listed in [MAINTAINERS.md](./MAINTAINERS.md). Independent contractors or self-employed contributors are each treated as their own organization. If a maintainer's affiliation is unclear, the [TODO: Maintainer Council / Steering Committee] will determine it.
+
+### Examples
+
+**Example 1 - Simple majority with org balance:**
+The project has 6 maintainers: 3 from Company A, 2 from Company B, and 1 independent. A governance change requires a simple majority of organizational votes. There are 3 organizational votes possible (Company A, Company B, Independent). Company A's 3 maintainers collectively cast 1 vote. The change passes with 2 of 3 organizational votes.
+
+**Example 2 - Steering election with org balance:**
+The project elects a 5-seat steering committee. No more than [TODO: 1 / 2] seat(s) may be held by employees of the same organization. If election results would exceed this limit, the lowest vote-getter from the over-represented organization is replaced by the next-highest vote-getter from a different organization.
+
+### Scope
+
+Org-balanced voting applies to governance decisions listed above. Day-to-day technical decisions (PR review, merge, release) continue to follow the project's standard decision-making process (typically lazy consensus among maintainers).
+
+### Adoption
+
+To adopt this module, add the applicable sections to your project's governance document and list the specific decision types that use org-balanced voting. Update your MAINTAINERS.md to ensure all affiliations are current.
+
+<!-- For Maintainer Council projects, add this to your Voting section. -->
+<!-- For Steering Committee projects, add this to your Limitations on Company Representation section. -->
+<!-- For Federated Subproject projects, add this to your Steering Committee Elections section. -->

GOVERNANCE-subprojects.md

@@ -66,6 +66,14 @@ one representative to the Steering Committee.  This representative
 need not be a member of the subproject's Maintainer Committee, and will be 
 replaced or renewed by the committee annually.
 
+### Subproject Organizational Diversity
+
+Each subproject should track the organizational diversity of its maintainer
+committee. Umbrella projects can have overall organizational diversity while
+individual subprojects remain dominated by a single organization. The Steering
+Committee should review per-subproject diversity at least annually and work with
+subproject maintainers to grow external participation where concentration exists.
+
 Should a member of the Maintainer Committee cease being active in the subproject,
 violate the Code Of Conduct, or need to be removed for some other reason, they
 may be removed by a 2/3 majority vote of the other Committee members, or a

MAINTAINERS.md

@@ -1,13 +1,30 @@
 The current maintainers of the [TODO: Projectname] project are listed below.
 
 <!-- Sandbox projects require a minimum of 3 maintainers from 2+ organizations. -->
+<!-- Maintainer affiliations must be updated within 30 days of employment changes. -->
 
 | Name | GitHub/GitLab ID | Company/Organization |
 | ---- | ---------------- | -------------------- |
 |      |                  |                      |
 |      |                  |                      |
 |      |                  |                      |
 
+## Emeritus Maintainers
+
+Maintainers who have stepped back from active participation are recognized here. Emeritus maintainers do not have voting rights or merge access but are recognized for their contributions and may be consulted on project matters.
+
+A maintainer is moved to emeritus status after [TODO: Number, e.g. 12] months of inactivity, or by request. An emeritus maintainer may return to active status through the normal maintainer nomination process. See [the project Governance](GOVERNANCE.md) for the full maintainer lifecycle.
+
+| Name | GitHub/GitLab ID | Date moved to emeritus |
+| ---- | ---------------- | ---------------------- |
+|      |                  |                        |
+
+## Maintainer Affiliation Updates
+
+Maintainer affiliations (Company/Organization column) must be kept current. When a maintainer changes employers, they should update this file within 30 days. Accurate affiliations are essential for the CNCF to assess organizational diversity during project evaluations.
+
+---
+
 This list must be kept in sync with the [CNCF Project Maintainers list](https://github.com/cncf/foundation/blob/main/project-maintainers.csv).
 
 See [the project Governance](GOVERNANCE.md) for how maintainers are selected, replaced, and removed.