Sig-release: Update RT docs/handbooks to remove being an org member as a req for RT shadows

[justaugustus]

Feedback from Twitter (@sethmccombs) that some handbooks list being an org member as a requirement to be a shadow for the Release Team.

While that's definitely a _goal_ for shadows (and a requirement for Leads), we should edit the documentation to make sure to not alienate any potential contributors.

/milestone v1.15
/priority critical-urgent
/kind cleanup
/help

@kubernetes/release-team

[k8s-ci-robot]

@justaugustus:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

Feedback from Twitter (@sethmccombs) that some handbooks list being an org member as a requirement to be a shadow for the Release Team.

While that's definitely a _goal_ for shadows (and a requirement for Leads), we should edit the documentation to make sure to not alienate any potential contributors.

/milestone v1.15
/priority critical-urgent
/kind cleanup
/help

@kubernetes/release-team

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.

[jimangel]

Minor objection to this. If we are expecting a shadow to lead after working on 2 releases (6 months), it would be helpful if they are already an org member, at the start, in order to work towards an approver during their lead cycle.

We've hit a few minor snags with @makoscafee not having full permissions this cycle.

I believe the process in gaining org membership, specifically for docs, isn't incredibly blocking or painful (and encourage @sethmccombs to work towards it! 👍). I'm also open to saying it's STRONGLY STRONGLY STRONGLY encouraged for those reasons - but not a blocker.

The last thing we want to do is turn down good help due to process...

[justaugustus]

Sir, I object to your objection!
Just kidding. Although I do think an implied function of the lead role is to provide support to their shadows in bringing them to the point where they can take over the role. Guiding them through membership should be part of that.

I'm curious; today and historically, have all Docs Leads also been Docs approvers?

I'm absolutely open to workshopping the appropriate language.
Would you like to PR something for this? :)

[jimangel]

I know the previous 3 (@zparnold, @tfogo, and myself) were, I'm _thinking_ others beyond that were too. I can do some digging...

I'm all for opening the process more vs. closing - so it sounds like a language change is all that is needed.

I'm currently short on bandwidth at the moment, but this might be a good PR for @sethmccombs?

[justaugustus]

I'm currently short on bandwidth at the moment, but this might be a good PR for @sethmccombs?

Great idea, Jim!

[sethmccombs]

I'm on it! I'll get something together this evening or tomorrow at the latest!

[sethmccombs]

So here's what I'm seeing, some handbooks mention requirements, some do not.

Some (Enhancements) state "in addition to the requirements detailed for all Release Team Members", but that link just points to the SIG-Release README, which is just links to other reading, should we perhaps point that at the Release Team README, which doesn't have a concrete requirements section, but it's something. Or perhaps the Release Team Onboarding page?

What my train of thought is, and where I'd like guidance from your folks is, do we create a requirements section somewhere (Release Team README?) which is the general requirements, (time, working on joining the k8s org, etc), for both leads and shadows?

Then reference that from each handbook? And allow those that maintain the handbooks,(prior leads, etc) to add the "additionals", such as Enhancements shadows needing Org Membership? (This last part came from the Kubernetes Community Membership section of the "Release Team Onboarding" page.

For that to work, we'd also "need" (want?) to have "requirements" section for each handbook? For both leads and shadows?

I'm working on a PR for this, which I can easily land tomorrow, I just want to do the right thing, seems like the plan for this when this repo was created was a general requirements section, but that seems to have been lost in the shuffle.

[jberkus]

@sethmccombs I never knew about any general requirements session. Such would be a good idea, since a bunch of the requirements (slack & GH logins, free time, etc.) are common to all roles.

Regarding the Org Membership, what I put in the CI signal handbook is:

Become a Kubernetes org member. In many cases, this will be done with the sponsorship of the CI Signal Lead or Release Lead in the first week of the cycle.

I think that's good language for the requirement. We don't expect them to be an org member when they start, but we do expect them to be one by the time they finish.

[justaugustus]

Or perhaps the Release Team Onboarding page?

Yep, point all handbooks to that page.

What my train of thought is, and where I'd like guidance from your folks is, do we create a requirements section somewhere (Release Team README?) which is the general requirements, (time, working on joining the k8s org, etc), for both leads and shadows?

That should be the onboarding doc.

For that to work, we'd also "need" (want?) to have "requirements" section for each handbook? For both leads and shadows?

That should be covered in the umbrella issue here: https://github.com/kubernetes/sig-release/issues/574
The role leads are in the process of updating their handbooks as we wind down on 1.15, so no action required there.

Just so we don't blow scope, the only requirements here are:

• scrub any references in all handbooks that someone _must_ be an org member, before being accepted as a role shadow
• link out each of the handbooks to the onboarding guide

Any further improvements can be addressed in follow up PRs.

HTH! :)

[zacharysarah]

@justaugustus 👋

I'm curious; today and historically, have all Docs Leads also been Docs approvers?

Yes, out of necessity. For leads to merge docs PRs into the release branch requires leads to be approvers.

[justaugustus]

Closed via #685.
/close

[k8s-ci-robot]

@justaugustus: Closing this issue.

In response to this:

Closed via #685.
/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.