How to contribute

Cilium is an open community project. New contributors are welcomed via the Cilium Slack #development channel, the contributor guide, and the weekly developer meeting.

At a glance

1. Find an issue or open one. Look at the kind/community-help, good-first-issue, and SIG-specific labels.
2. Sign your commits (git commit -s) — the DCO is enforced by CI (see .github/workflows/dco-check.yml).
3. Fork, branch, and open a PR. The PR template (.github/pull_request_template.md) enumerates required release notes.
4. Apply the appropriate release-note/... and area/... labels (or wait for a maintainer to do so).
5. Pass CI: lint, codegen, unit tests, BPF unit tests, and a curated set of integration matrices in GitHub Actions.
6. Receive review from at least one maintainer; some areas (CRDs, Helm, security) require additional approvers per CODEOWNERS.

Definition of done

A change is ready to merge when:

• All CI checks are green (build, vet, golangci-lint, generated-files-up-to-date, unit, privileged unit, BPF unit, connectivity-test matrix).
• Every public surface change carries a release-note line (release-note/major, release-note/minor, release-note/bug).
• Generated files (CRDs, Helm values, OpenAPI, mocks, BPF asm dumps, cmdref) are committed alongside the source change. The Documentation/check-*.sh scripts will fail CI otherwise.
• Documentation under Documentation/ is updated for any user-facing behaviour change.
• The change is reviewed by the relevant CODEOWNERS for the touched paths.

Useful sub-pages

• Development workflow — branch / PR / release branches.
• Testing — unit, privileged unit, BPF unit, connectivity test.
• Debugging — cilium-dbg, bugtool, BPF map inspection, monitor.
• Patterns and conventions — Hive cells, error handling, log conventions.
• Tooling — make targets, codegen, kind, lint.

Contacts

MAINTAINERS.md holds the committer roster. SIG ownership lives in cilium/community/sigs.yaml. The Slack #development channel is the fastest route to ask a question.