Update Shadow Selection Documentation

[JamesLaverack]

Update both the shadow selection and EA Handbook to clarify a few aspects of the selection process.

Note: This is mostly a holding issue for me to go back and make these updates.

• Advise that a single person taking on multiple roles on the same team (e.g., shadowing multiple roles) is generally not permitted, and explain why.
• Guidelines for leads selecting shadows from the same company as them (i.e., usually don't, but talk to the EA if there's a case).
• Add to the EA handbook a seciton on how to prune the shadow applications:
  • Look for duplicates
  • Look for spam
  • Look for applications from people who are already release team members
• Add to the EA handbook a section on using https://github.com/kubernetes-sigs/release-team-shadow-stats to generate Markdown.
  • Add a special note about the Slack limitation of only uploading 10 files.
• Talk about how the EA should validate the selections, and what they should look for.
  • Gender balance (based on pronouns), in particular ensuing there are no all-male subteams.
  • Regional and timezone distirubtion, especially for comms.
  • Good mix of new and returning members.
  • Company balance, that no one employer is over-represented.
  • That leads are close to the "two new, two returners" advise, and discuss with them if they're not. (It's not unacceptable, but it is something to keep an eye out for)

• Discuss timing of onboarding and offering roles, and why that is done (to avoid shadows learning they are not selected by watching others announce their invovlement).
• Discuss the procedure for onboarding new shadows. In particular:
  • Who and when we should we process shadow org membership for each one
  • Who and when we should process k/k8s.io group membership

[JamesLaverack]

/kind documentation
/priority important-longterm

[palnabarun]

/milestone v1.27

[k8s-triage-robot]

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

This bot triages un-triaged issues 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:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[SGA-pranamika-pandey]

Hi @JamesLaverack ,
I'm Pranamika, a Kubernetes user and a newbie contributor.
I read in the Release shadow documentation that a sign-up form would be posted in the last week of the prior release cycle, or the first week of the new one.

But I couldn't understand, where it would be posted. I tried finding slack channels and github issues but couldn't find anything.
Did I miss anything please?

Kind regards,
Pranamika