Community post originally published on Medium by Maryam Tavakkoli

Kubernetes has become the de facto standard for container orchestration in the cloud-native ecosystem, powering some of the most critical infrastructures worldwide. The Kubernetes release process, which ensures the stability and improvement of the platform, is central to its continued success and evolution. This process is managed by a dedicated and diverse team of contributors from various organizations across the globe. I had the unique opportunity to serve as a shadow on the Kubernetes Release Team, contributing to the release of Kubernetes versions v1.29, v1.30, and v1.31. In this article, I’ll share my experiences across these release cycles, detailing the responsibilities I took on, the challenges I faced, and the invaluable lessons I learned as part of the broader Kubernetes community.

The Release Team and SIG Release

The Kubernetes Release Team operates as part of the Special Interest Group (SIG) Release.

But what exactly is a SIG?

A Special Interest Group (SIG) in the Kubernetes community is a group of contributors who collaborate on specific aspects of the project, ranging from networking to storage to releases. Each SIG is responsible for the ongoing development and maintenance of its focus area, ensuring that Kubernetes continues to evolve and improve.

According to the SIG Release GitHub:

The Kubernetes Release Team is embedded within SIG Release and is responsible for the day-to-day work required to successfully deliver each release. Meanwhile, the broader SIG focuses on the continuous improvement of the release process itself.

Release Team Structure

The Kubernetes Release Team is organized into five sub-teams:

• Enhancements
• CI Signal & Bug Triage (These two sub-teams were merged starting with v1.30)
• Docs
• Release Notes
• Communications

Each sub-team has a specific focus area, which is crucial to the overall release process. Handbooks detailing the responsibilities of both the leads and shadows are available for each sub-team. You can find these handbooks here.

But who is a shadow?!

The Role of Shadows in the Release Process

The shadow program is designed to mentor new contributors, providing them with hands-on experience while ensuring the continuity of the release process. Shadows work closely with their respective leads, gradually taking on more responsibilities as they gain confidence and expertise. This program is vital for cultivating future leaders within the Kubernetes community, ensuring that the release process remains sustainable and inclusive.

My Experience as a Kubernetes Release Team Shadow

I first learned about the Kubernetes release team through a kind friend in the community who shared their positive experience with the program. This is one of the best aspects of being part of such a supportive community — people are always willing to introduce you to new opportunities and help you take your first steps.

Encouraged by this, I applied to join the v1.29 release team and was accepted as a Bug Triage Shadow.

Bug Triage Shadow for v1.29

According to the SIG Release GitHub:

The bug triage team is responsible to make sure that Issues and Pull Requests (PRs) which are targeted for the ongoing release cycle are dealt with in a timely fashion.

Serving as a Bug Triage Shadow for v1.29 was my first experience on the release team, and it highlighted the significance of the community’s role. It was eye-opening to see how the release of the world’s second-largest open-source project is driven by the voluntary collaboration of many dedicated individuals.

Given the relatively light workload for this sub-team, it was decided to merge the Bug Triage team with the CI Signal team since the v1.30 release.

CI Signal Shadow for v1.30

Being one of the CI Signal Shadows for v1.30 was my most challenging role. CI Signal is one of the most time-intensive roles on the release team, and I gained valuable experience during that cycle.

According to the handbook, the CI Signal team’s responsibilities include:

Continuously monitoring various e2e tests in SIG-release dashboards throughout the release cycle.

Providing early and ongoing signals on release and test health to both the Release Team and various SIGs.

Ensuring that all release-blocking tests deliver a clear Go/No-Go signal for the release.

Following the merge of the Bug Triage sub-team into CI Signal, the responsibilities of Bug Triage were also included in this role.

Docs Shadow for v1.31

My experience as a Docs Shadow for v1.31 was generally smooth. The main challenge was ensuring timely communication with developers, and encouraging them to update the documentation alongside their features. This coordination is crucial so that both the feature and its corresponding documentation are ready for release.

According to the handbook, the responsibilities of a Docs Shadow include:

Identifying new Kubernetes features and enhancements (Kubernetes Enhancement Proposals, also referred to as KEPs) that require new documentation and tracking them using the Enhancements Tracking sheet created for the release.

Creating a dev branch used by contributors to target documentation updates for the upcoming release

Key Takeaways and Lessons Learned

Being part of the Kubernetes Release Team has been a rewarding experience, providing both technical and personal growth. I gained hands-on experience across various areas of Kubernetes and deepened my appreciation for community involvement and collaboration in driving open-source projects forward.

For anyone interested in contributing to the CNCF community, I highly recommend participating as a shadow in the release team. It’s a challenging yet incredibly fulfilling way to give back to the community and advance your professional development.

If you’re ready to get involved, now is your chance to join the release team for the upcoming v1.32 release. Fill out the application form here.

You can download the PDF version of the release team structure with clickable links HERE.

Find all my links here.

I would love to hear your thoughts and feedback on this article.
Let’s continue learning, sharing, and evolving together!
Until next time!