Sig-release: Proposal: shadow halo process

[lachie83]

In an effort to build a pool of capable community members to serve on the release team and to ensure succession, the shadow role was created and implemented many release cycles ago. It occurred to me that there is no clear path for shadows to NOT serve on consistent release cycles and still be eligible for a lead role and hence I would like to discuss an idea that I refer to as "shadow haloing".

The purpose of shadow haloing is to provide a capable contingent of shadow members that are eligible to serve lead roles without the burden of having to commit consistently to contiguous release processes. This may also aide in easing burnout by having already served as a shadow but not been given the opportunity to serve as a lead.

The initial details are as follows:

• An existing shadow is eligible to serve in a lead role so long as they have served on a release team in any role within the last three releases.

I am reluctant to put too much process in this issue without having discussed the high level concept for now. The process can be as simple as proving eligibility and submitting interest in serving a role on a specific release team and providing sufficient verbiage around this being a valid path.

[tpepper]

I think this is/was the intent, if not well worded as such in the english language document?

[lachie83]

okay thanks for the confirmation - I couldn't find wording to validate so thought I would ask the question and also put a timebox how long the acquired skills would remain relevant. Is there currently any expiry date on release team skills if a member has been out of the loop for more than a few cycles?

[qedrakmar]

As a lapsed shadow, I agree with the "last three releases" timebox. I might have been able to serve as lead to the role I shadowed over a year ago, but not now, without shadowing again. I think it's a fair expiration date.

[jberkus]

Yeah, I think this was always the intention as well ... submit a PR update to the Role docs?

[lachie83]

Sure. I'll submit a PR. Thanks for the feedback.

[justaugustus]

What's the status on this?
/milestone v1.15

[justaugustus]

/assign @lachie83

[justaugustus]

/area release-team
/priority important-longterm

[justaugustus]

What's the current status of this?

[alejandrox1]

ping @lachie83 any updates on this?
/milestone v1.17

[alejandrox1]

/milestone v1.18

[alejandrox1]

/unassign @lachie83

[alejandrox1]

/help

[k8s-ci-robot]

@alejandrox1:
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:

/help

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.

[alejandrox1]

/assign @lachie83

[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

[LappleApple]

Hi, can this be closed?

[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