cncf/presentations: the community talk archive behind a website

A data repository with a small Go tool attached

The first thing to understand about this repository is that it is content, not software.

The project description is presentations from the CNCF community to share and reuse, and the readme says the repository is for the presentations.cncf.io site. The Go module confirms the scale of the code:

module github.com/cncf/presentations

go 1.20

The dependencies are two libraries, a command line framework and a YAML parser:

github.com/spf13/cobra v1.7.0
gopkg.in/yaml.v3 v3.0.1

So the Go part is a small command line tool that reads and validates the data, and everything else is the data itself. The primary language listed for the repository is Go, but the interesting artefact is a YAML file and a folder tree.

The top level of the repository makes the shape obvious. There is the presentations.yaml file, a command directory, a package directory, and then a long list of directories named after cloud native projects: kubernetes, prometheus, envoy, fluentd, coredns, grpc, jaeger, linkerd, opa and opentracing. There are also directories for 2016 events, a cncf-archive directory, and directories for Chinese, Japanese and Korean material.

That layout is doing two jobs at once. The per-project directories are the taxonomy that the website filters on, and the per-language directories are a second axis, so a talk can be found either by the project it is about or by the language it was given in.

Two doors into the submission process

The submission process is described with two paths, and the split is by technical confidence rather than by policy.

If you are not technical, you file an issue with a link to the video and the slides, and someone makes the pull request for you. If you are technical, you add your information to the presentations.yaml file at the top and open the pull request yourself.

The reason for the split is obvious once you see the data shape. Adding a talk is a mechanical edit to a structured file, and the tool exists to keep that file valid. For a maintainer, an issue with two links is cheap to turn into a pull request. For a non-technical speaker, finding the right place in a YAML file and getting the field names right is a barrier with no upside.

The readme also asks for ideas as well as data, saying this is a work in progress and subject to change, and inviting pull requests for ideas and changes you would like to see. That is a useful signal about how the project is run: the shape of the data is not frozen, and the person who wrote the first version of the site is not going to freeze it either.

The two-door approach also means the barrier to contributing a talk is as low as it can be while the barrier to contributing a tool is as high as it should be, which is a reasonable division for a content repository with a small tool around it.

The editorial line, and why it exists

The readme includes a question and answer section about what is accepted, and it is more considered than most submission policies.

The focus is on talks presented at CNCF events about CNCF projects, and the reason given is that these have already been vetted and accepted by the community. The stated aim is to avoid editorializing in the repository.

That is a coherent position for a catalogue. If the project accepted any talk on any cloud native topic, the archive would quickly become a list of links of uneven quality, and the person maintaining it would end up making editorial decisions without admitting to it. Restricting to talks that a CNCF event already accepted moves the editorial work to the event's programme committee, where it belongs, and leaves the repository as a record rather than a judgement.

The scope is expected to widen. The answer says the initial focus is on CNCF project talks and that the hope is to expand the scope to a broader range of topics in the future, and that if you believe your talk is valuable you should go ahead and submit it. So the current line is a starting point rather than a permanent policy.

On quantity there is no limit. The goal is to collect as many CNCF-related talks as possible, so the only limit is the number of talks you can realistically present. And on submitting for someone else, the readme notes that the information is publicly available in published schedules, encourages you to help colleagues enrich the topic tags, and asks you to consult the presenter first as a common courtesy.

What the archive looks like, including the old parts

The repository holds more than one generation of material, and the readme is candid about which parts are current.

The newer part is the presentations.yaml file, with the new submission flow, and the per-project directories for the projects the archive covers. The older part is described in a section titled other presentations, and the readme says those presentations from the CNCF community are available in the repository although they may be out of date, and asks for a pull request if you want a presentation added.

The directories at the root line up with that split. There are the 2016 collaboration summit and 2016 software circus directories, which are the earliest material, and a cncf-archive directory that presumably holds the rest of the historical set. The per-project directories for kubernetes, prometheus and the rest are the ones the current site serves from.

The language directories sit alongside the project ones, and they are the more unusual feature. Chinese, Japanese and Korean each have a directory, which means the archive is indexed by language as well as by topic, and a talk given at a CNCF event in Asia can be found by someone looking for material in their own language.

The licence requirement is stated for the older material: the readme asks that anything added to the other presentations section be under the Apache 2.0 or CC-BY licence so the content can be shared and reused easily. That is a practical constraint on contributors and a sensible one for a repository whose entire purpose is reuse.

The website is splitting out, the data is not

There is a section at the top of the readme that explains an ongoing migration, and it is the first thing a new contributor will read.

Frontend issues should be filed in a separate repository, the presentations-website one, rather than here. And the readme says the existing data and presentations will not be removed and will be migrated eventually, with a note asking for patience.

So the direction is clear: the content stays in this repository and the site moves elsewhere. That is a sensible split, because a repository that holds both the data and the site has a conflict of interest. Every change to the site risks being a change to the data model, and every change to the data risks breaking the site. Separating them means the data repository can accept a pull request that changes the shape of an entry without anybody having to review the rendering code.

The phrase existing data and presentations will not be removed is the reassuring part for a user of the archive. There is a long tail of material in the older directories, and the plan is to migrate it rather than to prune it, which for an archive of conference talks is the right instinct. Talks from 2016 are not interesting because they are recent, they are interesting because they are a record.

The trade-off is that during the migration the two halves may disagree, and the readme's own framing, with a heading that asks for pardon for the dust, tells you to expect that.

Licence, releases and what to check first

Three practical points to finish on.

The licence is the first. The repository listing does not record a licence, and the readme does not state one for the repository itself, only the requirement that contributions be under Apache 2.0 or CC-BY. If you are scraping the archive into something else, or shipping slides to users, that is the question to resolve, and the readme does not answer it.

The second is that there are no releases. The project is a website and a data set rather than a package, and the last push was on 2026-09-28 with the repository not archived, so the data is being maintained even though there is no version history to point at. The change log for a data repository is its commit history, which is a different kind of artefact from a changelog, and for a consumer the practical consequence is that you have to look at the file rather than at a version number to know what you have.

The third is the practical one. If you want the CNCF talk catalogue as data, the right place to look is the YAML file, which is structured and the one the tool reads. If you want a specific talk and you know roughly when it was given, the per-project and per-language directories are the place to look, accepting that the readme warns the older material may be out of date.

And if you want to contribute, the two-door process is the whole thing: an issue with links if you are not technical, or an edit to the top of the YAML file if you are.

Editorial conclusion

The repository suits anyone who wants the CNCF conference talk catalogue as a machine readable dataset, since the data is a single YAML file plus a directory tree, and the Go tool is small enough to read. It is a poor fit if you want a polished archive right now, because the readme says the site is being reorganised and the older material may be out of date. Before you rely on the data, check the licence of any talk you take, since the repository's own terms are not stated and the requirement for Apache 2.0 or CC-BY applies to submissions, and check whether the talk you want is in the current YAML file or only in the older directories.

Frequently asked questions

Official sources

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