Revise release checklist to be more explicit

.github/PULL_REQUEST_TEMPLATE/release-checklist.md

@@ -26,36 +26,34 @@ To check if any of the top-level crates need version increments, go to the zebra
 
 Zebra follows [semantic versioning](https://semver.org).
 
-Semantic versions look like:
+Semantic versions look like: `MAJOR`.`MINOR`.`PATCH[`-`TAG`.`PRE-RELEASE]`
-`MAJOR`.`MINOR`.`PATCH[`-`TAG`.`PRE-RELEASE]`
 
 #### Pre-Release Crates
 
-Pre-Release versions have a `TAG` like "alpha" or "beta".
+Pre-Release versions have a `TAG` like "alpha" or "beta". For example: `1.0.0-alpha.0`
-For example: "1.0.0-alpha.0"
 
 1. Increment the `PRE-RELEASE` version for the crate.
 
 Optionally, if a `MINOR` feature pre-release breaks `MAJOR` API compatibility:
+
 2. Increment the `MAJOR` version, and reset all the other versions to zero
 
 #### Unstable Crates
 
-Unstable versions have a `MAJOR` version of zero.
+Unstable versions have a `MAJOR` version of zero. For example: `0.1.0`
-For example: "0.1.0"
 
 1. Follow stable crate versioning, but increment the `MINOR` version for breaking changes
 
 #### Stable Crates
 
-For example: "1.0.0"
+For example: `1.0.0`
 
 Increment the first version component in this list, and reset the other components to zero:
 1. MAJOR versions for breaking public API changes and removals
-  * check for types from dependencies that appear in the public API
+    * check for types from dependencies that appear in the public API
 2. MINOR versions for new features
 3. PATCH versions for bug fixes
-  * includes dependency updates that don't impact the public API
+    * includes dependency updates that don't impact the public API
 
 ### Version Locations
 
@@ -65,6 +63,7 @@ Once you know which versions you want to increment, you can find them in the:
 - [ ] `zebrad` app code: https://github.com/ZcashFoundation/zebra/blob/main/zebrad/src/components/tracing/component.rs
 - [ ] `zebra-network` protocol user agent: https://github.com/ZcashFoundation/zebra/blob/main/zebra-network/src/constants.rs
 - [ ] `README.md`
+- [ ] `Cargo.lock`: automatically generated by `cargo build`
 
 Merge all these version increments as one commit, by squashing and rebasing the PR onto the main branch.
 
@@ -83,11 +82,14 @@ We skipped `tower-fallback`, because it hadn't changed since the last tag.
 
 ## Change Log
 
+**Important**: Any merge into `main` deletes any edits to the draft changelog. Edit the draft changelog in a pad like https://pad.riseup.net
+
 We follow the [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) format.
 
 We use [the Release Drafter workflow](https://github.com/marketplace/actions/release-drafter) to automatically create a [draft changelog](https://github.com/ZcashFoundation/zebra/releases).
 
 To create the final change log:
+- [ ] Copy the draft changelog into a pad like https://pad.riseup.net
 - [ ] Delete any trivial changes
 - [ ] Combine duplicate changes
 - [ ] Edit change descriptions so they are consistent, and make sense to non-developers
@@ -104,11 +106,12 @@ From "Keep a Changelog":
 * `Fixed` for any bug fixes.
 * `Security` in case of vulnerabilities.
 
-**Important**: Any merge into `main` while the Changelog is still in draft state will remove all the changes made and create a new raw list. Save your Changelog changes locally while in draft to avoid having to redo the list if that happens.
-
 ## After merging this PR
+- [ ] Check for any PRs that have been merged since you created the changelog pad
 - [ ] Update the draft release with the final changelog
-- [ ] Point the draft release at the commit resulting from merging this PR, using the correct version tag name
+- [ ] Set the release title to `Zebra ` followed by the version tag, for example: `Zebra 1.0.0-alpha.0` 
+- [ ] Set the tag name to the version tag, for example: `1.0.0-alpha.0`
+- [ ] Set the release to target the `main` branch
 - [ ] Mark the release as 'pre-release' (until we are no longer alpha/beta)
 
 ## Final Testing
@@ -120,4 +123,4 @@ If the build fails after tagging:
 1. fix the build
 2. check if the fixes changed any extra crates, and do the required version increments
 3. update `README.md` with a **new** git tag
-4. tag **another** release
+4. tag a **new** release