KEP-3344: Add Release Team Roster KEP #3347
Conversation
JamesLaverack
commented
Jun 7, 2022
JamesLaverack
commented
- One-line PR description: Add first draft of KEP 3344
- Issue link: Release Team Roster #3344
- Other comments: N/A
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
do-not-merge/work-in-progress
k8s-ci-robot
added
kind/kep
|
/assign |
|
@JamesLaverack thank you for outlining this! Feel free to ping folks when this is ready for review. |
There was a problem hiding this comment.
Minor comments on the draft. This is awesome @JamesLaverack ❤️
| - The release team having some degree of 'churn' is natural and expected. | ||
| An entirely static, or effectively static, team is not desirable. | ||
|
|
||
| Balancing these desires, this KEP introduces a stable |
There was a problem hiding this comment.
I think this sentence needs an ending? ;)
There was a problem hiding this comment.
I just replaced the whole sentance. I don't know what thought I was half way though. 😂
| - when the KEP was retired or superseded | ||
| --> | ||
|
|
||
| ## Drawbacks |
There was a problem hiding this comment.
Probably this section should be filled out eventually.
There was a problem hiding this comment.
I've added a few obvious ones. More are welcome!
| Not applicable. | ||
|
|
||
| ### Graduation Criteria | ||
|
|
There was a problem hiding this comment.
This is essentially a straight to GA process change right?
There was a problem hiding this comment.
Good point. I agree. I've updated it.
I don't think there's any way to do an alpha/beta of this.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: JamesLaverack The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
Okay @saschagrunert @kikisdeliveryservice. I think this is ready for a serious review. :D |
| An entirely static, or effectively static, team is not desirable. | ||
|
|
||
| Balancing these desires, this KEP introduces a long-lived "roster" of release team members. | ||
| This roster is used to assemble release teams instead of a new shadow survey each time. |
There was a problem hiding this comment.
I think we should not replace the shadow survey for new folks who wanna join, so let's clarify:
| This roster is used to assemble release teams instead of a new shadow survey each time. | |
| This roster is used to assemble release teams with recurring contributors in addition to the shadow survey for new folks. |
| ### Release Team Roster | ||
|
|
||
| We will add to SIG Release a "Release Team Roster". | ||
| The list of roster members will be maintained in a YAML file in https://github.com/kubernetes/sig-release under a new `release-team/roster` directory. |
There was a problem hiding this comment.
I'd say we keep to k8s.io and add it as yaml like this: https://github.com/kubernetes/k8s.io/blob/c4b73a3e677f83091a2ab939b289d2f84aad9ff7/groups/sig-release/groups.yaml#L307-L363
|
|
||
| We will add to SIG Release a "Release Team Roster". | ||
| The list of roster members will be maintained in a YAML file in https://github.com/kubernetes/sig-release under a new `release-team/roster` directory. | ||
| People on the roster can be in one of three roles: Shadow, Member, or Emeritus. |
There was a problem hiding this comment.
How about keeping the shadows as-is and only use "Member" or "Emeritus"? This way shadows can join the roster after a cycle, which provides a contributor ladder.
|
|
||
| ### Shadow Survey | ||
|
|
||
| The per-release shadow selection survey will be replaced with a rolling "expression of interest" form. |
There was a problem hiding this comment.
I think we should do both: Selecting new shadows and re-evaluating the existing roster. This makes it easier for new contributors to join because the folks from the roster will not use the shadow form any more.
| People on the roster can be in one of three roles: Shadow, Member, or Emeritus. | ||
|
|
||
| At the time of creation, all former role leads or release leads from any release will be added as emeritus members, or a member if they want. | ||
| The 1.25 EA will lead discussions around which shadows from 1.25 should be placed at the member or shadow level on the release team roster. |
There was a problem hiding this comment.
nit: let's avoid building language barriers:
| The 1.25 EA will lead discussions around which shadows from 1.25 should be placed at the member or shadow level on the release team roster. | |
| The 1.25 Emeritus Advisor (EA) will lead discussions around which shadows from 1.25 should be placed at the member or shadow level on the release team roster. |
JamesLaverack
changed the title
|
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 |
|
@JamesLaverack awesome, thank you for the update (assuming you mean k8s v1.27)! |
|
@JamesLaverack: The following test failed, say
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 dev@kubernetes.io 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 |
Yes that's what I mean. Sorry I wasn't clear. |
|
No worries. It's closed already. The last date was 2nd September. |
|
Sure, then I'm thinking of sending this to dev@kubernetes.io:
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 🙂
|
@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) |
| - Continue to provide an "on ramp" for new community members. | ||
| - Provide a more streamlined process for release team shadows, including easier return into future release teams. | ||
| - Provide a "stable" position that a member may continue to be on release teams if they wish. | ||
| - Better handle contributors who wish to take breaks from the team, and then return. |
There was a problem hiding this comment.
If @kubernetes/sig-release-leads are -1 on the stable roster, then we could also refocus the KEP to:
| - Continue to provide an "on ramp" for new community members. | |
| - Provide a more streamlined process for release team shadows, including easier return into future release teams. | |
| - Provide a "stable" position that a member may continue to be on release teams if they wish. | |
| - Better handle contributors who wish to take breaks from the team, and then return. | |
| - Continue to provide an "on ramp" for new community members. | |
| - Provide a more streamlined process for release team shadows, including easier return into future release teams. | |
| - Better handle contributors who wish to take breaks from the team, and then return. |
|
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:
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. |
