October 5, 2017·6 min read·engineeringkubernetesgovernancecommunity

Kubernetes gives its Steering Committee an explicit charter

Six elected members join seven continuity members on Kubernetes' initial Steering Committee. The charter defines authority over project structure and a procedure for changing the governance rules themselves.

An open source project can distribute implementation work while leaving authority over its own organization implicit. Kubernetes' October 5 Steering Committee election announcement describes the new committee as a step toward making that authority explicit. Its responsibilities include deciding which groups own which parts of the project and establishing processes through which contributors gain responsibility.

The initial committee combines six elected members with the seven members of the Bootstrap Governance Committee. It is therefore a transitional arrangement with both electoral representation and continuity. The charter available before the announcement defines how that arrangement should develop and how the committee can revise the rules as the project changes.

I care about this because a platform's maintenance structure affects the technical decisions its users eventually receive. Kubernetes depends on groups that can maintain APIs and operational tools over time. Giving those groups explicit authority and an escalation path makes the project's decision process easier to examine.

The first result preserves continuity while adding elected seats

Aaron Crickenberger, Derek Carr, Michelle Noorali, Phillip Wittrock, Quinton Hoole and Timothy St. Clair win the six elected positions. Derek, Michelle and Phillip receive two-year terms. Aaron, Quinton and Timothy receive one-year terms. The different term lengths establish staggered elections instead of replacing the entire elected membership at once.

They join Joe Beda, Brendan Burns, Clayton Coleman, Brian Grant, Tim Hockin, Sarah Novotny and Brandon Philips. These seven bootstrap members wrote the initial charter and organized the transition. The announcement describes them as long-time leaders representing five companies with substantial investment in the Kubernetes ecosystem.

The charter expands the initial committee to thirteen members to retain those continuity members. Its intended eventual structure has seven elected members serving two-year terms, with elections alternating between four seats and three seats. The continuity positions are temporary under the adopted plan. Those provisions describe a planned transition, not evidence that a fully elected seven-person committee already exists today.

That distinction is useful when assessing what the first election accomplishes. It adds an elected cohort and begins a replacement cycle while retaining the people who established the process. Authority now has an explicit organizational home, but the membership model still includes a deliberate bootstrap period.

The charter delegates technical responsibility

The Steering Committee decides which project subgroups are responsible for different areas and delegates authority to them. It can charter Special Interest Groups, Working Groups and Committees and establish their transparency and accountability policies. This gives the project a process for defining groups and their responsibilities as new work appears.

That role fits the structure described in the second-anniversary retrospective. SIGs already bring people from different organizations together around technical subjects and distribute leadership. The charter supplies an explicit place to decide how such groups are constituted and how their authority relates to the rest of the project.

The committee also defines governance processes for contributors becoming reviewers, approvers and maintainers. These roles affect who can advance changes and who is accountable for their review. A contributor's path to responsibility therefore becomes a governance subject in its own right, rather than a collection of undocumented local customs.

The scope includes deciding which subprojects belong to Kubernetes. Accepting a new subproject and pruning an existing one both fall within the charter. A growing project needs a way to define its boundaries as well as a way to approve changes within existing repositories. That decision influences which software receives the project's name and shared maintenance structure.

Infrastructure access is part of governance

The charter gives the committee control over repository access and a final escalation role for Kubernetes repositories. It also covers project assets such as artifact repositories, build and test infrastructure, websites and social accounts. These are operational powers that affect whether contributors can perform the work assigned to them.

The 1.6 release account provides a concrete reason to include those powers. That release team worked to document tribal knowledge and expose processes that required special permissions. Formal responsibility for a release is incomplete if the people holding it cannot access the necessary tools or learn the required procedures.

The committee's scope also includes deciding how official releases are made and what they contain. It can declare a release against quality, feature and other requirements. This connects project governance with the artifacts users receive, while allowing technical work and review to remain distributed among the appropriate groups.

Conformance is another explicit responsibility. The charter assigns the committee the task of defining a conformant Kubernetes cluster as part of certification. It also covers use of the Kubernetes brand. Those responsibilities connect the project's technical identity with the claims that vendors and users make about implementations.

Membership and candidacy have stated rules

The initial electorate consists of Members of Standing. The charter initially defines that group as the union of SIG leads, approvers and reviewers in Kubernetes-owned repositories, and people with write access to those repositories. It also acknowledges that this heuristic will fail to represent every contributor.

An exception process lets people with other contributions apply for standing. The bootstrap committee decides those applications by simple majority, and the charter intends the results to inform better membership criteria. This is an explicit admission that repository permissions are an imperfect proxy for participation in the project.

Anyone can nominate a candidate, including themselves. Ratification requires the nominee's acceptance and endorsements from three Members of Standing associated with three different employers. That requirement gives a candidate a basis of support beyond one company's internal reporting structure. Members of Standing can endorse more than one candidate.

The election uses a time-limited Condorcet ranking process through CIVS. The charter also limits any one company's representation to one-third of the committee. It supplies procedures for reducing excess representation, including situations caused by job changes or acquisitions. Corporate affiliation remains a governance concern after election day, not merely a condition checked when nominations close.

Campaigning rules restrict candidates' use of their employers' brands and prohibit employers from soliciting votes for them. Bootstrap members serving as continuity members pledge not to endorse candidates, although they retain voting rights. These provisions address different sources of influence within an election that includes contributors employed by major vendors.

Governance can change under a defined procedure

The committee can rewrite or remove charter provisions with a supermajority greater than two-thirds. The charter recommends using that power sparingly beyond small changes and in response to clear failures. It nevertheless gives the committee substantial authority to reform its own governing document.

That is a real tradeoff in the initial arrangement. The charter does not assign the broader community a formal role in rewriting governance. It relies on the committee to respond to the community and recognizes that contributors can leave or fork the project. The election creates representation, while the amendment procedure places formal revision authority with the elected and continuity members together.

Regular meetings must occur at least monthly, with a two-thirds attendance quorum. Meeting recordings should become publicly available. Confidential matters can receive closed sessions, but those sessions do not count toward the required meeting frequency, and the committee must announce their general reasons in advance. Transparency is thus a specified operating requirement with a defined exception.

Vacancies also have an explicit process. The next highest-ranked candidate from the preceding election receives an offer of the seat, with the process continuing until it is filled. If that fails, a special election fills the remaining term. A departing continuity member's position stays empty, so this mechanism does not recreate a bootstrap seat that has been vacated.

The committee must define and evolve a Code of Conduct with a neutral conflict-resolution process. That responsibility extends governance beyond selecting technical owners. Contributors need a way to resolve conduct disputes, including matters unsuitable for a public meeting recording. The charter's provisions for confidential meetings give the committee a procedure for handling that category of work while retaining public meetings as the normal arrangement.

My judgment of this arrangement depends on how clearly it identifies both powers and limitations. The committee has authority over project structure, access and releases, and it can change the rules governing itself. The first election announcement identifies immediate work, including selecting a CNCF Governing Board representative and chartering topical groups. Those are concrete decisions through which the new committee can begin applying the published charter.