If you, too, have been looking to make your first-ever open source contribution, GitHub<\/a> makes it easy to take the all-important first step of finding a beginner-friendly contrib opportunity. Look for issues marked good first issue<\/a> or help wanted<\/a>, and don\u2019t forget to look at other projects<\/a> in the Kubernetes organization.<\/p>\n If you\u2019re still not sure how you can start contributing to Kubernetes, you can glean a lot of insight from a project\u2019s test suite. Writing tests for existing functionality can help you find your bearings in a new codebase, and the maintainers will love you for it. Another option with a fairly low barrier to entry is contributing to Kubernetes documentation \u2013 there is even a whole website<\/a> devoted to helping you get started doing just this. Again, the maintainers will love you for it.<\/p>\n In my case, I found an issue looking to add tests to ensure protobuf<\/a> doesn\u2019t break their API. That way, the maintainers can upgrade the protobuf dependency as needed without triggering any unpleasant surprises. A nice side effect of choosing this issue, in particular, was learning more about protobuf. Prior to starting, I knew what protobuf was, and even how to use it, but I had no idea how it actually worked. Protobuf internals are beyond the scope of this article, so here\u2019s a link to a comprehensive overview<\/a>.<\/p>\n Once I decided what issue I was going to work on, I cloned the repo and started looking through the code. Kubernetes, for better or for worse, contains nearly 4,000,000 lines of code spread out across more than 13,000 files. Navigating a codebase this large can be daunting, to say the least, so diving in without a plan is definitely not advised.<\/p>\n One thing that can greatly narrow your search domain is identifying which packages or libraries you\u2019ll need to dig into to accomplish your goals. My patch, for example, targets the apimachinery<\/b> library. That cuts it down to around 60kloc across ~330 files. Now we\u2019re getting somewhere!<\/p>\n Once you know where to look, a good understanding of how to search the source with tools like find<\/b> and ack<\/b> will be an invaluable asset, so it pays to brush up on their usage (the Linux man pages<\/a> are a great place to start). You should ultimately be able to focus your attention on, at most, a handful of files.<\/p>\n The next step is to actually write your code. In my case, that meant adding a few tests to an existing file. If your patch is much larger in scope, then you should probably put it on hold, and find something smaller. It\u2019s no fun to spend weeks writing something you\u2019re proud of, only to have it rejected right off the bat.<\/p>\n I can\u2019t provide much more guidance when it comes to writing your first patch. since every issue is unique. Hopefully, you didn\u2019t bite off more than you could chew. Once you\u2019re happy with your code and\/or documentation, it\u2019s time to submit your pull request. That can be a rather stressful experience for the uninitiated, and if you\u2019re not used to very direct feedback, it can be hurt. Try not to take things too personally.<\/p>\n To minimize the pain, it\u2019s a good idea to make sure your contribution is consistent with the existing codebase, and\/or Documentation Style Guide<\/a>. Also, make sure your git history is clean, by squashing and rebasing your working commits and checking the diffs against the latest master.<\/p>\n Before your patch can be reviewed, you will have to sign the CNCF Contributor License Agreement<\/a>, which grants the Cloud Native Computing Foundation<\/a> additional rights and limitations not covered under the Apache-2.0<\/a> license that accompanies the project. While the CLA requirement definitely merits further discussion, this article is not the place to do it.<\/p>\n Once you\u2019ve signed the CLA, make sure you read and follow the pull request template<\/a>. In the same vein, you should pay special attention to the format and content of your commit message. Make sure that the message is clear and concise, and that it conveys the purpose of your changes\/additions. If you\u2019re not sure what format to use, I\u2019m quite fond of:<\/p>\n topic: subtopic: Concise description of your patch here apimachinery: protobuf: Test protobuf compatibility<\/p>\n Now comes the hard part; waiting for review. Kubernetes is one of the most active projects on GitHub, and currently has over 1000 open pull requests<\/a>, so it shouldn\u2019t come as a surprise that you might have to wait a while before you get any feedback.<\/p>\n First, someone from the Kubernetes organization will triage your patch, and assign it to a suitable reviewer. If that person deems it safe, they will trigger the tests and review your code for style, correctness, and utility. You will probably need to make some changes, unless your patch is tiny and you\u2019re a rock-star. Finally, once they\u2019re happy with your patch, they\u2019ll flag it with a \u2018\/LGTM\u2019 message, and it will be automatically merged into Kubernetes\u2019 master branch.<\/p>\n Congratulations, you\u2019re now part of the CNCF\/Kubernetes developer community! That wasn\u2019t so bad, was it? Feel free to share your thoughts in the comments below, and ping me here or on Twitter<\/a> if you have any questions or comments.<\/p>\n![\"Contributing](\"http:\/\/container-solutions.com\/content\/uploads\/2019\/02\/maximilian-weisbecker-121294-unsplash-1024x684.jpg\")
<\/a><\/p>\nFirst Steps<\/h3>\n
Diving In<\/h3>\n
Do Your Thing<\/h3>\n
Read The Fine Print<\/h3>\n
\nFor example, the commit message for my patch was:<\/p>\nWait For It\u2026<\/h3>\n