Add Release Writer to release team roles

Signed-off-by: killianmuldoon <kmuldoon@vmware.com>

docs/release/release-tasks.md

@@ -47,6 +47,7 @@ This document details the responsibilities and tasks for each role in the releas
       - [\[Continuously\] Monitor CI signal](#continuously-monitor-ci-signal)
       - [\[Continuously\] Reduce the amount of flaky tests](#continuously-reduce-the-amount-of-flaky-tests)
       - [\[Continuously\] Bug triage](#continuously-bug-triage)
+  - [Release Writer](#release-writer)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
@@ -149,15 +150,8 @@ We should take a look at the following dependencies:
 The goal of this task is to ensure we have a release branch and the milestone applier applies milestones accordingly.
 From this point forward changes which should land in the release have to be cherry-picked into the release branch.
 
-1. Create the release branch locally based on the latest commit on main and push it:
-   ```bash
-   # Create the release branch
-   git checkout -b release-1.4
-
-   # Push the release branch
-   # Note: `upstream` must be the remote pointing to `github.com/kubernetes-sigs/cluster-api`.
-   git push -u upstream release-1.4
-   ```
+1. Ask the [Release Writer](#release-writer) to create a new release branch.
+
 2. Update the [milestone applier config](https://github.com/kubernetes/test-infra/blob/0b17ef5ffd6c7aa7d8ca1372d837acfb85f7bec6/config/prow/plugins.yaml#L371) accordingly (e.g. `release-1.4: v1.4` and `main: v1.5`)
    <br>Prior art: [cluster-api: update milestone applier config for v1.3](https://github.com/kubernetes/test-infra/pull/26631)
 
@@ -186,30 +180,14 @@ to a newer Go minor version according to our [backport policy](./../../CONTRIBUT
 
 1. Ensure CI is stable before cutting the release (e.g. by checking with the CI manager)
    Note: special attention should be given to image scan results, so we can avoid cutting a release with CVE or document known CVEs in release notes.
-2. Create and push the release tags to the GitHub repository:
-
-   **NOTE:** clusterctl will have issues installing providers between the time the release tag is cut and the Github release is published. See [issue 7889](https://github.com/kubernetes-sigs/cluster-api/issues/7889) for more details
-
-   ```bash
-   # Export the tag of the release to be cut, e.g.:
-   export RELEASE_TAG=v1.0.1
-
-   # Create tags locally
-   # Warning: The test tag MUST NOT be an annotated tag.
-   git tag -s -a ${RELEASE_TAG} -m ${RELEASE_TAG}
-   git tag test/${RELEASE_TAG}
-
-   # Push tags
-   # Note: `upstream` must be the remote pointing to `github.com/kubernetes-sigs/cluster-api`.
-   git push upstream ${RELEASE_TAG}
-   git push upstream test/${RELEASE_TAG}
-   ```
-   **Note**: This will automatically trigger a [GitHub Action](https://github.com/kubernetes-sigs/cluster-api/actions/workflows/release.yml) to create a draft release and a [ProwJob](https://prow.k8s.io/?repo=kubernetes-sigs%2Fcluster-api&job=post-cluster-api-push-images) to publish images to the staging repository.
+2. Ask the [Release Writer](#release-writer) to create and publish a tag for the release. This will automatically trigger a [GitHub Action](https://github.com/kubernetes-sigs/cluster-api/actions/workflows/release.yml) to create a draft release and a [ProwJob](https://prow.k8s.io/?repo=kubernetes-sigs%2Fcluster-api&job=post-cluster-api-push-images) to publish images to the staging repository.
 3. Promote images from the staging repository to the production registry (`registry.k8s.io/cluster-api`):
     1. Wait until images for the tag have been built and pushed to the [staging repository](https://console.cloud.google.com/gcr/images/k8s-staging-cluster-api) by the [post push images job](https://prow.k8s.io/?repo=kubernetes-sigs%2Fcluster-api&job=post-cluster-api-push-images).
     2. If you don't have a GitHub token, create one by going to your GitHub settings, in [Personal access tokens](https://github.com/settings/tokens). Make sure you give the token the `repo` scope.
     3. Create a PR to promote the images to the production registry:
        ```bash
+       # Export the tag of the release to be cut, e.g.:
+       export RELEASE_TAG=v1.0.1
        export GITHUB_TOKEN=<your GH token>
        make promote-images
        ```
@@ -229,8 +207,7 @@ to a newer Go minor version according to our [backport policy](./../../CONTRIBUT
          docker pull registry.k8s.io/cluster-api/kubeadm-control-plane-controller:${RELEASE_TAG}
          ```
 4. Publish the release in GitHub:
-    1. Get the final release notes from the docs team and add them to the GitHub release.
-    2. Publish the release (ensure to flag the release as pre-release if necessary).
+   1. Ask the [Release Writer](#release-writer) to publish the release in GitHub.
 5. Publish `clusterctl` to Homebrew by bumping the version in [clusterctl.rb](https://github.com/Homebrew/homebrew-core/blob/master/Formula/clusterctl.rb).
    <br>**Notes**:
     * This is only done for new latest stable releases, not for beta / RC releases and not for previous release branches.
@@ -491,3 +468,46 @@ and add them to the milestone of the current release.
 
 We probably have to figure out some details about the overlap between the bug triage task here, release leads
 and Cluster API maintainers.
+
+## Release Writer
+
+The Release Writer must be a person with write access to the Cluster API repo. They can hold another role in the release team. The Release Writer need only be involved in the release as required on days when releases are cut. They are not expected to take part in release team meetings or other activities, but should feel free to do so.
+
+### Responsibilities
+  * Create new release branches.
+  * Write tags for releases.
+  * Publish the release.
+
+1. Create the release branch locally based on the latest commit on main and push it.
+   ```bash
+   # Create the release branch
+   git checkout -b release-1.4
+
+   # Push the release branch
+   # Note: `upstream` must be the remote pointing to `github.com/kubernetes-sigs/cluster-api`.
+   git push -u upstream release-1.4
+   ```
+
+2. Create and push the release tags to the GitHub repository:
+
+   **NOTE:** clusterctl will have issues installing providers between the time the release tag is cut and the Github release is published. See [issue 7889](https://github.com/kubernetes-sigs/cluster-api/issues/7889) for more details
+
+   ```bash
+   # Export the tag of the release to be cut, e.g.:
+   export RELEASE_TAG=v1.0.1
+
+   # Create tags locally
+   # Warning: The test tag MUST NOT be an annotated tag.
+   git tag -s -a ${RELEASE_TAG} -m ${RELEASE_TAG}
+   git tag test/${RELEASE_TAG}
+
+   # Push tags
+   # Note: `upstream` must be the remote pointing to `github.com/kubernetes-sigs/cluster-api`.
+   git push upstream ${RELEASE_TAG}
+   git push upstream test/${RELEASE_TAG}
+   ```
+   **Note**: 
+
+3. Publish the release.
+   1. Get the final release notes from the docs team and add them to the GitHub release.
+   2. Publish the release. Ensure release is flagged as `pre-release` for all `beta` and `rc` releases or `latest` for a new release in the most recent release branch.

docs/release/release-team.md

@@ -50,7 +50,7 @@ As noted above, making changes to  the CAPI release cadence is out of scope for
 - **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.
 - **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.
 - **Shadow**: Any Release Team member may select one or more mentees to shadow the release process in order to help fulfill future Release Team staffing requirements and continue to grow the CAPI community in general.
-
+- **Release Writer**: 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/5999d1679509d4f3b09d50f394c43bc0f8d33c94/OWNERS_ALIASES#L21-L27).
 *Note*: This is also documented in [Release tasks](./release-tasks.md) together with a mapping to specific tasks.  
 
 ## Team Selection