As a Kubernetes 1.23 Release Shadow
Meha Bhalodiya
SQE at Red Hat - OpenShift (Performance & Scale) | Kubernetes Release Branch Manager v1.31 & CI Signal Lead v1.28 | ISTQB Certified
Curious to know what it is?
I thought to write on this as I am getting a flood of DMs these days just because the shadow application for the Kubernetes 1.24 Release is now open! To be considered as a shadow on the team, please fill out the application: https://bit.ly/3ywyTlT
The application will remain open until Thursday, December 30, 2021, 6:00 PM PST. They will notify all applicants of their status no later than January 6th, 2022. While the release calendar has not been finalized, the release is planned to start on Monday, January 10th, 2022. The tentative release date for Kubernetes 1.24 is Tuesday, April 19th, 2022. Please keep these dates in mind when you consider your availability and the time commitments.
Okay, so after going through quick updates, let’s have a look at what’s inside the Kubernetes Release!
First things first…
What is Kubernetes Release Team?
Every new release cycle has a new Kubernetes Release Team, comprised of community members who handle different responsibilities and the logistics of the release itself. The team roles are divided into:
Each role has a Lead and several shadows (generally around 3 to 5), who are mentored by the Leads. We attend Release team meetings and have a kind of discussion of the Release Team Selection Process.
If you may also want to take a quick look at the 1.23 Release README: github.com/kubernetes/sig-release/blob/master/releases/release-1.23/README.md
When it comes to contributing and reviewing PRs, you should check out the docs style guide: kubernetes.io/docs/contribute/style/style-guide/
Shadow Experience
Honored to be a part of the KUBERNETES organization. As always, they have a lot of candidates (185 applicants for approximately 26 shadow roles — more than any previous release) who apply to shadow the Release Team.
As someone who started as a shadow on the Docs team for the 1.23 Release Team, I want to share what I’ve learned from this journey and answer any questions you may have about the Release Team.
However, since I’ve only been involved on the Documentation side, I have asked some of my colleagues who have been involved in other release team roles to share more about their experiences!
Regarding the Enhancement role, the role & responsibilities are pretty much same to what you see in documentation role. Just the timelines of active work & responsibilities are different.
Enhancements folks start fairly very early in the release cycle (like during week 0–3) to start tracking & shepherding the enhancements who have opted for the current release in question. This all happens in the release tracking sheet (same as the one for docs you see). And the comms happen mostly in the enhancements KEP issues or slack channels.
So, the enhancements role does this work of tracking during the timelines of the soft PRR deadline & the Enhancements Freeze deadline. Followed by that, Enhancements folks are fairly free unless there are exception requests coming in for the KEPs which couldn’t make in the release, due to any reasons.
Enhancements folks come active again then in the final weeks of release to check if the ones who opted actually had the code implementation in place & all PRs are merged or not & do the cleaning of the sheet once again.
- Priyanka Saggu, MTS-3 at VMware TKG
From CI Signal Shadow,
My work mostly involved looking at the testgrid and reporting any failures/flakes by creating issues for them. Other than that you could also chose to work on the ci-signal report tool — github.com/kubernetes/release/tree/master/cmd/ci-reporter
- Arsh Sharma, Ex-MTS at VMware
What responsibilities are there?
Most of my work revolves around tracking Pull Request — PRs (keeping them up-to-date in the tracking sheet, compared to the state of PRs), as well as helping to review for style and content where we can, & ensuring all requirements are met before merge on the dev-1.23 integration branch. In addition, I review PRs (English localization) to the kubernetes/website repository, take on larger projects like section reorganization and rewriting.
K8s 1.23 Enhancements/Docs Tracking sheet: https://docs.google.com/spreadsheets/d/1P1J1QpayRmh2SNjs8T-wBCb6SgEOdWTRQ7MBol7yibk/
Also, there are meetings held, which are quite flexible to attend according to the time zones. It’s all right if you didn’t make it to few. It’s just for giving the status on behalf of the whole team. I identified 3 meetings:
领英推荐
Meeting Notes: docs.google.com/document/
By covering the meetings, you get to learn volunteering skills. Especially to me, it was satisfying to speak in front of leaders/developers. I recommend you should attend once a week up until burndown when meetings happen every day for the last two weeks leading up to the release.
Beyond that, l learned about the different modes of communications the community utilizes, experienced the process of publishing Kubernetes blog posts, saw the dependencies that exist between all the teams working together to get a release out, and met a ton of people in the community who make things happen behind the scenes.
What is the time commitment one would need in the whole process?
Each team has sort of different starting lines, and times when they are super busy. So, even though you aren’t working yet, you haven’t missed anything… and you will be working soon!
It took me a maximum of 2 hours a week. Two weeks before the code freeze is the most busy time for us. I spent more time tracking several GitHub issues such as this one and contacted issue-related people in slack if they didn’t answer me in Github.
- Xinyuan Cai, Bug Triage Shadow
What comes after shadowing?
That’s up to you! Some people choose to explore other roles, some shadow again to better prepare themselves to eventually become a Lead (that’s what I am planning), and some jump straight into becoming a Role Lead in the next cycle!
Learn from and give back to the community
Many thanks to Jesse Butler, a Senior Developer Advocate at AWS for leading the 1.23 Release Docs team! He is the one who has done all the heavy lifting to keep up with deadlines to get the most complicated part of the Release (the end game) done!
Please refer to the following links for information on the Release Team and selection process:
Further details on the 1.24 release team can be found in the following issue: kubernetes/sig-release/issues/1768
Please reach out via the #sig-release channel on Kubernetes Slack, if you have any further questions.
The unasked gift I got!
SIG Docs will definitely get to reviewing your PR — we have a backlog. This is a good thing because it means there are lots of people contributing, but it’s also a challenge to find enough people willing to be reviewers.
Outside of your role in connection with the Release, would be interested in becoming a SIG Docs reviewer long-term?
- Documentartian of Kubernetes
I received this when I was requesting a review on my PR!
Finally, I am now a SIG Docs Member. Cheers!