How to contribute

This page covers how kubernetes/kubernetes accepts contributions in practice. The authoritative copy lives in the community repo. Treat this page as a working summary of the same flow.

Sign the CLA

Every contributor must sign the Linux Foundation Contributor License Agreement. The Prow bot blocks PRs from unsigned authors automatically.

Find work

• Issues labeled good first issue or help wanted on the GitHub issue tracker are curated for new contributors.
• KEPs (Kubernetes Enhancement Proposals) live in the separate kubernetes/enhancements repo. New features must have a KEP before code merges.
• SIGs (Special Interest Groups) coordinate ownership. The OWNERS files at every directory level point to the SIG that approves changes there.

The PR lifecycle

1. Fork + branch. Branch off master. Use a descriptive branch name. The repo also accepts release-1.x PRs for cherry-picks.
2. Push code. Open a pull request with a kind/* label (bug, feature, cleanup, documentation) and a sig/* label.
3. Bot triage. The Prow bot assigns reviewers from OWNERS files and applies labels. CI starts immediately.
4. Review. Reviewers leave /lgtm; approvers leave /approve. Both are required before merge.
5. Tide. When all required labels are set and CI is green, Tide rebases (if needed) and merges. There is no human merge button.
6. Cherry-pick. If a fix needs to land on a release branch, follow hack/cherry_pick_pull.sh.

What every PR must include

• DCO sign-off (git commit -s) and a CLA signature.
• A release-note block in the description (NONE is acceptable for chores).
• Updated tests. New behaviour without tests is a near-automatic block.
• Regenerated code if you touched API types (hack/update-codegen.sh and friends).
• A green make verify locally.

Definition of done

Box	Meaning
Tests pass locally and in CI	Including unit, integration, e2e where applicable
Generated code is up to date	verify-codegen.sh is green
Lint is clean	verify-golangci-lint.sh is green
Approvers and reviewers from each affected OWNERS have signed off	/lgtm + /approve from a SIG owner
Release note set	release-note block in the PR description
KEP referenced (for features)	Mentioned in the PR description

Sub-pages

• Development workflow — branching, commits, signing, rebasing
• Testing — unit, integration, e2e, conformance, fuzz
• Debugging — logs, common errors, troubleshooting runbook
• Patterns and conventions — Go style, error handling, controllers, error wrapping, imports
• Tooling — Make, codegen, linters, vendor, OWNERS, Prow bot commands