Kubernetes is open source, but many of the people working on it do so as their day job. In order to avoid forcing people to be “at work” effectively 24/7, we want to establish some semi-formal protocols around development. Hopefully, these rules make things go more smoothly. If you find that this is not the case, please complain loudly.
As a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays. Please do not ever hesitate to ask a question or send a pull request.
Check out our community guiding principles on how to create great code as a big group.
For quick reference on contributor resources, we have a handy contributor cheatsheet.
It is best to contact your SIG for issues related to the SIG’s topic. Your SIG will be able to help you much more quickly than a general question would.
To check out code to work on, please refer to the GitHub Workflow Guide.
The full workflow for a pull request is documented here:
That document is comprehensive and detailed, for purposes of a typical pull request we will cover the initial and simple use case here:
Pull requests are often called a “PR”. Kubernetes generally follows the standard github pull request process, but there is a layer of additional kubernetes specific (and sometimes SIG specific) differences:
The first difference you’ll see is that a bot will begin applying structured labels to your PR.
The bot may also make some helpful suggestions for commands to run in your PR to facilitate review.
/command options can be entered in comments to trigger auto-labeling and notifications.
Refer to its command reference documentation.
Common new contributor PR issues are:
For a brief description of the importance of code review, please read On Code Review.
There are two aspects of code review: giving and receiving.
To make it easier for your PR to receive reviews, consider the reviewers will need you to:
Reviewers, the people giving the review, are highly encouraged to revisit the Code of Conduct as well as community expectations and must go above and beyond to promote a collaborative, respectful community. When reviewing PRs from others The Gentle Art of Patch Review suggests an iterative series of focuses which is designed to lead new contributors to positive collaboration without inundating them initially with nuances:
Note: if your pull request isn’t getting enough attention, you can use the #pr-reviews channel on Slack to get help finding reviewers.
fixes #123in the PR body (where 123 is the specific issue number the PR will fix. This will automatically close the issue when the PR is merged.
fixeskeywords in your git commit messages. These should be included in the PR body instead.
There are multiple types of tests. The location of the test code varies with type, as do the specifics of the environment needed to successfully run the test:
Continuous integration will run these tests either as pre-submits on PRs, post-submits against master/release branches, or both.
The results appear on testgrid.
sig-testing is responsible for that official infrastructure and CI. The associated automation is tracked in the test-infra repo. If you’re looking to run e2e tests on your own infrastructure, kubetest is the mechanism.
Have you ever noticed the total number of open issues? Helping to manage or triage these open issues can be a great contribution and a great opportunity to learn about the various areas of the project. Triaging is the word we use to describe the process of adding multiple types of descriptive labels to GitHub issues, in order to speed up routing issues to the right folks. Refer to the Issue Triage Guidelines for more information.
Was this page helpful?