Making your First Contribution
Your First Contribution
- Find something to work on
Find something to work on
Help is always welcome! For example, documentation (like the text you are reading now) can always use improvement. There’s always code that can be clarified and variables or functions that can be renamed or commented. There’s always a need for more test coverage. You get the idea - if you ever see something you think should be fixed, you should own it. Here is how you get started. If you have no idea what to start on, you can browse the Contributor Role Board to see who is looking for help. Those interested in contributing without writing code may also find ideas in the Non-Code Contributions Guide.
Find a good first topic
There are multiple repositories within the Kubernetes organization.
Each repository has beginner-friendly issues that provide a good first issue.
For example, kubernetes/kubernetes has help wanted and good first issue labels for issues that should not need deep knowledge of the system.
good first issue label indicates that members have committed to providing extra assistance for new contributors.
Another good strategy is to find a documentation improvement, such as a missing/broken link, which will give you exposure to the code submission/review process without the added complication of technical depth. Please see Contributing below for the workflow.
Issue Assignment in Github
When you are willing to take on an issue, you can assign it to yourself. Just reply with
/assign @yourself on an issue,
then the robot will assign the issue to you and your name will present at
Learn about SIGs
You may have noticed that some repositories in the Kubernetes Organization are owned by Special Interest Groups, or SIGs. We organize the community into SIGs in order to improve our workflow and more easily manage what is a very large community project. The developers within each SIG have autonomy and ownership over that SIG’s part of Kubernetes. Check out the list of SIGs for contact information.
Understanding how to interact with SIGs is an important part of contributing.
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. SIGs have regular video meetings which everyone is welcome to. Each SIG has a slack channel, meeting notes, and their own documentation that is useful to read and understand.
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! Better yet, help us fix it by joining the SIG; just show up to one of the bi-weekly meetings.
Find a SIG that is related to your contribution
Finding the appropriate SIG for your contribution and adding a SIG label will help you ask questions in the correct place and give your contribution higher visibility and a faster community response.
For Pull Requests, the automatically assigned reviewer will add a SIG label if you haven’t done so. See Open A Pull Request below.
For Issues, we are still working on a more automated workflow. Since SIGs do not directly map onto Kubernetes subrepositories, it may be difficult to find which SIG your contribution belongs in. Here is the list of SIGs so that you can determine which is most likely related to your contribution.
Follow the link in the SIG name column to reach each SIGs README. Most SIGs will have a set of GitHub Teams with tags that can be mentioned in a comment on issues and pull requests for higher visibility. If you are not sure about the correct SIG for an issue, you can try SIG-contributor-experience here, or ask in Slack.
SIG-specific contributing guidelines
Some SIGs have their own
CONTRIBUTING.md files, which may contain extra information or guidelines in addition to these general ones.
These are located in the SIG-specific community directories:
File an Issue
Not ready to contribute code, but see something that needs work? While the community encourages everyone to contribute code, it is also appreciated when someone reports an issue (aka problem). Issues should be filed under the appropriate Kubernetes subrepository. Check the issue triage guide for more information.
Example: a documentation issue should be opened to kubernetes/website.
Make sure to adhere to the prompted submission guidelines while opening an issue.
Was this page helpful?