Some thoughts from SIG PM on Code Freeze day

[Stephen Augustus]

T'was the night before code freeze and all through the repos
Kubies were diligently merging code, so we could give to the peoples.

I wrote that masterpiece last night, but it's morning now.

Code Freeze day is here. Please be sure to review Claire's email for action items: https://groups.google.com/d/topic/kubernetes-dev/kYhmnwkgWv0/discussion

---

Over the past few months and during KubeCon, we've had the opportunity to have some wonderful conversations about improvements in SIG PM and SIG Release and I'd like to (hopefully, briefly) summarize some of that here. Much of this is a call to action for contributors and SIG Chairs/Technical Leads as we move into the next release cycle.

One of the best, recent threads about this was started by Tim Hockin called "Deadlines are horrible"[1]. 

Take a moment to dive into that one and add your thoughts when you have a chance.

Some high-level takeaways:

Increasing reviewers/approvers across subprojects, KEPs, and API reviews

Top-level reviewers/approvers are in general bandwidth-constrained, increasingly so as release deadlines approach.

SIG Chairs/Tech Leads/Subproject Owners: Take some time to promote contributors who have been consistently providing PR reviews. This extends to OWNERS files in your subproject repos, as well as in k/enhancements for your KEPs.

Contributors: Discuss becoming a reviewer/approver/subproject owner[2] with your SIG Chairs/Tech Leads/Subproject Owners.

Issue triage is burdensome

We're discussing ways to make it easier to triage issues[3], starting in k/k, which hopefully we can start to roll out during the 1.16 cycle.

If you have thoughts on this, please comment on the workflow proposed in the k/community issue[4].

KEP bikeshedding

Remember the name of the game is: merge early, iterate often.

There are multiple (68) KEP PRs[5] open, some of which have been open since December. Several of them are marked as provisional, which means they should be merged if the SIG believes in the general motivation, goals, and non-goals of the enhancement.

Each SIG needs to work on draining this queue as we move into 1.16.

Would it be helpful to have an "Open Questions" section of the KEP, which would allow us to capture the feedback that we need to iterate over for each enhancement?

Deadlines are horrible

SIGs feel obligated to completely review all KEPs by the Enhancements Freeze, instead of just the ones targeted for the current milestone.

There was some talk about pushing Enhancements Freeze, but understand that having some dates in place allows the Release Team the breathing room they need to do high-quality work.

Instead, I'd like SIGs to consider planning events.

SIG Planning Events

Create a project board[6]. Add KEPs to that board. Schedule a time in each cycle to review the open enhancements and prioritize what's important. 

I send this email now, because I think Code Freeze is an excellent time to do planning for the next cycle. 

Assign a KEPherd (KEP shepherd) to individual enhancements to ensure that there's at least one person helping move an enhancement forward during the cycle.

Consider integrating walking the project board(s) into the first part of your SIG/subproject meetings to ensure contributors stay aligned throughout the cycle.

KEP reviews != API reviews

Some may feel that their experiences are not sufficient to do reviews. 

Remember that as a SIG Chair/Technical Lead, you should feel empowered to do reviews and approvals for the KEPs coming in to your SIG.

As a SIG contributor, you should not feel shy about commenting/reviewing if you have opinions on an enhancement.

Remember that API reviews[7] are not the same as KEP reviews. 

A KEP may describe an enhancement that will eventually require an API review, but we should not block the merge of a KEP on an API review.

API reviewers

Yet another note on becoming an API reviewer.

If this is something you're interested in, please take some time to take a look at the process[8].

Removing friction from KEP submission

Some of this is covered above, but SIG PM is dedicated to making the KEP ubiquitous across SIGs, easy to use and consume, and maybe even fun!

Open issues on KEP implementation are available on the KEP Implementation Tracking board[9]. Please feel free to comment on any on those issues.

Release Calendar

There were some requests to get notifications about key release dates. We currently create a per-release calendar, but we realize that may not be as visible as it needs to be.

I'm planning on creating a Kubernetes Releases calendar, which will span all release cycles moving forward. Stay tuned to the tracking issue[10] for more details.

Visibility on inbound KEPs

It's still tricky to quickly get visibility on open and merged KEPs. 

We're working on ideas for a website that will do just that. Expect to see something within the next two months. Feedback welcomed on the tracking issue[11].

Dealing with KubeCon

We shortened the release cycle to get around some of this for 1.15, but several people expressed frustration that KubeCons have been stacked close together, which means their review capacity and general availability drops to zero in the weeks leading up to the event.

I'm not sure exactly how to make this better, but I'm throwing it out there as a point of discussion.

KEPtrospective

It would be nice to have a KEP therapy session to talk a little bit about what has and hasn't worked for SIGs as they've approached KEPs. 

I've had a tricky time figuring out when to schedule this, given the KubeCon and release activity, but if it's something people are interested in, I can direct more attention to it, once travel schedules die down a little.

KEP Office Hours

This would be an additional future SIG PM subproject meeting. If you have questions like, "Why is my KEP stuck?", "Who should I go to review this KEP?", "I write a bunch of KEPs and I think it would be beneficial if we _____", then this will be the meeting for you.

Same thing here with the travel schedules. I'll get something recurring in the books during the 1.16 cycle.

1.15 Release Retro

If you have opinions on what we can be doing better on the Release Team, please drop some notes in the 1.15 Release Retrospective doc[12].

More details on the retrospective as we move closer to the end of the 1.15 cycle.

Finally, some ideas that came up across threads that we may not action on, but I'll just bullet point here:

• Live, full KEP readout in SIG Architecture
• KEP Risk/Priority/Voting
• Master KEP tracking board
• KEP review calendar
• Change budgets for SIGs

Thanks to everyone who contributed to these discussions and everyone responsible for moving the needle forward on this cornucopia of priorities.

As always, my virtual door is open to chat about all of this. @justaugustus on GitHub/Slack and @stephenaugustus on Twitter.

-- Stephen Augustus // Kubernetes Product Management Chair

[1] https://groups.google.com/d/topic/kubernetes-sig-pm/3bOMguYeN-0/discussion

[2] https://github.com/kubernetes/community/blob/master/community-membership.md#community-membership

[3] https://groups.google.com/d/topic/kubernetes-sig-contribex/BvGmOQ0v5f0/discussion

[4] https://github.com/kubernetes/community/issues/3456#issuecomment-496039993

[5] https://github.com/kubernetes/enhancements/pulls?q=is%3Aopen+is%3Apr+label%3Akind%2Fkep

[6] https://github.com/orgs/kubernetes/projects

[7] https://github.com/kubernetes/community/blob/master/sig-architecture/api-review-process.md

[8] https://github.com/kubernetes/community/blob/master/sig-architecture/api-review-process.md#expanding-the-reviewer-and-approver-pool

[9] https://github.com/orgs/kubernetes/projects/5

[10] https://github.com/kubernetes/sig-release/issues/617

[11] https://github.com/kubernetes/community/issues/1819

[12] https://docs.google.com/document/d/1Re80f4qICEKLEhOEIFuzr0IZTp2es82urMi45PrScLM/edit?usp=sharing