docs(maintaining): add release manager rotation

Author: jsjoeio

.github/ISSUE_TEMPLATE/release.md

@@ -9,6 +9,7 @@ assignees: "@cdr/code-server-reviewers"
 <!-- Maintainer: fill out the checklist -->
 
 ## Checklist
+
 - [ ] Assign to next release manager
 - [ ] Close previous release milestone
 - [ ] Create next release milestone

CHANGELOG.md

@@ -62,11 +62,11 @@ VS Code v1.56
 
 ### Bug Fixes
 
-- fix: Check the logged user instead of $USER #3330 @videlanicolas
+- item
 
 ### Documentation
 
-- item
+- docs(maintaining): add process for release managers #3360 @jsjoeio
 
 ### Development
 

docs/MAINTAINING.md

@@ -8,6 +8,8 @@
     - [Triage](#triage)
     - [Project Boards](#project-boards)
   - [Versioning](#versioning)
+  - [Release](#release)
+  - [Release Manager Rotation](#release-manager-rotation)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
@@ -63,3 +65,15 @@ It also gives us a way to separate the issue triage from bigger-picture, long-te
 `<major.minor.patch>`
 
 The code-server project follows traditional [semantic versioning](ttps://semver.org/), with the objective of minimizing major changes that break backward compatibility. We increment the patch level for all releases, except when the upstream Visual Studio Code project increments its minor version or we change the plugin API in a backward-compatible manner. In those cases, we increment the minor version rather than the patch level.
+
+## Release
+
+## Release Manager Rotation
+
+With each release, we rotate the role of "release manager" to ensure every maintainer goes thorugh the process. This helps us keep documentation up-to-date and encourages us to continually review and improve the flow with each set of eyes.
+
+If you're the current release manager, follow these steps:
+
+1. Create a [release issue](../.github/ISSUE_TEMPLATE/release.md)
+2. Fill out checklist
+3. After their release is cut, they close their release template and their release milestone