KubeCon + CloudNativeCon NA Virtual sponsor guest post from Amanda Katona, Cloud Native Community Engagement Director at VMware
To get into the KubeCon mood, I recently ordered some Boston clam chowder takeout, selected a cozy fireplace Zoom background, and sat down with Nikhita Raghunath and Yuvaraj Balaji Rao Kakaraparthi to better understand how writing a Kubernetes Enhancement Proposal (KEP) actually works to affect change. Nikhita is a Kubernetes Steering Committee member, and Yuvaraj is a new contributor to SIG ContribEx—in other words, together they offer a great combination of perspectives! The approve plugin revamp KEP they are working on will change how pull requests get approved in the Kubernetes project.
The Q&A that follows is geared toward anyone who wants to contribute a feature to the Kubernetes project, but doesn’t necessarily know how to get started. Authoring a KEP is a tall order since it has a wide-ranging impact, goes through extensive review from the community, and requires buy-in from multiple special interest groups (SIGs). Read on to learn how a new contributor got started with writing a KEP that affects the whole Kubernetes project!
For those new to the community, can you describe how the KEP approval process works today? And what is the role of the approval plugin?
Yuvaraj: A KEP is a design proposal required for major technical efforts to improve Kubernetes that touch large sections of the community. Each KEP is owned by a SIG. The KEP starts in a ”provisional” state while the SIG accepts and fleshes it out. Once approved, the KEP moves to an ”implementable” state and development work starts. Finally, after the implementation is reviewed and approved by the owning SIG, the KEP will move to ”implemented” status.
Nikhita: That’s right, and since KEPs can have a broad scope, comprehensive review can take a while! As a KEP author, it is important to collaborate with the community effectively to achieve consensus in a reasonable amount of time. This involves proposing the KEP in SIG meetings and mailing lists, working with SIG members on the design review, and factoring in suggestions. This is where the approve plugin comes in—it’s a GitHub automation tool used to help facilitate this process. It defines and enforces ownership of various components of a huge project like Kubernetes.
Tell us about the Kubernetes Approval Plugin that assigns approvers and reviewers. Why is the approve plugin revamp KEP important for the Kubernetes community?
Yuvaraj: The new updates to the approve plugin we are working on will encourage engagement of more maintainers in the [pull request] (PR) process instead of limiting ourselves to a few. This is another right step towards embracing distributed asynchronous ownership and collaboration, strengthening our community value, “Distribution is better than centralization.”
Nikhita: The current approve plugin in the Kubernetes project does not allow maintainers to selectively choose files for approval. If a maintainer has the power to approve changes broadly, they often feel over-empowered and hesitant to review if they want to seek a second opinion on the PR. Most PRs get languished since such maintainers now have a huge backlog of PRs to approve, and might not have the bandwidth to take a look at them. The new update will fix this problem by allowing maintainers to approve selectively and self-limit their authority, if they choose to do so. This will also help in delegating review to others, effectively growing the pool of reviewers in the community, reducing maintainer burnout, and leading to faster response times on new PRs.
How did you end up working together? And can you talk about the Kubernetes contributor mentoring aspects?
Yuvaraj: I came to know about these efforts by attending the public SIG ContribEx meetings. From the discussions in these meetings, I realized the importance of the approve plugin and volunteered to learn about the current process and improve it. Nikhita, who also was interested in solving these problems, offered to mentor me through the ramp-up and design process.
Nikhita: The Kubernetes community has been discussing revamp of the approval plugin for over two years now. The changes required for it are very nuanced and require big design updates, including writing a KEP. Given how huge the change is, it was clearly going to take a lot of effort. When Yuvaraj reached out to me with an interest in teaming up, it became something we could reasonably tackle together. We ended up brainstorming ideas, creating the design, and then eventually working on a proof-of-concept. We are working through some edge cases right now and will soon share the KEP for broader review.
Apart from such one-on-one mentoring for specific issues, the community has other mentorship programs such as Group Mentoring and New Contributor Workshops. The Kubernetes project also participates in internship-like programs, like Google Summer of Code, Outreachy, and Community Bridge.
What surprised you about working together?
Yuvaraj: I was happily surprised to learn that our collaboration efforts were not affected even though we live on the opposite sides of the globe. Working on this project gave me an opportunity to learn more about the community and its people; for example, Nikhita is probably the only person I know who enjoys using a TrackPoint mouse!
Nikhita: I am amazed at how we managed to break down and then work through such big design changes even though we are in completely different time zones- I am in India and Yuvaraj is in the US. I also enjoyed our Zoom calls, where we talked about books and our shared love for the delicious panipuri.
If you are interested in becoming a Kubernetes contributor, kubernetes.dev is a great place to start your journey. And this GitHub page is a great place to follow along on the enhancements being made to the Kubernetes approve plugin. You can also stay up to date with important Kubernetes contributor news and information via this Twitter account: @K8sContributors. Finally, be sure to check out these useful tips to get the most out of your KubeCon experience.