Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update Release Team Selection (Shadow questionnaire) #433

Merged
merged 1 commit into from Jan 10, 2019
Merged

Update Release Team Selection (Shadow questionnaire) #433

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
60 changes: 2 additions & 58 deletions release-team/README.md
View file
Open in desktop
Expand Up @@ -129,66 +129,9 @@ is undefined.
For all unplanned or embargoed releases
- Facilitate security releases following the under the [Security Release Process](security-release-process-documentation/security-release-process.md)

---

## Release Team Selection

In addition to discharging the duties of their respective Release Team roles, the current Release Team is charged with selecting the team for the following release cycle.

Team selection should happen transparently.

In the 1.11 release cycle, we selected the Release Team Lead by quorum during a public Release Team meeting and additional roles were staffed via [an issue in k/sig-release](https://github.com/kubernetes/sig-release/issues/167) and a set of PRs, starting with [this one](https://github.com/kubernetes/sig-release/pull/168).

Each Release Team role is responsible for staffing their respective role, with this order of fall-through in mind:
- training and selecting a successor from the current pool of role shadows
- training and selecting a successor from non-Release Team members
- staffing the role themselves

Ultimately, if none of these can be satisfied, responsibility falls to the future Release Team Lead and SIG Release to staff the roles.

### Release Team Lead Selection

The incoming Release Team Lead _MUST_ have participated on the Release Team for 2 or more release cycles, acting in a lead (non-shadow) capacity for at least one of those cycles.

Release Team Leads should be staffed, with this order of fall-through in mind:
- the current pool of Release Team Lead shadows
- the current pool of Release Team members
- former Release Team members

Bear in mind that these are suggestions based on precedent and a Release Team Lead may be nominated by any Release Team member, past or present.

_The new Release Team Lead can be selected via lazy consensus of the current Release Team members._

### Shadows

Every Release Team role should seek to accommodate a set of role shadows. This creates a new avenue for code and non-code contributors alike to contribute to the project. Additionally, it seeds future release cycles with new leaders.

While there isn't a strict restriction on the amount of shadows, we've found three shadows per role to be a reasonable upper bound.

If there are more contributors interested in shadowing once hitting that upper bound, we welcome them to sit in on Release Team meetings in preparation for shadowing in a future release cycle.

### Considerations

#### Timing

Staff early! The Release Team should undertake the selection process at the beginning Code Freeze, with a deadline of three days following the current release.

Any staffing decisions that cannot be made within this timeframe should be escalated to SIG Release Chairs and discussed publicly.

#### Membership

Try to ensure potential Release Team candidates:
- can commit to the amount of time required across the release cycle
- are enthusiastic about being on the release team
- are members of the relevant SIGs for their role, if applicable
- have some prior experience with contributing to Kubernetes (such as shadowing a role for a prior release)

Most importantly, strive for diversity in:
- gender identity
- ethnicity
- nationality
- locality
- company affiliation
If you're interested in learning more about how the Release Team is selected, as well as how to volunteer, please review the [Release Team Selection Process][release-team-selection-process].

---

Expand Down Expand Up @@ -225,6 +168,7 @@ The process for filing an enhancement exception can be found [here][exceptions].
[kubernetes-release-team-roles]: #kubernetes-release-team-roles
[other-activities-of-the-release-team]: #other-activities-of-the-release-team
[release-team-selection]: #release-team-selection
[release-team-selection-process]: release-team-selection.md
[milestone-maintainers]: #milestone-maintainers
[filing-exceptions]: #filing-exceptions
[exceptions]: /releases/EXCEPTIONS.md
102 changes: 102 additions & 0 deletions release-team/release-team-selection.md
View file
Open in desktop
@@ -0,0 +1,102 @@
# Release Team Selection

In addition to discharging the duties of their respective Release Team roles, the current Release Team is charged with selecting the team for the following release cycle.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Subtle nit: I think the current release team has a very powerful say in who should be on the next release team. But I feel like creating/staffing the next release team is the responsibility of SIG Release (or the owners of the release team subproject). eg: Neither Aish nor I have been opening up release-team staffing PR's or issues for this release team, but we have been consulted

I won't hold this PR back for this, but suggest we follow up.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will take a note to follow up on this.


Team selection should happen transparently.

In the 1.11 release cycle, we selected the Release Team Lead by quorum during a public Release Team meeting and additional roles were staffed via [an issue in k/sig-release](https://github.com/kubernetes/sig-release/issues/167) and a set of PRs, starting with [this one](https://github.com/kubernetes/sig-release/pull/168).

Each Release Team role is responsible for staffing their respective role, with this order of fall-through in mind:
- training and selecting a successor from the current pool of role shadows
- training and selecting a successor from non-Release Team members
- staffing the role themselves

Ultimately, if none of these can be satisfied, responsibility falls to the future Release Team Lead and SIG Release to staff the roles.

## Considerations

### Timing

Staff early! The Release Team should undertake the selection process at the beginning of Code Freeze, with a deadline of three days following the current release.
justaugustus marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Three days following current release is unrealistic, unless you're talking leads only. Going back to 1.10, release teams aren't finalized until the end of week 2.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can follow up on this.


Any staffing decisions that cannot be made within this timeframe should be escalated to SIG Release Chairs and discussed publicly.

### Membership

Try to ensure potential Release Team candidates:
- can commit to the amount of time required across the release cycle
- are enthusiastic about being on the release team
- are members of the relevant SIGs for their role, if applicable
- have some prior experience with contributing to Kubernetes (such as shadowing a role for a prior release)

Most importantly, strive for diversity in:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

somewhat orthogonal, but outreach to this effect would be a nice SIG subproject, if we get anything more official together for that we should link to it here :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For sure. Love that idea, @BenTheElder!

- gender identity
- ethnicity
- nationality
- locality
- company affiliation

## Selection Criteria

### Release Team Lead

The incoming Release Team Lead _MUST_ have participated on the Release Team for 2 or more release cycles, acting in a lead (non-shadow) capacity for at least one of those cycles.

Release Team Leads should be staffed, with this order of fall-through in mind:
- the current pool of Release Team Lead shadows
- the current pool of Release Team members
- former Release Team members

Bear in mind that these are suggestions based on precedent and a Release Team Lead may be nominated by any Release Team member, past or present.
justaugustus marked this conversation as resolved.
Show resolved Hide resolved

_The new Release Team Lead can be selected via lazy consensus of the current Release Team members._

### Release Team Lead Shadow

Same as [Release Team Lead](#release-team-lead).

### Shadows

Every Release Team role should seek to accommodate a set of role shadows. This creates a new avenue for code and non-code contributors alike to contribute to the project. Additionally, it seeds future release cycles with new leaders.

While there isn't a strict restriction on the amount of shadows, we've found three shadows per role to be a reasonable upper bound. However, as shadowing is intended to be a mentor / mentee journey, it is important that role leads only accept an amount of shadows that they feel that can reasonably mentor within the scope of a release cycle.

If there are more contributors interested in shadowing once hitting that upper bound, we welcome them to sit in on Release Team meetings in preparation for shadowing in a future release cycle.

In Kubernetes 1.14, we begun handling shadow selection using a questionnaire, as opposed to the first-come, first-served GitHub issue approach that we had adopted during previous release cycles ([1.12](https://github.com/kubernetes/sig-release/issues/167), [1.13](https://github.com/kubernetes/sig-release/issues/280).

Moving to a [questionnaire](#sample-questionnaire) / survey format will allow us to capture more of the information required to vet potential shadows and well as begin to generate metrics around some of the Release Team processes.

Questionnaire creation will be facilitated by SIG Release Chairs or a delegated coordinator to ensure consistency across release cycles.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to recommend a rough timeframe by which we want
(i) the questionairre to be sent out
(ii) 1:1 discussions completed between section leads and prospective shadows
(iii) Official shadows locked down?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AishSundar -- I think it's hard to do that at the moment, as the timelines may be shifting this release e.g., maybe nixing Code Slush. Let's assess this once the cycle kicks off.


Following submissions, the questionnaires will be reviewed by role leads of the incoming Release Team.

Volunteers that meet the requirements of the respective role will be contacted by those leads via some convenient mechanism (Slack, video chat, etc.) to further discuss.

After vetting the volunteers for their roles, role leads should make a final decision on selected shadows with the incoming Release Team Lead.


### Sample Questionnaire

Thank you for volunteering for the Kubernetes 1.14 Release Team!

This questionnaire is meant to learn a little bit more about you, your journey with Kubernetes, your understanding of the Release Team processes and procedures, as well as to determine if you're a good fit for the current Release Team. Please note that you are expected to be inexperienced in some areas, as a role shadow is a mentorship opportunity.

Participation in the Release Team can include somewhat open-ended expectations. We never know what blocking/critical issue may come up at what point during the release cycle. On a rare occasion this may mean we each make some personal sacrifice to check in on a status or show up at a meeting to give or receive information. The team of leads and shadows must be flexible and pragmatic in addressing these. The Release Team Lead will endeavor to make sure any such inconveniences do not unfairly hit individuals or specific timezones.

#### Logistics

- What [Release Team role(s)](https://git.k8s.io/sig-release/release-team#kubernetes-release-team-roles) are you interested in shadowing? _[Select up to two (2)]_
- The [Role Handbooks](https://git.k8s.io/sig-release/release-team/role-handbooks) defines the tasks and responsibilities of each role for this release cycle. Are you prepared to assist in fulfilling these duties? You must read the handbook relevant to the role you're interested in before answering.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a rubber stamp question. How do I know they've read the handbook? Again, I won't hold up for this.

But consider questions that demonstrate a bit of comprehension, eg:

  • "how many hours a week do you think you'll need to fulfill these duties?"
  • "which parts interest you most?"
  • "which parts interest you least?"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm inclined to hope that people are responding factually on the questionnaire, and by extension, have actually read the relevant handbooks. I generalized some of the questions so it can be used for all roles.

...just want to make sure this is more like getting a baseline of the volunteer and less like grading a test.

The latter two make for good "exit interview" questions. Maybe we can have a post-release survey in future?

- Shadowing Release Team roles requires a substantial time commitment, especially during the periods specified in your role handbook. The time requirements specified are estimates and depending on the need, you may need to dedicate more time than initially estimated. This may include attending video meetings at inconvenient times. Is this time you can commit to? (This usually requires support from your employer, as you may need to do release work during work hours.)
- Do you have any schedule conflicts during [this release cycle](https://git.k8s.io/sig-release/releases/release-1.14/README.md), such as vacations, school, or intense periods of work, that would make you unavailable for more than a couple of workdays?
- The purpose of shadowing is to train new Release Team members. Assuming that your job or life situations don't change between now and then, are you willing to volunteer for the relevant role Lead position for 1.15 or 1.16? (This usually requires support from your employer, as you may need to do release work during work hours.)
- What time zone are you usually in?

#### Experience
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a former release notes lead, I think it's really useful to have one shadow with programming experience and one shadow with copy-editing / technical writing experience. Should we include these kinds of questions in the questionnaire?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jberkus' initial intent was to have multiple questionnaires with role-specific information. I thought at this stage, it would be better to have a very generic survey that can apply to all roles with specifics about the role in the relevant role handbook. That's why one of the questions explicitly asks you to read the role handbook before continuing.

From a visibility/management perspective, I think it's also better to keep the handbook as the source of truth for role-specific requirements.

tpepper marked this conversation as resolved.
Show resolved Hide resolved

- What's your current experience and involvement with Kubernetes SIGs?
- Are you already a [Kubernetes organization member](https://git.k8s.io/community/community-membership.md#member)?
- Have you applied to, or served on, a prior release team? Please give details.
- Do you have any past experience (outside of the Kubernetes upstream community) working/volunteering in the role you're interested in? Please give details.
- Is there any specific goal you hope to accomplish or experience you intend to gain by participating in the Release Team? Please give details.