Sig-release: More refined guidance for Release Manager Associates

[Bubblemelon]

As mentioned in this comment:

The branch management handbook needs a more thorough section for shadows on:

• [ ] What they might learn
• [ ] Contributor ladder
• [ ] How to contribute to ongoing tasks e.g. allow shadows to run ./branchff, run a mock build, help with release verification (or write a script for that), etc.
• [ ] Skills required (although I think the "Minimum skills and requirements" section of the handbook seems sufficient - putting this on here for thoughts)
• [ ] Making sure this does get missed out i.e. debugging release tools [[src](https://github.com/kubernetes/sig-release/pull/666#discussion_r296541793)]

Continuation of #666

CC: @idealhack @SlickNik @vivektaparia @chrisz100

[SlickNik]

Thanks for creating this issue @Bubblemelon!

Here are some of my thoughts on this:

• It would be good to include a section about what one might learn as a 'Release Manager Associate' (formerly Branch Manager Shadow) - in addition to the expectations section, having this defined a bit more concretely would be helpful.
• Having a section on how to contribute would also be great; one thing that this will help iron out is ensuring that 'Release Manager Associates' have the appropriate permissions needed to run necessary tasks (e.g. ./branchff).
• Agree on the skills comment; imho the skills outlined in the 'Minimum skills and requirements section' seem sufficient.

I'm happy to help put together something for some combination of 1, 2 above - let me know what you think.

[justaugustus]

@Bubblemelon @idealhack @SlickNik -- allow me to take a run at this.
I plan to take a look at the Branch Manager and Patch Release handbooks and try to distill out:

• An onboarding guide, with lists to join, access requirements, expectations/requirements for team members, common set of tools we use
• Dedupe data between the two handbooks

/assign
/area release-eng
/priority important-soon
/milestone v1.16

[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-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

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-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.