This document assumes that you know what Kubernetes does. If you don't, check out the Kubernetes keynote and try the demo at https://k8s.io/.
Have you ever wanted to contribute to the coolest cloud technology? This document will help you understand the organization of the Kubernetes project and direct you to the best places to get started. By the end of this doc, you'll be able to pick up issues, write code to fix them, and get your work reviewed and merged.
If you have questions about the development process, feel free to jump into our Slack Channel or join our mailing list.
Kubernetes developers work in teams called Special Interest Groups (SIGs). At the time of this writing there are 31 SIGs.
The developers within each SIG have autonomy and ownership over that SIG's part of Kubernetes. SIGs organize themselves by meeting regularly and submitting markdown design documents to the kubernetes/community repository. You can see an example of the design document process at kubernetes/community#645. Like everything else in Kubernetes, a SIG is an open, community, effort. Anybody is welcome to jump into a SIG and begin fixing issues, critiquing design proposals and reviewing code.
Most people who visit the Kubernetes repository for the first time are bewildered by the thousands of open issues in our main repository. But now that you know about SIGs, it's easy to filter by labels to see what's going on in a particular SIG. For more information about our issue system, check out issues.md.
This guide is non-technical, so it does not cover the technical details of working Kubernetes. We have plenty of documentation available under github.com/kubernetes/community/contributors/devel. Check out development.md for more details.
The pull-request process is documented in pull-requests.md. As described in that document, you must sign the CLA before Kubernetes can accept your contribution.
There is an entire SIG (sig-contributor-experience) devoted to improving your experience as a contributor. Contributing to Kubernetes should be easy. If you find a rough edge, let us know! File an issue in the appropriate repository if you know it, send a message on our Slack channel or to the owners of contributor-experience. Better yet, help us fix it by joining the SIG; just show up to one of the bi-weekly meetings.
Every so often @k8s-merge-robot will refuse to merge your PR, saying something about release milestones. This happens when we are in a code freeze for a release. In order to ensure Kubernetes is stable, we stop merging everything that's not a bugfix, then focus on making all the release tests pass. This code freeze usually lasts two weeks and happens once per quarter. See the 1.8 release schedule for more information.
If you're new to Kubernetes, you won't have to worry about this too much. After you've contributed for a few months, you will be added as a community member and take ownership of some of the tests. At this point, you'll work with members of your SIG to review PRs coming into your area and track down issues that occur in tests.
Thanks for reading!