Simplify release permissions process.

Signed-off-by: James Blair <[email protected]>

Documentation/contributor-guide/release.md

@@ -15,6 +15,7 @@ for ensuring the stability of the release branch.
 - Marek Siarkowicz [@serathius](https://github.com/serathius)
 - Sahdev Zala [@spzala](https://github.com/spzala)
 - Wenjia Zhang [@wenjiaswe](https://github.com/wenjiaswe)
+- Ivan Valdes Castillo [@ivanvc](https://github.com/ivanvc)
 
 All release version numbers follow the format of [semantic versioning 2.0.0](http://semver.org/).
 
@@ -69,9 +70,8 @@ which don't need to be executed before releasing each version.
 ### Release steps
 
 1. Raise an issue to publish the release plan, e.g. [issues/17350](https://github.com/etcd-io/etcd/issues/17350).
-2. Raise a `kubernetes/org` pull request to temporarily elevate permissions for the GitHub release team.
-3. Once permissions are elevated, temporarily relax [branch protections](https://github.com/etcd-io/etcd/settings/branches) to allow pushing changes directly to `release-*` branches in GitHub.
-4. Verify you can pass the authentication to the image registries,
+2. Raise a `kubernetes/org` pull request to ensure members of the release team are added to the [release github team](https://github.com/orgs/etcd-io/teams/release-etcd).
+3. Verify you can pass the authentication to the image registries,
    - `docker login gcr.io`
    - `docker login quay.io`
      - If the release person doesn't have access to 1password, one of the owners (@ahrtr, @ivanvc, @jmhbnz, @serathius) needs to share the password with them per [this guide](https://support.1password.com/share-items/). See rough steps below,
@@ -80,9 +80,9 @@ which don't need to be executed before releasing each version.
        - Select `Password of quay.io`.
        - Click `Share` on the top right, and set expiration as `1 hour` and only available to the release person using his/her email.
        - Click `Copy Link` then send the link to the release person via slack or email.
-5. Clone the etcd repository and checkout the target branch,
+4. Clone the etcd repository and checkout the target branch,
    - `git clone --branch release-3.X [email protected]:etcd-io/etcd.git`
-6. Run the release script under the repository's root directory, replacing `${VERSION}` with a value without the `v` prefix, i.e. `3.5.13`.
+5. Run the release script under the repository's root directory, replacing `${VERSION}` with a value without the `v` prefix, i.e. `3.5.13`.
    - `DRY_RUN=false ./scripts/release.sh ${VERSION}`
    - **NOTE:** When doing a pre-release (i.e., a version from the main branch, 3.6.0-alpha.2), you will need to explicitly set the branch to main:
      ```
@@ -91,14 +91,14 @@ which don't need to be executed before releasing each version.
 
    It generates all release binaries under the directory `/tmp/etcd-release-${VERSION}/etcd/release/` and images. Binaries are pushed to the Google Cloud bucket
    under project `etcd-development`, and images are pushed to `quay.io` and `gcr.io`.
-7. Publish the release page on GitHub
+6. Publish the release page on GitHub
    - Open the **draft** release URL shown by the release script
    - Click the pen button at the top right to edit the release
    - Review that it looks correct, reviewing that the bottom checkboxes are checked depending on the
      release version (v3.4 no checkboxes, v3.5 has the set as latest release checkbox checked,
      v3.6 has the set as pre-release checkbox checked)
    - Then, publish the release
-8. Announce to the etcd-dev googlegroup
+7. Announce to the etcd-dev googlegroup
 
    Follow the format of previous release emails sent to [email protected], see an example below. After sending out the email, ask one of the mailing list maintainers to approve the email from the pending list. Additionally, label the release email as `Release`.
 
@@ -114,11 +114,11 @@ Thanks to everyone who contributed to the release!
 etcd team
 ```
 
-9. Update the changelog to reflect the correct release date.
-10. Paste the release link to the issue raised in Step 1 and close the issue.
-11. Restore standard branch protection settings and raise a follow-up `kubernetes/org` pull request to return to least privilege permissions.
-12. Crease a new stable branch through `git push origin release-${VERSION_MAJOR}.${VERSION_MINOR}` if this is a new major or minor stable release.
-13. Re-generate a new password for quay.io if needed (e.g. shared to a contributor who isn't in the release team, and we should rotate the password at least once every 3 months).
+8. Update the changelog to reflect the correct release date.
+9. Paste the release link to the issue raised in Step 1 and close the issue.
+10. Raise a follow-up `kubernetes/org` pull request to return the GitHub release team to empty, least privilege state.
+11. Crease a new stable branch through `git push origin release-${VERSION_MAJOR}.${VERSION_MINOR}` if this is a new major or minor stable release.
+12. Re-generate a new password for quay.io if needed (e.g. shared to a contributor who isn't in the release team, and we should rotate the password at least once every 3 months).
 
 #### Release known issues