At KubeCon + CloudNativeCon China 2019, held in Shanghai and attended by over 3500 attendees, the major talk was about the pace of growth of the Kubernetes community and discussions were focused on how to contribute to the community.

In addition to talks by the local Chinese community, many of the event’s presentations touched on the staggering numbers that the Kubernetes community has managed to collect in a relatively short amount of time. Lots of the hallway conversations with developers were focused on how contributions can be made in some form to the community, as the feeling of merely being part of the community was not enough. The Cloud Native Computing Foundation published some stats recently that track the Kubernetes journey which is the foundation’s largest hosted project.

InfoQ caught up with Nikhita Raghunath, a contributor to the Kubernetes community. She is also a CNCF Ambassador and the technical lead for SIG Contributor Experience.

Raghunath begins the discussion by outlining her first contribution, and although it initially appeared to be an intimidating experience her fears were eased by her interactions with the community. She also talks about the organization of the community, and outlined some of the tools in the contributors aresenal with a key goal of enabling a better understanding to the reader of how and where to contribute.

Although people can read the detailed Contributor Guide for a comprehensive how-to, Raghunath outlined several quick tips and tricks that are especially focused on the impatient contributors who are keen to get started and to move up the contributor ladder.

InfoQ: Welcome to InfoQ. Can you start by highlighting your first contribution, please. How did you plan this, how long did it take and any lessons learned?

Raghunath: When I was in college, I noticed that Kubernetes was participating in the Google Summer of Code (GSoC) internship program. GSoC is a four month paid internship program where students can work on open source projects. As part of my GSoC application, I decided to work a bug related to incorrect marshaling of integers in CRDs (called TPRs back then). I wasn’t really familiar with how TPRs worked internally, so I decided to first read the design proposal related to it. Once I got a fair idea about it, I then moved onto understand how Kubernetes did JSON serialization and deserialization. To be honest, understanding this from scratch was a little intimidating. I looked at existing issues, grepped the codebase for terms related to it and asked numerous questions in the SIG API Machinery slack channel. After this, I finally created a PR and it got merged!

The whole process took me about a week, with a couple of hours of work each day. I remember being confused about how the whole GitHub automation worked and I was afraid that I’d be asking really silly questions in Slack. Looking back, I realize how my fears were unfounded because everyone was really kind and patient while answering. This was in 2017 and we have come a long way in terms of contributor-facing documentation since then. There are docs explaining the automation and videos about code-base tours. My biggest suggestion would be not shy away from asking questions and show up on slack and (if possible) meetings so that other contributors see that you are active and know who you are. This also helps while taking up/delegating new tasks and moving up the contribution ladder to a reviewer.

InfoQ: Can you offer any tips on how to get started with contributing, especially those that are impatient and don’t want to read the contributor guide from cover to cover?

Raghunath: We have a cheatsheet (in eight languages) for this very reason! 🙂

Apart from the cheatsheet, here are some practical tips:

• Start with lurking in SIG slack channels and meetings! It removes any added pressure about introducing yourself or contributing from the beginning. It would also prove beneficial in understanding the community conventions and the current tasks the SIG is working on. The contributor calendar contains information about all SIG meetings. In case you are not able to attend a meeting, meeting notes can be helpful in getting a quick rundown.
• Kubernetes uses Prow for CI/CD and GitHub automation in the form of “slash commands”. When you create a PR, you might see bots adding certain labels and comments and even asking you to run certain commands. Understanding this automation is crucial to make sure that your PR gets adequate attention from reviewers and is merged quickly. The command help page gives a handy overview of all commands including examples on how to use them.
• To find an issue to work on, you can look for issues having the `good-first-issue` or the `help-wanted` labels. Apart from these, fixing lint, shellcheck or static check errors are good places to start diving in with code contributions since they don’t require a lot of familiarity with the codebase.
• For an overview of the kubernetes/kubernetes repo, you can checkout the codebase tour. If you’d like to have a codebase tour of specific repos, you can also ask about them in the Meet Our Contributors sessions. Running a `git blame` on a particular file can point you to the specific commit/PR that led to the change. This is very helpful since PRs contain a lot of additional context and discussions.
• If you are looking for specific mentorship and are willing to contribute a certain number of hours per week, consider “shadowing” on the release team. Shadows get mentored by leads, and can even step up to become leads in future release cycles!

InfoQ: Is it significantly easier to contribute to the Kubernetes docs than to an actual Kubernetes code repository? Can you provide some comparisons of contributing to docs versus contributing to code repositories?

Raghunath: I believe this is more nuanced. Fixing typos in documentation are easier for sure, but doc contributions extend far beyond that. Expressing technical concepts in clear, concise and unambiguous terms such that it’s easily understandable by people with all levels of technical background is tricky to get right.

One of the tasks actively being worked on by SIG Docs right now is localization to different languages. While this might seem easier on the surface, it is much more strenuous. Localization goes one step beyond just translation and requires that all concepts be adapted to convey a similar connotation in the target language, while still maintaining the original meaning. Implementing this in practice requires careful review and a vast understanding of the technical concepts and the language.

Let’s compare this with code changes like fixing lint, shellcheck or static check errors. Fixing these involve running a script, which then outputs failures containing exact reasons for the errors. Since the reasons are already known (most of the times, the reasons also contain suggestions on the required changes), it is easier to fix them. Moreover, fixing these errors don’t particularly require an immense knowledge about technical Kubernetes concepts.

InfoQ: If I know how to issue a Pull Request (PRs) on GitHub, what else do I need to know from a technical perspective before I can start contributing code to code repositories?

Raghunath: Firstly, you will need to setup your development environment. Depending on the repository you are contributing to, you might need to run additional commands as well. The CONTRIBUTING.md file at the root of the repo would be a good place to find more information about these. Once you make changes to the code, it is important to split the changes into logical series of smaller commits. One quick tip is to have any generated code in a separate commit since this makes reviewing the changes easier.

While we don’t impose any specific restrictions on commit message style, adhering to good commit message practices is always helpful. Note that certain repos might also impose additional restrictions like disallowing merge commits or keywords in commit messages. After creating the PR, you will notice bots adding labels and comments to your PR. Understanding the GitHub automation and slash commands as mentioned above will help in interacting with bots easier. Here are some commands that are commonly used:

• Apply the SIG label by adding a comment /sig cli. This will make sure that your PR is surfaced to SIG CLI reviewers.
• Writing /cc @username will request reviews and /assign @username will assign a particular person to your PR.
• /retest will automatically retest any failed tests on your PRs. This is especially handy in case your PR encounters any flakes.
• And the most important command: /meow and /woof will make the bot comment with a cat and dog picture!

After your PR looks good to the reviewer, they will add the “lgtm” (looks good to me) and “approved” labels to your PR using the /lgtm and /approve commands. Once your PR has these labels, it will get automatically merged by the bot.

InfoQ: Are there any particular Kubernetes communities that are more amenable for making contributions? In contrast, which ones are more challenging to contribute to?

Raghunath: There are certain tricky bugs like scalability failures or flaky tests that are harder to debug and fix but in my opinion, it is not possible to label a particular repo as harder to contribute to with a blanket statement. Having said this, many people equate contributing to Kubernetes as contributing to the core kubernetes/kubernetes repo. But this is far from the truth. There are many other subprojects and repos in the `kubernetes-sigs`, `kuberentes-client` and the `kubernetes-csi` GitHub orgs as well. All of these repos are incredibly important and generally have a smaller set of folks working on them. Working on these subprojects is “easier” in the sense that you can have greater interactions with the maintainers and have quicker review response times.

InfoQ: Besides the satisfaction of contributing code to open source, are there other rewards to contributing code in the Kubernetes community?

Raghunath: Code was the initial aspect that attracted me, but I stayed even after my internship and continued contributing because of the community. “Come for the code, stay for the people” definitely resonates with me. I made countless friends from various parts of the world, and while many of them work at different companies, we still get to work together and learn from each other.

Personally, the biggest reward for me was that a lot of doors opened for me while I was hunting for jobs. Several contributors have also switched jobs, and yet continue to work on Kubernetes same as before. This helps in individual growth and also makes the project succeed long-term.

And of course, there are other rewards like the Kubernetes contributor patch, a chance to attend the Kubernetes Contributor Summit (co-located with KubeCons) and a big stash of Kuberentes-related swag!

In summary, although there a number of steps and processes associated with contributing to the Kubernetes community, understanding and following the guidance outlined above may reduce some of the intimidation factor, and make contributing to the community a lot easier.