Release Team: Consider expanding the team even during the release cycle to handle no-shows

[furkatgofurov7]

What would you like to be added (User Story)?

There are times when we should consider expanding the team during the release cycle to handle no-shows of Team Leads / Shadows.

We could:

• Setup guidelines for off-boarding.
• Have a check-point to re-confirm with members of the release team about commitment for the rest of the release cycle.

Detailed Description

The process for resigning as a release team shadow, or for a subteam lead to remove and replace an inactive shadow, should be defined and documented.

Currently, the process for removing and replacing an inactive shadow is undocumented knowledge handed down from subteam lead to successor, and the standards by which a shadow can be declared inactive are unclear. Subteam leads may not even be aware that this is an option until the issue rises to the point of asking the release lead what to do, by which point that subteam lead may already be taking on an inordinate quantity of work to compensate.

Similarly, shadows may not be aware that they can safely step down without consequences mid-cycle should they need to.

Additionally, the process has to be documented in cases when Team Specific Lead has to step down due to various reasons.

Anything else you would like to add?

I see two options to tackle shadow no-shows:

1. If one of the shadows needs to drop or the responsible team lead decides the shadow is inactive/not responding/not interacting in group chats or not showing up at all in release team activities, the sub-team lead could discuss it with Release Lead
   and if agreed, the shadow would have to step down from their role and new spot will be filled with the new shadow. New shadow placement availability can be announced over the project communication means, such as Slack/office hours etc.
2. instead of searching for a new shadow to replace the stepped-down one, we could consider increasing the number of shadows in sub-teams from 3-4 to at least 4 or better 5 at the beginning of the RT staffing, so that we have redundancy in such cases and there would be no need for a new shadow lookout.

In case Team Specific Lead has to step down due to various reasons:

• one option would be to choose a new Team specific lead among the shadows.

Any ideas/suggestions/feedback would be much appreciated!

Tracked in: #9104

Label(s) to be applied

/kind documentation
/area release

@kubernetes-sigs/cluster-api-release-team
cc @killianmuldoon @CecileRobertMichon @sbueringer

[furkatgofurov7]

/assign

[killianmuldoon]

/triage accepted

I'm in favor of flexibility here. IMO we shouldn't necessarily try to increase the size of the teams, as this might lead to people feeling like there's nothing for them to do and have more folks feeling disconnected from the actual work of the team.

I think the release team should feel free to add folks to their teams during the cycle, as long as the release team agree to it. Adding should be done by PR to the release cycle doc as it's done initially, which will allow the community to have an input. Folks should also feel free to resign, but if they're not willing to or can't be contacted there's no major downside from having their names associated with the release team on paper for a single cycle.

Setup guidelines for off-boarding.
Have a check-point to re-confirm with members of the release team about commitment for the rest of the release cycle.

These both seem like good ideas - but let's keep the process light here and just include who needs to be informed and where names / github handles etc. need to be removed from.

In case Team Specific Lead has to step down due to various reasons:
one option would be to choose a new Team specific lead among the shadows.

One issue here is the process for choosing leads in the first place has no clear definition. I think their process for stepping down should be the same as that for team members, with emphasis on communication to the community. From there the other leads and members of the community can be involved in picking a successor.

[furkatgofurov7]

I think the release team should feel free to add folks to their teams during the cycle, as long as the release team agree to it. Adding should be done by PR to the release cycle doc as it's done initially, which will allow the community to have an input.

The question here would be: how do we find a new shadow for the team (by announcing in the slack? office hours? mailing list?) and what happens if there are more than 1? We do not have a clear selection criteria AFAIK

One issue here is the process for choosing leads in the first place has no clear definition. I think their process for stepping down should be the same as that for team members, with emphasis on communication to the community. From there the other leads and members of the community can be involved in picking a successor.

+1

[killianmuldoon]

Personally I wouldn't do a full announcement - usually there are folks who want to be on the release team but don't make it in time or aren't selected. Members of the release team should be able to suggest candidates at that point. They can be reached out to directly until someone is found to fit the bill. If there's no candidates then an announcement is fine, but I would keep this process lightweight and not overly prescriptive.

[furkatgofurov7]

/cc @fabriziopandini

[sbueringer]

I'm fine with whatever the release team wants to do, but I would also try to not over-formalize the whole process.

One concern, I don't know if it's realistic to update the slack handle pretty often (iirc it was that one where we usually wait for a while until it's merged)

[g-gaston]

My 2c, whatever the majority wants, I'm happy with.

However, I'm always scared of adding too many processes in a short period of time.

As our release teams gain more experience, these processes will appear naturally and IMO that's actually a good thing. But I think we should be cautious when officially adding them to our development cycle. Processes add overhead: when following them, when enforcing them and when updating them (which inevitably happens over time).

I understand this is a personal opinion, but I always lean towards avoiding adding a process until the consequences of not adding them are clearly worse than the overhead they introduce. If we are still able to figure a particular situation with good faith and communication then maybe we don't need a process just yet.

[fabriziopandini]

+1 to not over-formalize this process.

IMO something like "if necessary during the release cycle, the release lead can add/remove release team members from the list to react to people stepping down due to personal/professional issues, no-show, unplanned spikes of work, or other circumstances" should be enough for now, we can always iterate in the future