Making your First Contribution
Your First Contribution
- Find something to work on
Find something to work on
The first step to getting starting contributing to Kubernetes is to find something to work on. Help is always welcome, and no contribution is too small (but see below)!
Here are some things you can do today to get started contributing:
- Help improve the Kubernetes documentation
- Clarify code, variables, or functions that can be renamed or commented on
- Write test coverage
- Help triage issues
If the above suggestions don’t appeal to you, you can browse the issues labeled as a good first issue to see who is looking for help. Those interested in contributing without writing code can also find ideas in the Non-Code Contributions Guide.
Note: although contributions are welcome, beware that every pull request creates work for maintainers and costs for testing it. Fixing linter warnings is often not worth it because the existing code is fine. Always discuss with maintainers first before creating such PRs.
Find a good first topic
There are multiple repositories within the Kubernetes organization.
Each repository has beginner-friendly issues that are a great place to
get started on your contributor journey. For example, kubernetes/kubernetes has
help wanted and good first issue labels for issues that don’t need high-level
Kubernetes knowledge to contribute to. The
good first issue label also indicates
that Kubernetes Members have committed to providing extra assistance for new
contributors. Another way to get started 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.
Issue Assignment in Github
When you’ve found an issue to work on, you can assign it to yourself.
- Reply with
/assign @yourselfon the issue you’d like to work on
- The K8s-ci-robot will automatically assign the issue to you.
- Your name will then be listed under,
Learn about SIGs
Some repositories in the Kubernetes Organization are owned by [Special Interest Groups], or SIGs.
The Kubernetes community is broken out into SIGs in order to improve its 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. Understanding how to interact with SIGs is an important part of contributing to Kubernetes. Check out the list of SIGs for contact information.
A SIG is an open, community effort.
Anybody is welcome to jump into a SIG and begin fixing issues, critique design proposals, and review code. SIGs have regular video meetings which everyone is welcome to attend. 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. If you have an idea for improving the contributor experience, please consider attending one of the Contributor Experience SIG’s 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 already done so.
For Issues, please note that the community is 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. Review the list of SIGs to determine which SIG is most likely related to your contribution.
Follow the link in the SIG name column to reach each SIG’s 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, 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
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. Issues should be filed under the appropriate Kubernetes subrepository. For example, a documentation issue should be opened in kubernetes/website. Make sure to adhere to the prompted submission guidelines while opening an issue. Check the issue triage guide for more information.
Was this page helpful?