Kubernetes is one of the largest open source projects and an indispensable part of modern cloud native ecosystems. That is why it piqued my interest after learning to involve with its development. And i was searching for way I can contribute to this one of the first instincts someone like me a university student or any other curios person may have is oh i should have mastered Golang and have couple of years or multiple years of experience for that matter and i can just pick up a good first issue and you are off to the races right unfortunately that is far from true that’s what i though it was like.

But some research proved that it is much more beginner friendly than I thought, So i started with kubernetes new contributor orientation that happens every single month since the reason for that I learned is because the information in those sessions expire very quickly for project of caliber of kubernetes.

so the most of the information in those sessions are same like the hierarchy of roles and what SIGs (Special Interest Groups) WGs (Working groups) Sub projects their structure if you watch a recording from one year earlier or some time ago there is a possibility they might have added a another major SIG or working group but most of those rarely change. And starting from there I dove into the rabbit hole. Joining the slack groups subscribing to the mailing lists. and very importantly the calendar that lists the meeting schedule some biweekly and etc.

And the first meeting i have ever joined is node readiness controller project where i observed the members of that project reviewing a pull request explaining it live and anther remarkable thing i noticed is i joined this meeting expecting some healthy number of people joining this meeting since this project recently had listed a project in LFX mentorship. I was expecting to like 100 or so viewers instead the meeting throughout stayed in double digit numbers below 20 to 15 participants.

So i continued on attending meetings I then attended a sig meeting for sig-api-machinery where I witnessed federico bongiovanni the SIG lead for that other tech leads of the projects in that meeting discussing things and one of the best things that could have happened to a aspiring future contributor like me i witnessed them reviewing a first time contribution to kubernetes (How do I know so in the pull request the person who did it had first time contributor in the pull request) and It was interesting since they were talking about CBOR (Concise binary Object Representation) some kind of improvements in that area and the tech leads of the project they decided to hold before going forward with it since the implementation of the protocol in go is not stable enough. And the contributor was redirected by the leads to help the person that is currently doing the implementation of CBOR in go. This is one the insights I gained about their process of thinking when taking decisions about adding features to Kubernetes.

Then I continued and one of the other meetings I joined was SIG-ContribEx and SIG-Instrumentation which came to me as much beginner friendly where in ContribEx where we have a the opportunity as a new member to take down notes of the meeting in the shared Google Doc I did not opt in since I was not really prepared for that and SIG-Instrumentation where I was nearly close to getting assigned something or helping with triaging and prow commands in github page sharing the screen where the person chairing the meeting gave the opportunity to a new comer again I was not prepared for something like that and also they assigned a new comer some issues as well this was not directly on kubernetes but in the SIG Instrumentation metrics server project.

All of these experience turned what I thought I should do when contributing to Kubernetes upside down.

  • Showing up matters
  • When contributing to Kubernetes collaborating with the community is as important as coding.
  • You can write the technically most brilliant PR but you still have to get it merged and see it through review and fix other edge cases and in some cases explain that PR in a meeting as well.
  • You get to identify the currently most active members of the community some names pops up across some SIG meetings when they collaborate.

Contributing to this kind of project is ultimately something you build over time getting the context of the meeting where we are heading with the direction of the project what people are actively working and where we need help from the community building relationships and trust with the community.