Merge pull request #9563 from g-gaston/permissions-release-tool

🌱 Give permissions for release notes tool to release team
kubernetes-sigs · Nov 2, 2023 · af64722 · af64722
2 parents e877eec + 15442ce
commit af64722
Show file tree

Hide file tree

Showing 2 changed files with 16 additions and 0 deletions.
diff --git a/docs/release/release-team.md b/docs/release/release-team.md
@@ -8,6 +8,7 @@
   - [Duration of Term](#duration-of-term)
   - [Specific Responsibilities](#specific-responsibilities)
   - [Team Roles](#team-roles)
+  - [Team repo permissions](#team-repo-permissions)
   - [Team Selection](#team-selection)
     - [Selection Criteria](#selection-criteria)
   - [Time Commitment](#time-commitment)
@@ -72,6 +73,14 @@ As noted above, making changes to  the CAPI release cadence is out of scope for
 - **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).
 *Note*: This is also documented in [Release tasks](./release-tasks.md) together with a mapping to specific tasks.  
 
+## Team repo permissions
+- Release notes (`CHANGELOG` folder)
+  - 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.
+  - All members of the release team have `lgtm` permissions for PRs that add release notes in this folder.
+- Release notes tool (`hack/tools/release` folder)
+  - 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.
+  - All members of the release team have `lgtm` permissions for the release notes tool code.
+
 ## Team Selection
 
 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. 

diff --git a/hack/tools/release/OWNERS b/hack/tools/release/OWNERS
@@ -0,0 +1,7 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+approvers:
+  - cluster-api-release-lead
+
+reviewers:
+  - cluster-api-release-team