13.2 Cloud Native Community, Collaboration & Contribution

13.2 Cloud Native Community, Collaboration & Contribution

Quick Answer: The official curriculum names Cloud Native Community and Collaboration as a competency in its own right. Kubernetes development is organised into SIGs (Special Interest Groups) with clear ownership, plus cross-cutting Working Groups. CNCF-wide technical guidance comes from TAGs (Technical Advisory Groups) advising the TOC. Contributors advance a defined ladder — contributor → member → reviewer → approver — recorded in OWNERS files. Participation is governed by the Linux Foundation Code of Conduct and the Developer Certificate of Origin.

Section 13.1 covered the CNCF's institutional structure: TOC, Governing Board, and the project maturity lifecycle. This section covers how humans actually work inside it — which is what the competency is asking about.

---

1. Special Interest Groups

Kubernetes is far too large for one group of maintainers, so the project is divided into SIGs, each with a defined scope, its own chairs and technical leads, a public meeting on a fixed schedule, a Slack channel, a mailing list, and a charter.

Smaller units sit inside this structure:

• Subprojects — a specific deliverable owned by a SIG (kubeadm under SIG Cluster Lifecycle, kubectl under SIG CLI).
• Working Groups — time-bounded, cross-SIG efforts on a single topic. A WG has no code ownership, does not own APIs, and dissolves when its goal is met — the crisp exam distinction from a permanent SIG.
• User Groups — communities of practice organised around a use case rather than a component.

All of this is public. Meeting agendas, recordings, and notes are published, and anyone may attend. There is no private channel where the real decisions get made — that transparency is a deliberate governance property.

---

2. Technical Advisory Groups

SIGs belong to Kubernetes. TAGs belong to the CNCF and reason across projects on behalf of the TOC: TAG Security and Compliance, TAG Network, TAG Storage, TAG App Delivery, TAG Observability, TAG Runtime, TAG Contributor Strategy, and others. TAGs publish whitepapers (the widely cited Cloud Native Security Whitepaper is a TAG Security output), run project due diligence for maturity-level applications, and produce landscape guidance.

---

3. The Contributor Ladder

Kubernetes defines an explicit progression, and the roles are recorded in machine-readable OWNERS files in each directory:

# OWNERS
approvers:
  - alice          # may /approve — final sign-off on merges here
  - bob
reviewers:
  - carol          # may /lgtm — technical review
  - dave
labels:
  - sig/network

Merging requires both /lgtm (from a reviewer) and /approve (from an approver in the relevant OWNERS file), and the Prow bot enforces it. The design intent is that authority is earned and localised: you become an approver for the directory you have demonstrably maintained, not for the project as a whole.

Above all of it sits the Kubernetes Steering Committee, elected by the contributor community, which handles project-wide governance rather than technical direction.

---

4. Rules of Participation

Kubernetes Enhancement Proposals

A substantial change to Kubernetes goes through a KEP: a structured document covering motivation, design, alternatives considered, test plan, and graduation criteria from alpha to beta to GA. Owning SIGs review and approve KEPs, and each release's feature set is essentially the set of KEPs that met their criteria in time. This is the process behind the API maturity levels in section 2.4.

---

5. Events and On-Ramps

---

6. Contribution Is Not Only Code

A point the community makes repeatedly, and one KCNA is happy to test: valuable contribution includes documentation, translation (kubernetes.io is localised into many languages), triaging and reproducing issues, reviewing pull requests, improving test coverage and reducing flakes, answering questions in Slack and on forums, running a local meetup, speaking, publishing adoption case studies, and reporting security vulnerabilities responsibly through a project's disclosure process.

SIG Docs and SIG Contributor Experience exist precisely because the project treats these as first-class work.

---

7. Where to Find Things