From cdd03bf00d57d27c606e235194e2e9fff54e0444 Mon Sep 17 00:00:00 2001 From: Stephen Augustus Date: Tue, 4 Sep 2018 02:48:47 -0400 Subject: [PATCH 1/4] Add Release Team selection criteria Signed-off-by: Stephen Augustus --- release-team/README.md | 54 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/release-team/README.md b/release-team/README.md index e7205bade121..4d3048f910b4 100644 --- a/release-team/README.md +++ b/release-team/README.md @@ -188,6 +188,60 @@ 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 with 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 can 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 + +_The new Release Team Lead should be agreed by quorum of the current Release Team members._ + +**If for some reason a new RT Lead cannot be selected by these methods, the current Release Team Lead should be prepared to continue to serve in the following release cycle until a successor can be found.** + +### Shadows + +Every Release Team role should seek to accomodate 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. + +### Additional Considerations + +- Staff early! The 1.11 and 1.12 Release Teams began the selection process during Code Freeze +- 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 affliation + +--- + ## 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. From c31379990e2ce6619954fe8301c43ce8369d3054 Mon Sep 17 00:00:00 2001 From: Stephen Augustus Date: Tue, 4 Sep 2018 03:21:27 -0400 Subject: [PATCH 2/4] Add table of contents to RT README.md Signed-off-by: Stephen Augustus --- release-team/README.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/release-team/README.md b/release-team/README.md index 4d3048f910b4..2c652dc0f47d 100644 --- a/release-team/README.md +++ b/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 @@ -262,3 +269,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 \ No newline at end of file From 98399e16b2b2a70f7690c27654be50efcec13b2d Mon Sep 17 00:00:00 2001 From: Josh Berkus Date: Fri, 20 Jul 2018 17:28:39 -0700 Subject: [PATCH 3/4] (jberkus) Update RT Lead guide --- .../release-team-lead/README.md | 39 ++++++++++++++++--- 1 file changed, 33 insertions(+), 6 deletions(-) diff --git a/release-team/role-handbooks/release-team-lead/README.md b/release-team/role-handbooks/release-team-lead/README.md index 0bac31b13611..95fb7c45be58 100644 --- a/release-team/role-handbooks/release-team-lead/README.md +++ b/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 trained for future release cycles. ## Authority and Responsibility: @@ -34,6 +34,33 @@ 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 select a Release Team in consultation with SIG-Release. Currently there are 10 roles to fill on the Release Team, plus one or more shadows (trainees) of each of those roles. each of which has specific requirements. Aside from any specifics, in general you are looking for candidates who: + +1. Can commit to the amount of time required across the release cycle; +2. Are enthusiastic about being on the release team; +3. Are members of the relevant SIGs for their role, if applicable; +4. And have some prior experience with contributing to Kubernetes (such as shadowing a role for a prior release). + +In most cases, you will have a pool of candidates in the form of people who have previously shadowed the role in question, or have filled a different role on the Release Team and want to try something else. Where possible, do select new team members over someone who has done the role several times, as we are trying to share experience across the organization. + +Also give some thought to ensuring diversity on the team, including members of more than one gender, ethnicity, nationality, and company affiliation. This should not be hard to do, as prior release teams have had several women, several non-white folks, and staff from five or more companies. In some cases, though, you may need to reach out to individuals you know and suggest that they apply for the team. + ## Standards: * The GitHub repository layout is: @@ -50,7 +77,7 @@ 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) @@ -58,9 +85,9 @@ A guiding principle for the lead is be an arbiter of decisions, and not the prim * 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 +107,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 +190,7 @@ A guiding principle for the lead is be an arbiter of decisions, and not the prim

- 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.

- 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.) -

- Insure Test Infra Lead has release branch CI created and added to Testgrid +

- Ensure Test Infra Lead has release branch CI created and added to Testgrid

- Most feature-oriented tasks should be completed at the end of this week

- SIGs that have not completed release themes should be contacted again, with a focus on explaining why this matters to the community

- 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. From ba2d65d5341c3cf6c68551b7b9a20bc8fa766d7e Mon Sep 17 00:00:00 2001 From: Stephen Augustus Date: Tue, 4 Sep 2018 21:14:27 -0400 Subject: [PATCH 4/4] Update RT selection and RT Lead docs Incorporating feedback from reviews on: * #226 * #261 Signed-off-by: Stephen Augustus --- release-team/README.md | 33 +++++++++++-------- .../release-team-lead/README.md | 18 +++------- 2 files changed, 25 insertions(+), 26 deletions(-) diff --git a/release-team/README.md b/release-team/README.md index 2c652dc0f47d..aac1a3903349 100644 --- a/release-team/README.md +++ b/release-team/README.md @@ -201,7 +201,7 @@ In addition to discharging the duties of their respective Release Team roles, th 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 with 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). +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 @@ -214,38 +214,45 @@ Ultimately, if none of these can be satisfied, responsibility falls to the futur 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 can be staffed, with this order of fall-through in mind: +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 -_The new Release Team Lead should be agreed by quorum of the current 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. -**If for some reason a new RT Lead cannot be selected by these methods, the current Release Team Lead should be prepared to continue to serve in the following release cycle until a successor can be found.** +_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 accomodate 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. +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. -### Additional Considerations +### Considerations -- Staff early! The 1.11 and 1.12 Release Teams began the selection process during Code Freeze -- 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) +#### 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 affliation +- company affiliation --- diff --git a/release-team/role-handbooks/release-team-lead/README.md b/release-team/role-handbooks/release-team-lead/README.md index 95fb7c45be58..ce3f75c532f1 100644 --- a/release-team/role-handbooks/release-team-lead/README.md +++ b/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 trained for future release cycles. +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: @@ -50,16 +50,9 @@ Among the specific time commitments you have are: ## Choosing a Release Team -One of your first, and definitely your most important, duties as Release Lead is to select a Release Team in consultation with SIG-Release. Currently there are 10 roles to fill on the Release Team, plus one or more shadows (trainees) of each of those roles. each of which has specific requirements. Aside from any specifics, in general you are looking for candidates who: +One of your first, and definitely your most important, duties as Release Lead is to ensure a Release Team is in place. -1. Can commit to the amount of time required across the release cycle; -2. Are enthusiastic about being on the release team; -3. Are members of the relevant SIGs for their role, if applicable; -4. And have some prior experience with contributing to Kubernetes (such as shadowing a role for a prior release). - -In most cases, you will have a pool of candidates in the form of people who have previously shadowed the role in question, or have filled a different role on the Release Team and want to try something else. Where possible, do select new team members over someone who has done the role several times, as we are trying to share experience across the organization. - -Also give some thought to ensuring diversity on the team, including members of more than one gender, ethnicity, nationality, and company affiliation. This should not be hard to do, as prior release teams have had several women, several non-white folks, and staff from five or more companies. In some cases, though, you may need to reach out to individuals you know and suggest that they apply for the team. +Release Team selection should happen in accordance with the [Release Team Selection](/release-team/README.md#release-team-selection) process. ## Standards: @@ -219,7 +212,7 @@ Also give some thought to ensuring diversity on the team, including members of m

- Assist the documentation leads in collecting missing docs PRs.

- Schedule burndown meetings starting next week for every weekday until the Friday after release day, make sure to invite the community calendar

- 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. -

- 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. +

- 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.

- Prepare for x.x.0-beta.2 release (week 11), ensuring x.x-blocking, master-blocking, and master-upgrade dashboards are 100% green. @@ -251,7 +244,6 @@ Also give some thought to ensuring diversity on the team, including members of m 14 -

- Help fill the any open position for the next release milestone -

- 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. +

- Help fill the any open positions for the next release milestone