The CNCF TOC repository is the record of how cloud native projects are admitted

Admission, alignment and archiving are the three powers

The TOC admits and oversees all projects in the CNCF, and its mandate is stated as driving neutral consensus on four things. It defines and maintains the technical vision and principles for the foundation, with the principles living in PRINCIPLES.md at the repository root. It approves new projects within the scope the Governing Board sets, creates a conceptual architecture for those projects, aligns projects, and removes or archives them. It accepts feedback from the end user technical advisory board and maps that to projects. Finally, it aligns interfaces to components under management, referencing code implementations before standardizing, and defines common practices to implement across CNCF projects where any apply.

That third bullet is the one engineers usually miss. The TOC is not only an admissions committee; it can take a project out. Removal and archiving sit in the same mandate as approval, which is what makes the maturity levels meaningful rather than decorative.

The technical vision is described as problem-centric: the direction of the ecosystem follows the problems adopters face rather than a technology agenda.

The directory tree is a map of the governance process

What makes this repository usable rather than merely public is the layout. process/ holds the project lifecycle description that the README links for anyone asking how a project moves through the foundation. operations/ holds the election schedule and the decision process document that defines voting. governance/ and DEFINITION.md cover the structural rules. projects/ holds the per-project records. tags/ holds each Technical Advisory Group directory.

There are also files that exist to record departures. EMERITUS.md tracks members who have left, and .archive/ is present at the root for content that is kept but no longer current. PRINCIPLES.md and CONTRIBUTING.md sit alongside FAQ.md.

Four entries are less obvious and more telling. skills/ suggests a deliberate effort to capture how to do things as reusable material. toc_subprojects/ groups the committee's own subprojects, and initiatives/ its cross-cutting work. .gitvote.yml declares a voting bot at the root, which means the binding votes in the decision process are cast through the repository rather than in a meeting.

Finally, generator/ and go.mod: the only Go in the repository is a small documentation generator, module k8s.io/community, requiring Go 1.22.4 with two direct dependencies, misspell and yaml.v2. It is a site generator for these Markdown files, not application code.

Membership is appointed by four different bodies

Eleven members are listed, each with a two-year term, and each tagged with who appointed them. That tag is the interesting part because it shows the TOC is not a self-perpetuating club.

The appointment sources are EndUser-appointed, TOC-appointed, GB-appointed and Maintainer-appointed. The GB appointments come from the Governing Board; TOC appointments are the committee choosing its own members; maintainer appointments recognise the people actually running project infrastructure; and end user appointments bring the adopter perspective in, which is the counterpart to the mandate item about accepting feedback from the end user technical advisory board.

Because Angell is both GB-appointed and marked TOC Chair, the chair role sits inside an appointed seat rather than being a separate position. Terms are staggered across two start dates, 3/4/2025 and 5/12/2026, both running two years, which is the mechanism that keeps the body from turning over at once.

Two alternates serve one-year terms from 5/12/2026 to 5/12/2027, one GB-appointed and one TOC-appointed, and the README states plainly that alternates are non-voting members.

Every member holds a liaison seat, which is how the work actually flows

The TAG and TCG liaison list assigns each member to specific groups, and the distribution is the informative part. TAG Infrastructure carries three liaisons, TAG Operational Resilience four, TAG Developer Experience three, TAG Security and Compliance two, and TAG Workloads Foundation four.

On the technical coordination group side, Platform Engineering has two, Artificial Intelligence two, Environmental Sustainability three, and Software Supply Chain Security one. Some members hold several seats. Several of the same people bridge a TAG and a TCG, for example one who sits on TAG Infrastructure and TCG Platform Engineering.

The mechanism is straightforward: a project seeking admission arrives through the group that understands its domain, and the member who already sits there carries the argument into the TOC. That is why the liaison list is maintained as a first-class section of the README rather than left implicit, and why it is worth checking before opening an issue. Bringing a proposal to a group that has no TOC member present costs a meeting cycle.

Voting is restricted to members, and +1 means binding

The README links the voting policy to operations/toc-decision-process.md and states one rule directly: only TOC members can cast binding votes, marked +1 Binding.

The implication for anyone outside the committee is worth stating plainly. A vote on an issue is a way to signal technical merit, not a way to decide an outcome. Alternates are non-voting, TAG and TCG liaisons are not by virtue of their liaison role voting members, and adopters have no binding voice even though the mandate mentions the end user technical advisory board.

This is a normal shape for a foundation committee, and it is the reason the written process matters more than the meeting schedule for an outsider. Someone who cannot attend can still influence the outcome by making the arguments on the record in the issue before the vote.

Two meeting days a month, and minutes kept as issues

The TOC meets on the first and third Tuesday of every month at 8AM Pacific. The public calendar lives on the Linux Foundation Zoom platform and is also mirrored on the CNCF website, and meetings can be joined directly from the calendar entry.

Minutes are not documents in this repository; they are GitHub issues labelled kind/meeting, which means the whole governance history is greppable and linkable. Three archives cover what came before: a Google Doc of meeting working documents from 2018.10 to 2024.08, a repository file of meeting agendas and presentations from 2016.02 to 2019.06, and another file of community presentations from 2016.04 to 2018.11. A YouTube playlist holds the recordings.

The move from documents to labelled issues is a small design decision with a large effect: a contributor can search every meeting for the word they care about, which is not something a folder of PDFs allows.

Two addresses, and a separate one for sensitive matters

The public mailing list is [email protected], with its archive at lists.cncf.io and Mailman join instructions linked from the README. The Slack equivalent is the #toc channel on CNCF slack.

What is worth noticing is the second address. The README says that to reach the TOC on sensitive issues, email [email protected]. Two lists, one public and one private, with the distinction drawn explicitly in the public document, is a deliberate piece of transparency about the existence of a private path rather than an accident of configuration.

For a contributor, the practical routing is: general business to the public list or Slack, proposals to the relevant TAG or TCG through its liaisons, and sensitive or personal matters to the private address. The README also points to the CNCF contributors guide for people new to the foundation and to the project lifecycle document for how a proposal moves.

A governance repository has a maintenance cost, and this one shows it

The repository is not archived and the last push was on 2026-10-13, which is consistent with a body that meets twice a month. It has no GitHub releases, which is correct: a set of governance documents does not have release artifacts.

There is no licence file at the root and the repository's licence field is empty. That is a genuine gap for anyone who wants to reuse the TOC's decision process, its principles or its project templates in their own foundation's documents. Where the licence is unknown, the safe assumption is that nothing may be copied, so if you need the templates, ask rather than fork.

The primary language is listed as HTML, which is an artifact of the static site the generator produces. The actual content is Markdown in a directory structure that reads as a filing system: everything an adopter, a project maintainer or a prospective applicant would need to find is at a predictable path.

Editorial conclusion

Read this repository if you are preparing a CNCF project proposal or want to know what the technical governing body actually decides, because the admission, alignment and archiving rules sit in process/README.md and operations/toc-decision-process.md alongside the meeting minutes. Do not treat it as a governance framework you can copy; the membership model, the two-year terms and the TAG structure are specific to this foundation. Verify first the maturity level of the project you care about, since Sandbox, Incubating and Graduated carry different service entitlements, and check operations/election-schedule.md for how the current membership terms were set.

Frequently asked questions

Official sources

1. cncf/toc on GitHub
2. Issues
3. Project website
4. README