Chore: update release template (#1350)

.github/ISSUE_TEMPLATE/release.yml

@@ -19,50 +19,82 @@ body:
         release process](https://docs.calitp.org/benefits/deployment/release/).
 
         Close this issue when the checklist is complete.
+    validations:
+      required: true
   - type: input
     id: manager
     attributes:
       label: Release manager
       description: GitHub handle of who is responsible for this release; assign this issue to this user
       placeholder: "@cal-itp-bot"
+    validations:
+      required: true
   - type: input
     id: version
     attributes:
       label: Release version
       description: Calver-formatted version for this release
       placeholder: YYYY.0M.R
+    validations:
+      required: true
   - type: markdown
     attributes:
       value: |
         ## Release type
 
         Reference the diagram and discussion on [the release process docs](https://docs.calitp.org/benefits/deployment/release/).
 
-        * `Regular` release: propogates from `dev` to `test`, and then `test` to `prod`. Only possible if `dev` is ready to deploy.
-        * `Hotfix` release: propogates from `test` to `prod`, skipping `dev`.
+        * `Regular` release: propagates from `dev` to `test`, and then `test` to `prod`. Only possible if `dev` is ready to deploy.
+        * `Hotfix` release: fix is merged into `prod`. After release, fix is propagated to `dev` and `test`.
   - type: dropdown
     id: type
     attributes:
       label: What type of release is this?
       options:
         - "Regular"
         - "Hotfix"
+    validations:
+      required: true
+  - type: markdown
+    attributes:
+      value: |
+        ## Release checklist
+
+        After this issue is created, edit the description to keep only the checklist for the release type.
   - type: checkboxes
-    id: checklist
+    id: regular-checklist
     attributes:
-      label: Release checklist
-      description: Complete these items in sequence as the release progresses
+      label: Regular release checklist
+      description: Complete these items in sequence as the `Regular` release progresses
       options:
+        - label: Ensure the `dev` branch and secrets are up to date
         - label: Create a branch called release/version from the source branch
         - label: Bump the application version
-        - label: Open a PR for the release branch into the staging target, merge
-        - label: "(If applicable): update staging data migrations"
-        - label: "(If applicable): open another PR from dev to test"
-        - label: "(If applicable): update data migrations"
+        - label: Open a PR for the release branch into `dev`, merge
+        - label: Ensure `test` secrets are up to date
+        - label: Open another PR from `dev` to `test`, merge
         - label: QA the app in test
-        - label: "(If applicable): prepare production data migrations"
-        - label: Open a PR to for the test branch into prod, merge
+        - label: Ensure `prod` secrets are up to date
+        - label: Open a PR for the `test` branch into `prod`, merge
         - label: QA the app in prod
-        - label: Tag the release on the prod branch, push the tag to GitHub
+        - label: Tag the release on the `prod` branch, push the tag to GitHub (see [docs](https://docs.calitp.org/benefits/deployment/release/#5-tag-the-release) for commands)
+        - label: Create a release in GitHub for the tag, generating release notes
+        - label: Edit release notes with additional context, images, animations, etc. as-needed
+  - type: checkboxes
+    id: hotfix-checklist
+    attributes:
+      label: Hotfix release checklist
+      description: Complete these items in sequence as the `Hotfix` release progresses
+      options:
+        - label: Make the hotfix in a branch from `prod`
+        - label: Bump the application version
+        - label: Ensure `prod` secrets are up to date
+        - label: Open a PR from the hotfix branch into `prod`, merge
+        - label: QA the fix in prod
+        - label: Tag the release on `prod`, push the tag to GitHub (see [docs](https://docs.calitp.org/benefits/deployment/release/#5-tag-the-release) for commands)
         - label: Create a release in GitHub for the tag, generating release notes
         - label: Edit release notes with additional context, images, animations, etc. as-needed
+        - label: Create a branch off `dev`
+        - label: Open a PR from `prod` into that branch, merge
+        - label: (optional) Adapt hotfix to current state of `dev` in that same branch
+        - label: Merge the PR into `dev`

docs/deployment/release.md

@@ -28,25 +28,24 @@ version numbers look like: `YYYY.0M.R`
 ## 1. Prepare release in a branch
 
 Typically changes for a release will move from `dev`, to `test`, to `prod`. This
-assumes `dev` is in a state that it can be deployed without disruption.
+assumes `dev` is in a state that it can be deployed without disruption. (This is called a `Regular` release.)
 
 If `dev` or `test` contain in-progress work that is not ready for production,
 and a hotfix is needed in production, a separate process to test the changes
-before deploying to `prod` must be undertaken.
+before deploying to `prod` must be undertaken. (This is called a `Hotfix` release.)
 
-The following diagram shows how a release should propogate to `prod` under
+As implied in the previous step, all releases follow the same version number format.
+
+The following diagram shows how a release should propagate to `prod` under
 different circumstances:
 
 ```mermaid
 graph LR
     A(Release branch) --> B{Are dev and test ready to deploy?};
     B -->|Yes| C(dev);
-    B -->|No| D{Are test and prod equivalent?};
-    C --> E(test);
-    E --> F(prod);
-    D -->|Yes| E;
-    D -->|No| G{{Revert test to prod}};
-    G --> E;
+    C --> D(test);
+    D --> E(prod);
+    B -->|No| E;
 ```
 
 By convention the release branch is called `release/YYYY.0M.R` using the