sigs.k8s.io/cluster-api@v1.7.1/docs/release/release-team.md (about)

     1  <!-- START doctoc generated TOC please keep comment here to allow auto update -->
     2  <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
     3  
     4  - [Cluster API Release Team](#cluster-api-release-team)
     5    - [Overview](#overview)
     6      - [Goals](#goals)
     7      - [Non-Goals/Future work](#non-goalsfuture-work)
     8    - [Duration of Term](#duration-of-term)
     9    - [Specific Responsibilities](#specific-responsibilities)
    10    - [Team Roles](#team-roles)
    11    - [Team repo permissions](#team-repo-permissions)
    12    - [Team Selection](#team-selection)
    13      - [Selection Criteria](#selection-criteria)
    14    - [Time Commitment](#time-commitment)
    15    - [Release Team/Day Meetings](#release-teamday-meetings)
    16    - [Suggestions for Team Leads](#suggestions-for-team-leads)
    17    - [Why should I volunteer?](#why-should-i-volunteer)
    18    - [Cluster API release team vs kubernetes/kubernetes-SIG membership](#cluster-api-release-team-vs-kuberneteskubernetes-sig-membership)
    19  
    20  <!-- END doctoc generated TOC please keep comment here to allow auto update -->
    21  
    22  # Cluster API Release Team
    23  
    24  ## Overview
    25  
    26  In the past, releasing Cluster API has been mostly ad-hoc and relied on one or more contributors to do most of the chore work necessary to prepare the release. One of the major downsides of this approach is that it is often difficult for users and providers to plan around Cluster API releases as they often have little visibility around when a release will happen. 
    27  
    28  This document introduces the concept of a release team with the following goals and non-goals:
    29  
    30  ### Goals
    31  
    32  - To improve communication to end users and contributors about CAPI release cadence and target release dates
    33  - To spread the load of release tasks and involve a bigger, more diverse set of CAPI contributors in cutting releases
    34  - To look at the Kubernetes SIG release team processes for guidance on releasing best practices
    35  - To improve tooling, documentation, and automation of the CAPI release process
    36  
    37  ### Non-Goals/Future work
    38  
    39  - To increase the frequency of releases (AKA release cadence). This will be revisited in the future once the release process stabilizes.
    40  - To change the current proposal (CAEP) process
    41  - To copy implement all steps of the Kubernetes release process for CAPI releases
    42  
    43  Note that this document is intended to be a starting point for the release team. It is not a complete release process document.
    44  
    45  More details on the CAPI release process can be found in the [release cycle](./release-cycle.md) and [release task](./release-tasks.md) documentation.
    46  
    47  ## Duration of Term
    48  
    49  Each release team term will last approximately four months, to align with one minor release cycle. A minor release cycle starts right after a minor release and concludes with the release of the next minor release. There is no limit to the number of terms a release team member can serve, meaning that it's possible for a release team member to serve multiple consecutive terms.
    50  
    51  As noted above, making changes to  the CAPI release cadence is out of scope for this initial release team process. 
    52  
    53  ## Specific Responsibilities
    54  
    55  - Release patch releases monthly or more often as needed, so users will get fixes & updated dependencies with CVE fix on a predictable cadence
    56  - Release a minor release every 4 months (to be revised, see future work), so users will get new features on a predictable cadence
    57  - Create beta and release candidate (rc) tags for upcoming minor releases
    58  - Ensure only eligible PRs are cherry-picked to the active release branches
    59  - Monitor CI signal, so a release can be cut at any time, and add CI signal for each new release branch
    60  - Maintain and improve user facing documentation about releases, release policy and calendar
    61  - Update the CAPI Netlify book certificates and DNS
    62  - Update the clusterctl Homebrew formula
    63  - Create and maintain the GitHub release milestone
    64  - Maintain and improve and release automation, tooling & related developer docs
    65  - Track tasks needed to add support for new Kubernetes versions in the next CAPI release
    66  
    67  
    68  ## Team Roles
    69  
    70  - **Release Lead**: responsible for coordinating release activities, assembling the release team, taking ultimate accountability for all release tasks to be completed on time, and ensuring that a retrospective happens. The lead is also responsible for ensuring a successor is selected and trained for future release cycles.
    71  - **Communications/Docs/Release Notes Manager**: Responsible for communicating key dates to the community, improving release process documentation, and polishing release notes. Also responsible for ensuring the user-facing Netlify book and provider upgrade documentation are up to date.
    72  - **CI Signal/Bug Triage/Automation Manager**: Assumes the responsibility of the quality gate for the release and makes sure blocking issues and bugs are triaged and dealt with in a timely fashion. Helps improve release automation and tools.
    73  - **Team member**: Any Release Team lead or manager may select one or more additional members to help with their tasks. These team members will help fulfill future Release Team staffing requirements and continue to grow the CAPI community in general.
    74  *Note*: This is also documented in [Release tasks](./release-tasks.md) together with a mapping to specific tasks.
    75  
    76  ## Team repo permissions
    77  - Release notes (`CHANGELOG` folder)
    78    - The Release Lead has approval permissions, which allows them to merge PRs that add new release notes. This will start an automated release process through GitHub Actions: creating tags, create GitHub Release draft, etc.
    79    - All members of the release team have `lgtm` permissions for PRs that add release notes in this folder.
    80  - Release notes tool (`hack/tools/release` folder)
    81    - The Release Lead has approval permissions, which allows them to merge code changes to this tool. It's not their responsibility to always review the code changes (although they can), but to make sure the right folks have `lgtm`ed the PR.
    82    - All members of the release team have `lgtm` permissions for the release notes tool code.
    83  
    84  ## Team Selection
    85  
    86  To start, the release team will be assembled by the release team lead based on volunteers. A call for volunteers can be made through the usual communication channels (office hours, Slack, mailing list, etc.). In the future, we may consider introducing an application process similar to the Kubernetes release team application process. 
    87  
    88  ### Selection Criteria
    89  
    90  When assembling a release team, the release team lead should look for volunteers who:
    91  
    92  - Can commit to the amount of time required across the release cycle
    93  - Are enthusiastic about being on the release team
    94  - Preferably are [members of the kubernetes or the kubernetes-SIG org](https://github.com/kubernetes/community/blob/master/community-membership.md) (see [notes](#cluster-api-release-team-vs-kuberneteskubernetes-sig-membership)).
    95  - Have some prior experience with contributing to CAPI releases (such having been in the release team for a prior release)
    96  - Have diverse company affiliations (i.e. not all from the same company)
    97  - Are members of the Kubernetes slack community (register if you are not!)
    98  - Are members of the Cluster Lifecycle SIG mailing list (subscribe to the [SIG Cluster Lifecycle Google Group](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle) if you are not!)
    99  
   100  ## Time Commitment
   101  
   102  As a member of the release team, you should expect to spend approximately 4-8 hours a week on release related activities for the duration of the term.
   103  
   104  Specific time commitments include:
   105     * Release Team meetings once a week throughout the entire release cycle.
   106     * Release Day meetings ideally occurring once during the actual release weeks. Refer to release cycle timeline for more specific details.
   107     * Any other release-related critical meetings with prior notice.
   108  
   109  While we don't anticipate individuals to be available every week during the release cycle, please feel free to inform the team of any unavailability so we can plan accordingly.
   110  
   111  Before you volunteer to be part of a CAPI release team, please make certain that your employer is aware and supportive of your commitment to the release team.
   112  
   113  ## Release Team/Day Meetings
   114  
   115  Release Team Members meet and share team specific updates, news and all release specific items in the Release Team Meetings.
   116  
   117  - Release Team Meetings happen once a week every Wednesday, half an hour before office hours using the CAPI meeting zoom [link](https://zoom.us/j/861487554?pwd=dTVGVVFCblFJc0VBbkFqQlU0dHpiUT09). 
   118  - Release Team Meeting notes can be found [here](https://docs.google.com/document/d/1AUiuvapS3ldYVJfKucDhIoH6IJIPS009jqwnSTwS0EI).
   119  - Reach out to maintainers to get the zoom meeting host key to be able to share the screen when office hours zoom link is used.
   120  
   121  *Note:* For now, we don't have a calendar invite for Release Team Meetings to be sent out to all Release Team Members. Create a recurring calendar invite for the period of whole release cycle and send it to all Release Team Members.
   122  
   123  Release Day meetings is used to cut the releases as a group following the release cycle timeline.
   124  
   125  - Release Day Meetings happen on the release date specified in the release timeline document, using the CAPI meeting zoom [link](https://zoom.us/j/861487554?pwd=dTVGVVFCblFJc0VBbkFqQlU0dHpiUT09) at the time depending on the Release Team Members timezone and availability.
   126  
   127  ## Suggestions for Team Leads
   128  
   129    * In the first week of the release cycle, organize an onboarding session with members of your team (i.e CI Lead with CI team members) to go over the general responsibilities and expectations.
   130    * Public communication should be default: all the Release Team specific topics, issues, discussion have to be public and discussed openly in the communication channels the Release Team uses. It gives visibility on the work being done, it is inclusive and track of record. All other communication
   131    within the Release Team Members can de carried out using a private group/chat.
   132    * For Release Lead: Inform Release Team Members about the upcoming release, a day prior to the actual release cutting date over a common communication
   133    channel (usually Cluster API Slack) and ask for team specific updates from Team Leads (i.e status of CI signal from CI Team Lead or preparing a PR for release notes with new desired tag in advance) to ensure smoother release cutting process and avoid unexpected surprises. 
   134    * Clearly communicate with the team members you are responsible for, that the majority of the work during the release cycle will be a collaborative effort.
   135    * Establish an ownership rotation policy in consultation with respective team members.
   136    * Provide opportunities for team members to take the lead in cutting a release within the cycle, based on feasibility.
   137    * Define backup ownership and tasks for team members, such as:
   138        * Hosting release team meetings.
   139        * Communicating key updates during office hours meetings when necessary.
   140        * Sharing release-related updates with the CAPI community.
   141        * Monitoring and reporting CI status regularly to the release team.
   142        * Scheduling additional meetings as required to facilitate a smooth release cycle.
   143  
   144  ## Why should I volunteer?
   145  
   146  Volunteering to be part of a CAPI release team is a great way to contribute to the community and to the release process:
   147  
   148  - Get more familiar with the CAPI release process
   149  - Create lasting relationships with other members of the community
   150  - Contribute to the CAPI project health
   151  
   152  ## Cluster API release team vs kubernetes/kubernetes-SIG membership
   153  
   154  Candidates for the Cluster API release team should preferably be [members of the kubernetes or the kubernetes-SIG org](https://github.com/kubernetes/community/blob/master/community-membership.md), but this is not a hard requirement.
   155  
   156  Non-org members can perform all the tasks of the release team, but they can't be added to the [cluster-api-release-team](https://github.com/kubernetes/org/blob/99343225f3ce39c2d3da594b7aca40ca8043bd54/config/kubernetes-sigs/sig-cluster-lifecycle/teams.yaml#L341) GitHub group.
   157  
   158  Being part of the Cluster API release team could be a great start for people willing to become a members of the kubernetes-SIG org, see
   159  the official list of [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#requirements).