Revisit/refine policies on the upper bound of release team shadows per role

[justaugustus]

What would you like to be added:

From https://github.com/kubernetes/sig-release/blob/master/release-team/release-team-selection.md:

Every Release Team role should seek to accommodate a set of role shadows. This creates a new avenue for code and non-code contributors alike to contribute to the project. Additionally, it seeds future release cycles with new leaders.

While there isn't a strict restriction on the amount of shadows, we've found three shadows per role to be a reasonable upper bound. However, as shadowing is intended to be a mentor / mentee journey, it is important that role leads only accept an amount of shadows that they feel that can reasonably mentor within the scope of a release cycle.

If there are more contributors interested in shadowing once hitting that upper bound, we welcome them to sit in on Release Team meetings in preparation for shadowing in a future release cycle.

This policy was intentionally written to allow for flexibility in shadow selection for role leads, but is it time that we revisit?

Why is this needed:

While discussing changes to the Kubernetes release cadence, it was highlighted that fewer releases a year would also mean fewer opportunities to welcome new contributors to the community via the Release Team.

From #1290:

@saschagrunert:

On the other hand it will give less people a chance to participate in the shadowing program for example. Anyways, I think we will find appropriate solutions around those kind of new challenges.

@jeremyrickard:

The one downside is that we will remove an opportunity for shadowing, and as we saw this time around we had >100 people apply, and this will remove ~24-ish opportunities. I think we can maybe identify some opportunities for folks that want to be involved though. takes off release lead hat

@wilsonehusin:

as someone who started getting involved in this project through shadowing release team, I'd like to echo what @saschagrunert & @jeremyrickard raised above regarding shadow opportunities -- I'm glad we're acknowledging the downside and hope we can keep in mind to present other opportunities for folks to get involved!

@kcmartin:

As to the potential for limiting shadow opportunities (mentioned by @jeremyrickard, @wilsonehusin, and others), I'm definitely tuned in to that being a downside, since I've served as a SIG-Release shadow three times, and I think it's a fantastic opportunity!

One possible way to alleviate that downside would be to have 5 shadows, instead of three or four, per sub-team. I believe this is still a manageable number for the Leads, and could distribute the work more evenly.

@pires:

On a more personal note, (@jeremyrickard wink, wink) I applied for release shadow believing I'd be picked given my past contributions to the project and my justification to be selected over others. Being rejected was a humbling experience and I'm happy to let you know I didn't lose any of the appetite to contribute. Others may feel differently but, then again, the project is maturing and so should the community.

/assign @onlydole @palnabarun @bai @kikisdeliveryservice @savitharaghunathan
cc: @kubernetes/sig-release-leads
/area release-team
ref: kubernetes/enhancements#2567 (comment)
xref: #1343

[justaugustus]

/remove-kind feature
/kind documentation
/priority important-longterm

[annajung]

I think the number 3-4 probably was ideal at the moment when the doc was written, but with every release, the number of enhancements that are tracked by RT increases. We have seen a big increase in 1.20 and an even bigger number for 1.21.

The more enhancements to track, the more work required for the shadows and leads. At this point in time, 3-4 is no longer the ideal number for the number of enhancements RT tracks for the release.

With the release cadence change, it will impact the number of enhancements as well. So, we should be flexible with the number of shadows based on how much impact it will have per role.

[savitharaghunathan]

+1 to what @annajung said.

I think we need to have a minimum of 4 or above based on the team needs/workload and it will give the team enough breathing room if a shadow drops out during the cycle. Starting with 3-4 and if a shadow drops out or someone in the team is not being super responsive, puts a lot of stress on the rest of the team.

[wilsonehusin]

Context for future readers: I'm reading release cadence KEP and going down the trail of links. I'm also writing this with 1.21 release scheduled to go out in less than 2 weeks.

+1 on shadow availability as what Savitha and Anna mentioned above

I would also like to point out:

• Some work of release team is heavy at the {start, tail} end of release cycle and we should consider the team / shadow capacity at crunch time.
  • Of course, the ideal workload distribution is to have them evenly spread throughout the cycle, but with how everything else works in the community, our timeline isn't independent by itself.
• Release team meetings and schedules are generally US-centric. In the last few cycles, we tried to make schedule variations at reasonable time of day in EMEA / APAC. If we do increase the number of shadows and release team members, I hope that we strive to have a balanced timezone members and thus be inclusive to anyone in any timezone to join the activity.
  • I personally have not attended EMEA / APAC meetings as they are too early in the day for me, but looking at meeting notes seem to show that attendance and discussions are still heavy on the US-friendly meeting. I'd like to see more balanced activity and let sub-teams sync between the multiple events on what's relevant for them.

[kikisdeliveryservice]

While I agree 3-4 may not be the correct number I'd also say that there is probably also such a thing as too many - the lead needs to be able to have time to mentor folks and answer individual questions from each shadow, keep an eye on what the newer shadows are doing and increasing the number past a couple more means that it will probably be harder to do a good job with all of that. I'd probably advocate on the upper bound of 5, as we do want shadows to also be able to get enough experience & to really understand what's going on (also the enhancements toil is going down each release as the process refines).

I actually think the release cadence slowing down will be beneficial to the shadows as they will have a little more time in the release (quality of exp vs quantity of shadows) which has been something that I've heard in the past. I'd also offer that the RT doesn't stand on its own - it exists to support the release, so while we want a good shadow experience/plenty of opps to participate, we also need to strive for a manageable number that will be effective for its function/the release process as a whole.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[k8s-triage-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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.