How Projects Graduate and Who Makes the Decisions

One-line summary

A CNCF project passes through the three stages Sandbox → Incubating → Graduated, approved by the TOC (Technical Oversight Committee). Within Kubernetes, SIGs own the code and decisions, WGs handle topics that cut across SIGs, and large changes are proposed as KEPs. Contributing starts with signing the CLA and following the code of conduct, and once a reviewer or approver in an OWNERS file approves with /lgtm and /approve, the change is merged automatically.

Why this was needed

KCNA's Cloud Native Architecture domain asks not only about tools but about the structure of the people who build the tools. The reason is practical. To judge which project to adopt, whether it is Sandbox or Graduated is the first signal of maturity; when you hit a bug, you need to know which SIG to file the issue with to get an answer; and why a feature was designed the way it was is written in its KEP. If you do not know the community structure, you are not using open source but only downloading it.

How it works

CNCF project maturity and the TOC

According to the CNCF TOC repository, the TOC is the CNCF's technical governing body: it accepts and oversees all projects, sets the technical vision and principles, approves new projects within the scope set by the Governing Board, aligns, removes, and archives projects, and reflects the input of the End User Technical Advisory Board in the projects. The member list records members appointed by the GB, members appointed by the TOC, and members appointed by end users, each with a two-year term.

Project stages are defined by the TOC process document.

Stage	The document's definition
Sandbox	Early-stage experimental and innovative projects. They may fail, major changes and breaking compatibility are expected, and they are being refined through early adopters' feedback
Incubating	An intermediate stage where adoption is growing and stability is showing. The pace of change slows, versioned APIs stabilize, and this is the point where the TOC begins to actively evaluate adoption
Graduated	The most mature stage. They have shown stability, features, and broad adoption in the market, and have mature practices, security measures, and active community participation
Archived	Projects with little or no activity that the TOC no longer supports or recommends using

The CNCF projects page describes Graduated and Incubating projects as "considered stable and used successfully in production," and the Sandbox page explains Sandbox as the home of new projects that extend existing CNCF projects, independent projects trying new approaches, and experimental projects commissioned by the CNCF. In an adoption decision, the stage is a signal of "how well proven is it," not "how good is it." The document also notes that some organizations use even Sandbox projects in production.

Kubernetes SIGs, WGs, and committees

According to the Kubernetes governance document, the project is organized mainly into SIGs (Special Interest Groups). A SIG is made up of members from many companies and organizations and shares the common purpose of advancing the project on a particular topic such as networking or documentation. The goal is a distributed decision structure and code ownership, and every identifiable part of the project (GitHub organizations, repositories, directories, APIs, tests, issues, PRs) is to be owned by some SIG. SIG types are divided into vertical (Network, Storage, Node, Scheduling), horizontal (Scalability, Architecture), and project support (Testing, Release, Docs, Contributor Experience). Each SIG has at least one chair, preferably two, and must have a charter that states its scope, responsibilities, authority, how roles are elected, how decisions are made, and how conflicts are resolved. The SIG governance document stipulates that a SIG must hold a public meeting of at least 30 minutes at least every 3 weeks, publish minutes and recordings, and issue an annual report. Within a SIG there are subprojects, and the SIG list is where each SIG's chairs, contacts, and meeting times are written down.

A WG (Working Group), according to the governance document, is for discussing topics that cut across SIG boundaries within the scope of Kubernetes, and the SIG list document calls it a time-bounded group. A Committee handles topics that need discretion, such as security or the code of conduct, and unlike a SIG it is not open membership and is not always run in public. The Steering Committee creates committees as needed and decides their members.

KEP: how to propose a change

According to the KEP guide, a KEP (Kubernetes Enhancement Proposal) is the way to propose, communicate, and coordinate new work on Kubernetes. The start is to tell the sponsoring SIG about the idea: send it to the mailing list or put it on the meeting agenda, and after confirming that others think the work is worth doing and will help review, follow the KEP template. The document answers "generally, you should write a KEP": things that could be contentious, most new features except very small ones, large changes to existing features, and changes that affect most of the project need a KEP. Nearly all KEPs live in a SIG subdirectory, and the process was inspired by IETF RFCs, Python PEPs, and Rust RFCs. The value of a KEP is that a decision remains through a clear process with approvers and reviewers, and that decision can be looked up later.

The code of conduct

The Kubernetes community code of conduct page states that Kubernetes follows the CNCF code of conduct (v1.3) and reproduces the full text. The gist of the pledge is to respect everyone however they take part, whether reporting issues, requesting features, updating documentation, submitting PRs, or attending events, and to ensure harassment-free participation along any dimension such as age, disability, ethnicity, experience level, gender, nationality, race, religion, or sexual orientation. The scope covers the project and community spaces, as well as other spaces when a participant's words and actions are directed at a CNCF project or other participants. CNCF events run by the Linux Foundation with professional staff follow a separate event code of conduct. Besides the text of the code itself, the CNCF code of conduct page organizes the FAQ, the Code of Conduct Committee and its charter, the incident resolution process, the jurisdiction and escalation policy, the transparency report, and the ombudsperson.

Contributing: issues, PRs, and reviews

The contributor guide sets three things to do before you submit code: create a GitHub account, sign the CLA (Contributor License Agreement; opening a PR against the practice repository kubernetes-sigs/contributor-playground is the easiest way), and read the code of conduct and community values. A bot checks these three automatically at your first submission. Setting up a development environment is needed only when you submit code changes, and you can also contribute through documentation or issues.

The review described in the PR guide has two stages. When a person listed as a reviewer in the OWNERS file of the relevant directory adds /lgtm, it is a signal that the code has passed a trusted reviewer's review, and when a person listed as an approver adds /approve, it is a signal that it has passed the final review and is ready for automatic merge. The merge is done by the Prow bot. An OWNERS file can be placed in every directory and also applies to subdirectories, and it was inspired by Chromium's OWNERS files. Review speed is tied to the number of people who can review and review quality to familiarity with that code, so dividing responsibility with OWNERS is the way to solve both problems at once.

Events

The CNCF events page divides events into four kinds. KubeCon + CloudNativeCon is the flagship conference that gathers adopters and engineers on a worldwide scale; a Co-located Event is a CNCF-hosted event held alongside KubeCon that focuses on a particular project, landscape layer, or industry; a Project Event is an immersive gathering centered on a specific project; and KCD (Kubernetes Community Days) is an event hosted by a local community and supported by the CNCF, offering a low barrier to first-time speakers and people new to the community.

What it looks like in practice

"Can we use this project?" First look at the stage on the CNCF landscape. Graduated means several organizations have proven it in production, and Sandbox means going in as an early adopter prepared for compatibility breaks. The stage is the TOC's judgment, not a vendor's advertisement.

"I found a bug but do not know where to file it." If you open the OWNERS file in the relevant directory of the Kubernetes repository, you can see the SIG and reviewers that own that code. Finding the meeting time and Slack channel in the SIG list and asking there first is the way to keep your issue from being left unattended.

What to check in the next quiz

The quiz asks about the definitions of the maturity stages and the TOC's role, the difference between SIGs and WGs, the changes that need a KEP, the required procedures before contributing, who is behind /lgtm and /approve, and the kinds of events.