# cncf/foundation: the policy documents behind a foundation > The cncf/foundation repository is the document set a foundation runs on: a charter, a maintainer election policy, a membership agreement, a code of conduct with translations, licence allowlists and website neutrality rules. It has no code and no releases, and its most consequential file is a maintainer list that is generated from elsewhere and must not be edited by hand. **cncf/foundation** — ☁️♮🏛 This repo contains several documents related to the operation of the CNCF. File non-technical issues related to CNCF here. - Repository: https://github.com/cncf/foundation - Website: https://cncf.io - Stars: 696 · Forks: 872 - Language: Rich Text Format - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/cncf-foundation ## A repository whose product is a set of documents There is no code in cncf/foundation. The primary language is recorded as Rich Text Format and the tree is dominated by Markdown documents, a PDF, agreements, policies and CSV files. The description says the repository contains documents related to the operation of the Cloud Native Computing Foundation, and that non-technical issues related to CNCF should be filed there. That scope statement is the first useful thing to know, because the request for changes section repeats it: you are welcome to file non-technical issues on this repository. Technical problems with any particular project live in that project's own tracker, not here. The homepage is cncf.io, and the README notes that the public programs the foundation offers are documented there. The repository does not publish releases, and the last push was on 2026-10-20, so the documents are actively revised even though there is no versioned artefact to download. A reader who wants to know what a policy said at a given moment has to rely on the git history of the file rather than on a tag, which is a meaningful difference from a policy that ships as a versioned release. The tree also shows a lot of operational documents beyond the headline set: conformance-programs.md, journey-reports.md, do-insurance.md, travel_funding.md, cncfgroups.md, cncf-marketing-committee-chair.md, legal-committee-charter.md, KubeWeekly.md, a netlify.toml for site configuration, and a skills/ directory. ## The governance set: charter, elections, membership, conduct Four items make up the governance section, and each has a different status and a different kind of binding force. The charter is the document the foundation operates under. The maintainer election policy covers the maintainer-elected TOC member and the two maintainers on the governing board, which tells you the shape of the elected positions without needing to read the whole election rules. The membership agreement is a PDF, which is worth noting because the terms you accept as a member arrive as a signed-style document rather than as editable text in the repository. The Code of Conduct is a Markdown file, and it has been translated into multiple languages, with a code-of-conduct-languages/ directory and a code-of-conduct/ directory alongside it in the tree. The translations are a genuinely useful signal for anyone working in a language other than English, because a code of conduct that only exists in English is a code of conduct that only binds the people who read English. The separate translation.md file, described as a translation guide for the Chinese equivalent of cloud native phrases, points in the same direction: the foundation treats translation as an operational concern rather than a courtesy. The maintainer election policy is the one that affects contributors most directly, because it is about who has standing to make technical decisions in a project. A maintainer-elected TOC member and two governing board maintainers are the positions it covers, and the charter is the document that gives the TOC its authority in the first place. ## Licence allowlists and copyright notices decide what you can depend on The project guidance section is where an engineering team gets practical answers, and it covers three things. The allowlist licence policy states which licences are acceptable in upstream dependencies without requiring an explicit vote of the governing board. That is a real time saver, and it is the kind of rule that a project would otherwise have to invent badly on its own. A dependency on a permissively licensed library is uncontroversial; a dependency on a copyleft library is a decision some projects will not want to make, and a licence with attribution obligations is a decision most projects will want to record. The allowlist turns that from a per-project argument into a lookup. The tree also carries a license-exceptions/ directory and a license-notices.md file, which are where individual exceptions and required notices live. The copyright notice recommendations cover how to attribute contributions and what notices to carry. The website guidelines cover something more subtle: how to mention companies while maintaining neutrality. That is a harder document to write than a licence list, because a foundation that names commercial sponsors must still read as neutral to everyone else, and the guideline is the mechanism that keeps a blog post or a project page from turning into an advertisement. All three sit under policies-guidance/, and the directory naming is the point: they are guidance, distinct from the governance documents above them, even though both kinds of file are read as binding by different audiences. ## Two maintainer lists, and only one of them is yours to edit The most operationally detailed part of the README concerns the maintainer records, and it is worth reading twice because the two files behave differently. The primary list is project-maintainers-.project.csv, and it is generated automatically for projects that manage their maintainers in their own .project repository. The change path is to update maintainers.yaml in the project's .project repo, and automation picks it up. The README is emphatic that the CSV must not be edited directly, because manual edits are overwritten. This is a data pipeline with one direction, and the generated file is an output rather than a source. The second file, project-maintainers.csv, is a legacy list for projects that have not yet been onboarded to the .project process. Here the process inverts: an existing maintainer of one of these projects updates it by pull request, and also emails cncf-maintainer-changes@cncf.io or raises a service desk ticket so the foundation-run maintainer mailing list is updated to match. Two channels, one pull request and one notification, because the CSV and the mailing list are separate systems that have to be kept aligned by hand. The access model for the service desk and the mailing lists is tied to a link between a maintainer's GitHub handle and their LFID, and that link can be updated at openprofile.dev. The name and affiliation shown in the generated list are taken from the LFID profile. That is the mechanism behind the third record the README asks you to keep in sync: the .project/maintainers.yaml file records GitHub handles and teams, and changing it does not update the LFID or the project documentation, while updating a profile does not update the project repository. The README states plainly that these records must be kept in sync, which is a fair description of a process that spans four systems and needs a human to hold the thread. ## The style guide and the translation guide are how the foundation keeps language consistent Two documents exist to make the foundation's language uniform rather than to prescribe behaviour. The style guide is a set of recommendations for cloud native terminology, and the translation guide covers the Chinese equivalent of cloud native phrases. Read together they suggest the foundation is trying to fix vocabulary, not grammar, and to do it in more than one language. That is unusual in a foundation policy repository, and it reflects something real about the ecosystem: the same technical concept gets a different name in every language community, and inconsistent naming inside a project makes documentation harder to write and support questions harder to answer. The blog guidelines are a third document in the same family, and they cover who can submit, the suggested topics, and how to submit. That combination, a topic list plus an open call for submissions, is what makes the foundation's blog a channel that outside contributors can actually use. For a project that wants to talk about itself in a foundation forum or event, these are the documents that tell you what is expected. A style guide that says which term to use for a workload scheduler is a small thing, but it is the sort of small thing that becomes expensive when hundreds of projects pick different words. ## Where the real content lives elsewhere The README is candid that most project, TAG and TOC content sits in a different repository. Project and Technical Oversight Committee documents are in the cncf/toc repository, and cncf.io carries the information on all programs offered publicly by the foundation. This is a pointer worth following rather than a limitation. A policy repository that tried to contain everything would be a worse repository, because the things that change most often, namely which projects are in which stage and who sits on the TOC, would sit next to the things that change most slowly, namely the charter. Splitting them means each has an appropriate update rhythm. It also means the two repositories have to be read together if you are trying to answer a real question. The charter in this repository tells you what the TOC can do, and the TOC repository tells you what the TOC has decided. The same applies to the conformance programs listed in conformance-programs.md, which reference a certification process that lives in its own tooling. Questions about maintainer records have a single documented address, cncf-maintainer-changes@cncf.io, which is stated in both the maintainer section and the service desk context. For a foundation of this size, one well-known address is a good deal more useful than a scattering of contact forms. ## Conclusion Use the cncf/foundation repository when you need the authoritative text behind a foundation decision, when you maintain a project that wants CNCF guidance on licensing, attribution or neutrality, or when you are an existing maintainer of a project still on the legacy maintainer list. Do not expect it to be a place to file technical issues, because the README is explicit that only non-technical issues belong here, and do not edit the generated maintainer CSV by hand, since those edits are overwritten by automation. Before you act, read the charter and the maintainer election policy rather than the summaries, and if you are changing a maintainer record, decide first whether the project is on the .project process or still on the legacy CSV, because the two paths have different workflows and different notification requirements. ## FAQ ### What is the cncf/foundation repository for? It holds the documents related to the operation of the Cloud Native Computing Foundation, including the charter, the maintainer election policy, the membership agreement and the Code of Conduct. Non-technical issues related to CNCF can be filed there. ### How are CNCF project maintainers recorded and changed? There are two lists. project-maintainers-.project.csv is generated automatically from the maintainers.yaml in each project's .project repo, so manual edits to it are overwritten. project-maintainers.csv is the legacy list for projects not yet onboarded, and an existing maintainer updates it by pull request and also emails cncf-maintainer-changes@cncf.io or raises a service desk ticket. ### What is the CNCF allowlist licence policy? It sets out which licences are acceptable in upstream dependencies without requiring an explicit vote of the governing board. The tree also carries a license-exceptions/ directory and a license-notices.md file for individual exceptions and required notices. ### What kind of issues should be filed in the cncf/foundation repository? Only non-technical issues related to CNCF. The README states the repository contains documents about the foundation's operation and invites non-technical issues there, while project-specific technical issues belong in the individual project's tracker. ### Why do I need to keep LFID and project records in sync for CNCF maintainers? Access to the CNCF Service Desk and the project maintainer mailing lists is controlled by a link between a maintainer's GitHub handle and their LFID, and the name and affiliation in the generated list come from the LFID profile. Updating the .project maintainers.yaml does not update the LFID or the project documentation, and updating the profile does not update the project repository. ## Sources - [cncf/foundation on GitHub](https://github.com/cncf/foundation) - [Issues](https://github.com/cncf/foundation/issues) - [Project website](https://cncf.io) - [README](https://github.com/cncf/foundation/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cncf-foundation