Merge pull request kubernetes#271 from justaugustus/rt-selection

Add Release Team selection criteria

release-team/README.md

@@ -1,5 +1,12 @@
 # Kubernetes Release Team
 
+- [Overview][overview]
+- [Specific responsibilities][specific-responsibilities]
+- [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]
+- [Milestone Maintainers][milestone-maintainers]
+
 ## Overview
 
 The Kubernetes Release Team is embedded within SIG Release and is responsible for the day to day work required to
@@ -188,6 +195,67 @@ For all unplanned or embargoed releases
 
 ---
 
+## 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
+
+---
+
 ## Milestone Maintainers
 
 Across release cycles, one of the best signals for [issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#milestones) is whether or not an issue or PR is actually targeted for the current milestone.
@@ -208,3 +276,10 @@ Members of the `kubernetes-milestone-maintainers` GitHub team can include:
 Maintainers of the GitHub team can, with justification, add or remove members at any time during release cycles.
 
 Members are expected to actively triage issues and PRs to retain membership in `kubernetes-milestone maintainers`. Members not fulfilling the duties of this role should be removed.
+
+[overview]: #overview
+[specific-responsibilities]: #specific-responsibilities
+[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
+[milestone-maintainers]: #milestone-maintainers

release-team/role-handbooks/release-team-lead/README.md

@@ -2,7 +2,7 @@
 
 ## Overview:
 
-The release team leader role is responsible for coordinating release activities, assembling the release team, taking ultimate accountability for all release tasks to be completed on time, and ensuring a retrospective happens.  The lead is also responsible for ensuring a successor is selected once the release is complete.  
+The release team leader role is responsible for coordinating release activities, assembling the release team, taking ultimate accountability for all release tasks to be completed on time, and ensuring a retrospective happens. The lead is also responsible for ensuring a successor is selected and trained for future release cycles.
 
 ## Authority and Responsibility:
 
@@ -34,6 +34,26 @@ A guiding principle for the lead is be an arbiter of decisions, and not the prim
 
 * Prior experience in release management is extremely helpful
 
+## Time Commitments:
+
+Release Lead is a very time-consuming role, especially towards the end of the release cycle.  Before you volunteer to be Release Lead, please make certain that your employer and your family are OK with you spending a lot of time on the release for the next three months.  Here's a rough estimate of the time requirements by week:
+
+* Weeks 1-4: 4-8 hours a week
+* Weeks 5-8: 6-12 hours a week
+* Weeks 9-13: 10 to 25 hours a week, including some after-hours and weekend work
+
+Among the specific time commitments you have are:
+
+* SIG-Release and Release Team meetings once a week during weeks 1-7.
+* Burndown meetings three to five times a week during weeks 8-12.
+* Community meetings once a week.
+
+## Choosing a Release Team
+
+One of your first, and definitely your most important, duties as Release Lead is to ensure a Release Team is in place.
+
+Release Team selection should happen in accordance with the [Release Team Selection](/release-team/README.md#release-team-selection) process.
+
 ## Standards:
 
 * The GitHub repository layout is:
@@ -50,17 +70,17 @@ A guiding principle for the lead is be an arbiter of decisions, and not the prim
 
 * Short links are handled with [http://bit.ly](http://bit.ly) - and each release follows the convention of:
 
-    * Retro doc:  [http://bit.ly/](http://bit.ly/kubeXXretro)[kube](http://bit.ly/kubeXXretro)[XXretro](http://bit.ly/kubeXXretro) where XX is the version number minus dots, e.g.: [http://bit.ly/kube110retro](http://bit.ly/kube110retro) 
+    * Retro doc:  [http://bit.ly/](http://bit.ly/kubeXXretro)[kube](http://bit.ly/kubeXXretro)[XXretro](http://bit.ly/kubeXXretro) where XX is the version number minus dots, e.g.: [http://bit.ly/kube110retro](http://bit.ly/kube110retro)
 
     * Release Schedule overview [http://bit.ly/k8sXX-release-info](http://bit.ly/k8sXX-release-info)
 
     * Zoom link:  [http://bit.ly/k8sXX-zoom](http://bit.ly/k8sXX-zoom) 
 
     * Burndown/Meeting Minutes: [http://bit.ly/k8sXX-burndown](http://bit.ly/k8sXX-burndown)
 
-    * Features tracking spreadsheet:  [http://bit.ly/k8sXX-features](http://bit.ly/k8sXX-features) 
+    * Features tracking spreadsheet:  [http://bit.ly/k8sXX-features](http://bit.ly/k8sXX-features)
 
-    * Merged PRs with release notes: [http://bit.ly/k8sXX-relnotes](http://bit.ly/k8sXX-relnotes) 
+    * Merged PRs with release notes: [http://bit.ly/k8sXX-relnotes](http://bit.ly/k8sXX-relnotes)
 
     * Use the same conventions for additional documents
 
@@ -80,7 +100,7 @@ A guiding principle for the lead is be an arbiter of decisions, and not the prim
 
 * The release lead is responsible for updating the [burndown template](https://docs.google.com/document/d/1zLnmDDOp_ko9Yh5uPJtgqPFD7GKq76fQsKaenXoMHzM/edit) ahead of the release (changing the milestone in links and anything else requested during the retrospective)
 
-* Release theme: There is no particular reason for this other than to have fun.  As release lead you get to pick a theme naming the release.
+* Release theme: There is no particular reason for this other than to have fun, and possibly provide a theme for Release Team gifts / shirts. As Release Team Lead, you get to pick a theme for the release.
     * Releases 1.8 to 1.10, had unofficial food-based code names.
        * 1.8 - "Burrito"
        * 1.9 - "Pumpkin"
@@ -163,7 +183,7 @@ A guiding principle for the lead is be an arbiter of decisions, and not the prim
     <td>
 <p>- Coordinate x.x.0-beta.0 release, ensuring master-blocking, and master-upgrade dashboards are 100% green if possible (this release is not an official beta, just an artifact of the release process), and any flakes are being actively worked by SIGs since this is a chance to look at CI signal.  The release-x.x branch is created automatically as a part of the beta.0 release.  The branch manager now begins daily fast forwards.
 <p>- The burndown templates should be useful at this point since it starts asking about status relevant to each area now tracking (e.g. branch health, docs, communications, issues, etc.)
-<p>- Insure Test Infra Lead has release branch CI created and added to Testgrid
+<p>- Ensure Test Infra Lead has release branch CI created and added to Testgrid
 <p>- Most feature-oriented tasks should be completed at the end of this week
 <p>- SIGs that have not completed release themes should be contacted again, with a focus on explaining why this matters to the community
 <p>- Ping release team leads reminding them to start considering succession plans.  If they are handing the role off to a successor, identifying them early gives more time for the committed volunteer to get targeted mentoring.</td>
@@ -192,7 +212,7 @@ A guiding principle for the lead is be an arbiter of decisions, and not the prim
 <p>- Assist the documentation leads in collecting missing docs PRs.
 <p>- Schedule burndown meetings starting next week for every weekday until the Friday after release day, make sure to invite the community calendar
 <p>- Release notes, and themes should be close to done if not completed. There is a script that gathers notes from PRs but it’s still in progress.  As the lead you may need to help assemble the notes.
-<p>- Identify vacancies on the incoming release team and begin asking SIGs, the community, and CNCF-sponsor companies for volunteers to fill roles.  Getting committed volunteers now means they are also more actively engaged in the final weeks of the release, leading to more opportunities for final mentoring before they assume their release team role.
+<p>- Identify vacancies on the incoming release team and begin asking SIGs, the community, and CNCF-sponsor companies for volunteers to fill roles. Getting committed volunteers now means they are also more actively engaged in the final weeks of the release, leading to more opportunities for final mentoring before they assume their release team role. Continue to improve and uphold the [Release Team Selection](/release-team/README.md#release-team-selection) process.
 <p>- Prepare for x.x.0-beta.2 release (week 11), ensuring x.x-blocking, master-blocking, and master-upgrade dashboards are 100% green.</td>
   </tr>
   <tr>
@@ -224,7 +244,6 @@ A guiding principle for the lead is be an arbiter of decisions, and not the prim
   </tr>
   <tr>
     <td>14</td>
-    <td><p>- Help fill the any open position for the next release milestone
-<p>- If no one qualified steps up as a lead, you need to keep the following x.y release on track until you find your replacement.  </td>
+    <td><p>- Help fill the any open positions for the next release milestone</td>
   </tr>
 </table>