enhancements
enhancements copied to clipboard
kubernetes
KEP-3344: Add Release Team Roster KEP
- One-line PR description: Add first draft of KEP 3344
- Issue link: https://github.com/kubernetes/enhancements/issues/3344
- Other comments: N/A
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
@JamesLaverack thank you for outlining this! Feel free to ping folks when this is ready for review.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: JamesLaverack
Once this PR has been reviewed and has the lgtm label, please assign saschagrunert for approval by writing /assign @saschagrunert in a comment. For more information see:The Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Okay @saschagrunert @kikisdeliveryservice. I think this is ready for a serious review. :D
Hey @JamesLaverack, any update on this KEP? :)
Hey @saschagrunert. I've been very busy personally over the past few weeks, but I will be able to dedicate time to this over the coming weeks. :) Current plan is to get this merged ahead of ~1.17~ 1.27 in January.
@JamesLaverack awesome, thank you for the update (assuming you mean k8s v1.27)!
@JamesLaverack: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:
| Test name | Commit | Details | Required | Rerun command |
|---|---|---|---|---|
| pull-enhancements-verify | ff10b2230037aa64d72cf55374e3ada8b3609c0c | link | true | /test pull-enhancements-verify |
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.
@saschagrunert I've updated the KEP now, thank you for your patience.
We discussed sending an email to [email protected] about the change to solicit wider feedback. I'd like to do that, but I don't want to confuse people who are waiting on 1.26 shadow survey responses.
My understanding is that the 1.26 survey has closed, and responses are due on the 12th. (cc @palnabarun). Would it be best to send an email about this KEP the day after on Tuesday 13th September?
@JamesLaverack -- by 1.26 shadow survey, do you mean Release Team Shadow Applications for 1.26?
@JamesLaverack -- by
1.26 shadow survey, do you mean Release Team Shadow Applications for 1.26?
Yes that's what I mean. Sorry I wasn't clear.
Sure, then I'm thinking of sending this to [email protected]:
Hi Kubernetes Community,
Every Kubernetes release has a release team, a group contributors who work together to run the 'mechanics' of the release process for that release. SIG Release has overall responsibility for assembling this team for each release.
In order to better meet the needs of returning contributors, SIG Release is consdiering amending the team selection process for future release teams. We'd appreciate review, thoughts, or concerns from the commuity on this change in process. You can find the proposal under KEP-3344 [0], with a draft KEP on this PR [1].
All feedback is welcomed! Thanks,
[0]
https://github.com/kubernetes/enhancements/issues/3344[1]https://github.com/kubernetes/enhancements/pull/3347
Any advice on tigtening up the language here?
I like your text already LGTM :) I rephrased it below just for inspiration if you are not yet sure about your version 🙂
[...]
For each Kubernetes release, sig-release assembles a release team to work on the internal mechanisms for publishing the release. This process has worked well in the past, but with each release we've collected small pieces of feedback, and now we think it's time to bundle all that feedback into a KEP for a slightly bigger change for the release team.
Primarily to better meet the needs of returning contributors. sig-release is considering changing the team selection process by introducing a pool of stable release team members for future release teams.
We'd appreciate review, [...]
[...] I'm thinking of sending this to [email protected]
@JamesLaverack -- please hold any comms about this for @kubernetes/sig-release-leads review of the KEP.
I'm generally -1 for long-standing rosters on the Release Team side, so would like review the content before this goes any wider.
(One of the reasons: staffing has been tough over the last few years) /assign @saschagrunert @cpanato @puerco @jeremyrickard @justaugustus
We discussed this KEP in the SIG Release meeting on Tuesday 11th October 2022, see the notes for the full discussion.
My takeaway from that meeting is that there were a number of people with concerns or who were -1, and a number of people who were ambivilent, but few +1s. As a result I've taken that as a signal that in it's current form it's not worth taking forward.
A few of the concerns raised:
- That contributors may feel pressured into contributing every cycle, or that this is the expectation.
- That there will be fewer slots available for new contributors if a roster is present.
One of my goals with this process was to make it so that 'roster' members could feel safe taking breaks without worrying about "falling off" the release team, and the coditifcation that a team be built from both roster members and new contributors is the same as what we do now. I feel that the term "roster" is perhaps part of the issue, and is setting expectations that I didn't intend. That's not to say that this propsal isn't flawed of course, or that those concerns are purely language based. Purely that the language used isn't helping.
At the meeting there was general agreement that the experience for returning contributors in the release team could be improved, so I think I'm going to take @saschagrunert's advice above and refocus on improving that experience. We already provide a separate flow in the shadow application form for this, but I think more could be done. Given the removal of a 'roster' in this proposal, how can we better facilitate returning members, especially members who take breaks?
After further reflection, I don't think there's support for this more widely in the SIG. I'm closing this for now.