Are you happy in joining the open source software Kubernetes community? This blog post seeks to help clear up any confusion about contributing to a large open source project. It also sharing some personal stories to give you an idea with an open source project like Kubernetes may entail.
I hope that by sharing my experience as a contributor, I will motivate you to start your own journey as an open source contributor. Whatever your background or level of experience, you can contribute to Kubernetes. The open source community values and depends on everyone’s contributions.
I describe my experience as a contributor here, along with the essential steps anyone can follow.
Read More: Easy Steps and Tips to Hire Node.js developer.
Why did I start making Kubernetes contributions?
There are many ways to contribute to an open source project like Kubernetes, including sending in code pull requests (PRs), updating the documentation, handling issues, reporting bugs, enhancing tests, reviewing code, considering Kubernetes Enhancement Proposals (KEPs), and taking part in release management.
Thanks to the countless hours put in by existing contributors and upcoming contributors like you, Kubernetes is alive and well today.
When I was requested to create a trade study on methods my employer could use to containerize our services and manage them with a container orchestrator, that’s when I first learned about Kubernetes.
Writing the code for anything is the only way to gain expertise with it, which is how I became engaged with Kubernetes and why it’s so beneficial for others to do the same.
Also read: Laravel 9 blade template cheat sheet.
How can a novice contribute to Kubernetes?
Here are a few preliminary actions to start making contributions to Kubernetes.
1. Search for available contributors’ documentation that is pertinent.
As a new contributor to any open source project, you should typically seek for any pertinent contributor documentation.
Typically, a CONTRIBUTING.md file or something similar is used for this. Another acceptable starting point is the README located at the root of a repository. This information should be readily available to new contributors to any project that aims to build a community of contributors.
The channels of communication employed by the developers on that specific project or sub-project should also be taken into account.
For instance, Kubernetes primarily relies on Slack and mailing lists; join the slack channels and email lists that most appeal to you, particularly for the parts of Kubernetes to which you intend to contribute.
I skipped right to the CONTRIBUTING.md file because I am a complete newcomer to Kubernetes in general and have never contributed to the Kubernetes project. It is extensively documented, and it immediately directed me to the documents I needed to set up my environment and start developing.
2. Look up topics that interest you and refine your results.
Finding problems to work on: After setting up your development environment, you should look for a problem to work on. I looked at the issues in the Kubernetes repo when I initially started, after setting up my setup. In GitHub, there is a filtering label that can be used to filter for “good first problem,” which denotes that the issue can be worked on by a beginner, when you search for issues for a specific project.
Making repairs for the problems you discover: When you discover a problem, you should inform the maintainers that you want to fix it. I started by requesting permission to work on the issue I had discovered, which was a PR to eliminate all extra new lines being supplied to Logf() routines.
This required going through the code in test/e2e and test/e2e node, looking for newline repetitions in Logf() calls, and eliminating them. Since I had to make the changes locally, submit a PR against the main branch, and respond to review comments, this task served as a useful practise for contributing to the Kubernetes codebase.
It was crucial to seek clarification on any feedback I didn’t understand throughout the process. For instance, I didn’t know what an offender was, thus the term “identify and remedy offenders” confused me. But after I asked, I received a brief response explaining that it simply meant to eliminate all trailing lines from the entire e2e code.
Communication is essential: To produce open source software, communication is crucial throughout the contribution process. Ask inquiries if you are having trouble with a PR, are unsure about how to handle criticism, or don’t understand the reasoning. When it comes to contributing, it’s vital to communicate frequently, particularly when you need to take a break from the project.
Feel free to spend as much time as you need to complete these “excellent first issues” (unless otherwise specified), but make sure to keep everyone updated on your progress on the GitHub issue and enlist additional assistance as necessary. If you find that you are no longer able to work on it, let the relevant problem know and someone else will take it over.
3. Having trouble identifying problems? Try assuming the role of a Kubernetes release shadow.
In addition to submitting code changes, updating the documentation is another way to contribute to an open source project. This is how many new contributors join these projects.
This allowed me to collaborate with several KEP authors and offered me a great deal of insight into the process. I wholeheartedly endorse this route for anyone trying to make a bigger influence in the Kubernetes community.
Typical roadblocks in the way of becoming a Kubernetes contributor.
Getting your first code contribution in is the biggest challenge. Because there are so many daily contributions and so few reviewers, some PRs may languish for weeks or even longer. Making sure you are just donating code that is genuinely the best method to handle this.
1. Making code contributions without working with the community.
A project’s maintainers are only able to hold and accomplish so much context. Making your PR as reviewable as you can is your responsibility as a contributor.
Give your PRs smart, well-written descriptions. If there needs to be more than one PR for a significant change. Make sure there is consensus on the change.
2. Not contributing in an honourable or devout manner.
I view ego as another barrier among new contributors. The majority of the time, a problem that is novel to you is not novel to others. Thus it is crucial to respect their opinions and carry on a courteous conversation. When coming up with or revising your solution to the problem you’re trying to solve. If someone requests an update and you don’t agree with it. Ask them to clarify their comments until you both are happy with the result.
The beauty of open source is the capacity for teamwork and product iterations. That result in a net gain for the project. Do not take things personally and keep in mind that we are all on the same team!
Recap: Beginner’s guide to contributing to the Kubernetes open source project
- Look for a “excellent beginning issue” marked issue to start working on right away.
- Just keep in mind that communication is good.
- Finish the assignment in a constructive manner.
- Just as you would have wished when you first started out, assist others along the way.
