sigs.k8s.io/cluster-api@v1.6.3/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    - [Suggestions for Team Leads](#suggestions-for-team-leads)
    16    - [Why should I volunteer?](#why-should-i-volunteer)
    17    - [Cluster API release team vs kubernetes/kubernetes-SIG membership](#cluster-api-release-team-vs-kuberneteskubernetes-sig-membership)
    18  
    19  <!-- END doctoc generated TOC please keep comment here to allow auto update -->
    20  
    21  # Cluster API Release Team
    22  
    23  ## Overview
    24  
    25  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. 
    26  
    27  This document introduces the concept of a release team with the following goals and non-goals:
    28  
    29  ### Goals
    30  
    31  - To improve communication to end users and contributors about CAPI release cadence and target release dates
    32  - To spread the load of release tasks and involve a bigger, more diverse set of CAPI contributors in cutting releases
    33  - To look at the Kubernetes SIG release team processes for guidance on releasing best practices
    34  - To improve tooling, documentation, and automation of the CAPI release process
    35  
    36  ### Non-Goals/Future work
    37  
    38  - To increase the frequency of releases (AKA release cadence). This will be revisited in the future once the release process stabilizes.
    39  - To change the current proposal (CAEP) process
    40  - To copy implement all steps of the Kubernetes release process for CAPI releases
    41  
    42  Note that this document is intended to be a starting point for the release team. It is not a complete release process document.
    43  
    44  More details on the CAPI release process can be found in the [release cycle](./release-cycle.md) and [release task](./release-tasks.md) documentation.
    45  
    46  ## Duration of Term
    47  
    48  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.
    49  
    50  As noted above, making changes to  the CAPI release cadence is out of scope for this initial release team process. 
    51  
    52  ## Specific Responsibilities
    53  
    54  - Release patch releases monthly or more often as needed, so users will get fixes & updated dependencies with CVE fix on a predictable cadence
    55  - Release a minor release every 4 months (to be revised, see future work), so users will get new features on a predictable cadence
    56  - Create beta and release candidate (rc) tags for upcoming minor releases
    57  - Ensure only eligible PRs are cherry-picked to the active release branches
    58  - Monitor CI signal, so a release can be cut at any time, and add CI signal for each new release branch
    59  - Maintain and improve user facing documentation about releases, release policy and calendar
    60  - Update the CAPI Netlify book certificates and DNS
    61  - Update the clusterctl Homebrew formula
    62  - Create and maintain the GitHub release milestone
    63  - Maintain and improve and release automation, tooling & related developer docs
    64  - Track tasks needed to add support for new Kubernetes versions in the next CAPI release
    65  
    66  
    67  ## Team Roles
    68  
    69  - **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.
    70  - **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.
    71  - **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.
    72  - **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.
    73  - **Maintainer**: Responsible for tasks which require write access to the Cluster API repo including creating release tags and creating a release branch. This role must be filled by someone on the [`cluster-api-maintainers` list](https://github.com/kubernetes-sigs/cluster-api/blob/main/OWNERS_ALIASES).
    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  ## Suggestions for Team Leads
   114  
   115    * 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.
   116    * 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.
   117    * Establish an ownership rotation policy in consultation with respective team members.
   118    * Provide opportunities for team members to take the lead in cutting a release within the cycle, based on feasibility.
   119    * Define backup ownership and tasks for team members, such as:
   120        * Hosting release team meetings.
   121        * Communicating key updates during office hours meetings when necessary.
   122        * Sharing release-related updates with the CAPI community.
   123        * Monitoring and reporting CI status regularly to the release team.
   124        * Scheduling additional meetings as required to facilitate a smooth release cycle.
   125  
   126  ## Why should I volunteer?
   127  
   128  Volunteering to be part of a CAPI release team is a great way to contribute to the community and to the release process:
   129  
   130  - Get more familiar with the CAPI release process
   131  - Create lasting relationships with other members of the community
   132  - Contribute to the CAPI project health
   133  
   134  ## Cluster API release team vs kubernetes/kubernetes-SIG membership
   135  
   136  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.
   137  
   138  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.
   139  
   140  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
   141  the official list of [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#requirements).