Kubernetes is a fast-growing open source project that relies on its contributors and users to maintain and improve it. We aim to be an open, inclusive, welcoming community and are always happy to see new faces join us.
You do not have to be an experienced systems engineer to contribute. You don't even have to be a software engineer; we welcome tech writers, project managers, and students. There are multiple ways you can contribute to Kubernetes, and not all of them involve code. You can attend and speak up at meetings, ask questions on Slack, and file issues.
One of the best ways to join an open source community is to make a contribution, and this article is here to help your first contribution be a successful one.
Communicate
Join the Kubernetes Slack. Kubernetes is a growing community, which means we're still figuring out how to document everything, and often the best way to get unstuck is to reach out for help from a more experienced contributor. In fact, on the second Wednesday of each month, we have a "Meet Our Contributors" video chat just for that. Find it in the Kubernetes Community Calendar, and the corresponding Slack channel #meet-our-contributors. You may also find help in the following #kubernetes-users, #kubernetes-novice, or #sig-contribex.
Do the basics
You have to sign the Contributor License Agreement and agree to the Community Code of Conduct.
You should be familiar with how GitHub works, as well as with the Kubernetes Project's GitHub workflow.
Find your issue
Choosing your first issue to work on depends on the motivation for your contribution as well as your level of technical comfort. You may choose to fix an existing issue or file a new one.
Choosing a contribution may happen organically as part of using Kubernetes. Let's say you notice a bug and you would like to fix it, or you think of a feature that would be nice to have and you would like to add it. You are familiar enough with the languages and tools that this would not be too difficult for you.
Browse the open GitHub issues and see if you can find a related open issue; if not, create one. Adhere to the guidelines outlined in the issue and pull request templates as best as you can. Solicit feedback from the community by commenting on the issue or asking in Slack, and coordinate with any people who may already be working on the issue before you set out to work.
You may also want to contribute because you want to learn about Kubernetes and are trying to get some practical experience along the way. Look in the Kubernetes project repositories for labels such as "help wanted" or "good first issue."
A great beginner approach is to find and fix a typo. This allows you to experience the workflow without worrying about code standards and skills.
Stay on top of your contribution
Because Kubernetes is a huge project that spans multiple repositories and has thousands of members, it can be difficult to get attention, even if you tag someone's name in GitHub. We don't mean this personally!
This is where SIGs (special interest groups) come in. These are smaller focus groups that work on parts of the project, and each has its own Slack channel. Don't hesitate to introduce yourself and ask questions, even if your question is, "Am I talking to the right people?"
Some of this is automated; on a new pull request, the Kubernetes bot will add a reviewer, who can then add a SIG label, which will heighten visibility to code owners and reviewers familiar with the material. Existing issues will most likely already have a SIG label.
If you're submitting a new GitHub issue, you may have some difficulty finding the correct people to pitch your idea to. Unlike with pull requests, you are less likely to have someone add a SIG label for you; you must do so yourself with the bot command. Browse the list of SIGs and try to figure out which one is the most relevant. Don't worry too much if you don't know which SIG to pick. In my experience, it is better to get the SIG wrong and have someone relabel it to a different SIG than to leave off labeling altogether, which is a very quick way to get your issue to fall into obscurity.
To add the SIG contributor-experience label to an issue, for instance, type in a comment:
/sig contributor-experienceHurray! Your pull request is finally open.
But wait! There are a few more steps.
You need a Kubernetes organization member to add an /ok-to-test label to your pull request so that the test suite can run. Be patient as you wait for a member to do so.
- Make sure you have a SIG label and follow the bot prompts. If you get stuck, ask.
- Fix issues that come up during testing and review.
- Be courteous and communicative to your reviewers. If your pull request is not getting reviewed, you may ask in Slack or assign another reviewer.
- Once your pull request passes muster, the bot will merge it automatically.
Congratulations! You've made your first upstream contribution. I promise it will get easier with practice.
This article is a lightweight, introductory version of parts of the official Kubernetes Contributor Guide. For a guided tour to becoming a contributor, there are several mentoring tracks as well as new contributor video office hours.
Guinevere Saenger will be presenting at SCaLE16x this year, March 8-11 in Pasadena, California. To attend and get 50% of your ticket, register using promo code OSDC.
1 Comment