docs: updates about branches and where to target PRs (#12416)

* docs: updates about branches and where to target PRs

CONTRIBUTING.md: calling out the release flow doc earlier and more of why a contributor should read it.
LOTUS_RELEASE_FLOW: being more precise and organized about branch strategy.
RELEASE_ISSUE_TEMPLATE: added comment on what we expect to see when backporting from release branch to master.

* Update LOTUS_RELEASE_FLOW.md

Co-authored-by: Rod Vagg <rod@vagg.org>

* Update LOTUS_RELEASE_FLOW.md

Co-authored-by: Rod Vagg <rod@vagg.org>

* Incorporating review feedback.  Stripped colors and made clear that we're cherry picking.

* Removed one more color reference

---------

Co-authored-by: Rod Vagg <rod@vagg.org>

CONTRIBUTING.md

@@ -13,10 +13,10 @@ Lotus is a universally open project and welcomes contributions of all kinds: cod
 
 ## Before Contributing
 
-1. If the proposal entails a protocol change, please first submit a [Filecoin Improvement Proposal](https://github.com/filecoin-project/FIPs).
-2. If the change is complex and requires prior discussion, [open an issue](github.com/filecoin-project/lotus/issues) or a [discussion](https://github.com/filecoin-project/lotus/discussions) to request feedback before you start working on a pull request. This is to avoid disappointment and sunk costs, in case the change is not actually needed or accepted.
-3. Please refrain from submitting PRs to adapt existing code to subjective preferences. The changeset should contain functional or technical improvements/enhancements, bug fixes, new features, or some other clear material contribution. Simple stylistic changes are likely to be rejected in order to reduce code churn.
-4. Familiarize yourself with our [release flow](LOTUS_RELEASE_FLOW.md) to understand how changes are incorporated into releases.
+1. Familiarize yourself with our [release flow](LOTUS_RELEASE_FLOW.md) to understand how changes are incorporated into releases.  This includes our branch strategy and where to target PRs.
+2. If the proposal entails a protocol change, please first submit a [Filecoin Improvement Proposal](https://github.com/filecoin-project/FIPs).
+3. If the change is complex and requires prior discussion, [open an issue](github.com/filecoin-project/lotus/issues) or a [discussion](https://github.com/filecoin-project/lotus/discussions) to request feedback before you start working on a pull request. This is to avoid disappointment and sunk costs, in case the change is not actually needed or accepted.
+4. Please refrain from submitting PRs to adapt existing code to subjective preferences. The changeset should contain functional or technical improvements/enhancements, bug fixes, new features, or some other clear material contribution. Simple stylistic changes are likely to be rejected in order to reduce code churn.
 
 ## Implementing Changes
 

LOTUS_RELEASE_FLOW.md

@@ -107,24 +107,19 @@ Unless a security issue is actively being exploited or a significant number of u
 
 ## Branch and Tag Strategy
 
-> [!NOTE]
-> - <span style="color:blue">Blue text</span> indicates node-related information.
-> - <span style="color:orange">Orange text</span> indicates miner-related information.
-> - System default colored text applies to both node and miner releases.
-
-* Releases are branched from the `master` branch, regardless of whether they include a network upgrade or not.
+* Releases are usually branched from the `master` branch, regardless of whether they include a network upgrade or not.
+  * For certain patch releases where we can't risk including recent `master` changes (such as for security or emergency bug-fix releases):
+    * Node: `release/vX.Y.Z+1` will be created from `release/vX.Y.Z`
+    * Miner: `release/miner/vX.Y.Z+1` will be created from `release/miner/vX.Y.Z`
 * PRs usually target the `master` branch, even if they need to be backported to a release branch. 
+  * The primary exception is CHANGELOG editorializing and callouts.  As part of the [release process](https://github.com/filecoin-project/lotus/blob/master/documentation/misc/RELEASE_ISSUE_TEMPLATE.md), those changes happen directly in a release branch and are cherry-picked back to `master` at the end of a release. 
 * PRs that need to be backported should be marked with a `backport` label.
-* <span style="color:blue">Node release branches are named `release/vX.Y.Z`</span>
-* <span style="color:orange">Miner release branches are named `release/miner/vX.Y.Z`</span>
+* Node release branches are named `release/vX.Y.Z`
+* Miner release branches are named `release/miner/vX.Y.Z`
 * By the end of the release process:
-  * <span style="color:blue">A `release/vX.Y.Z` branch (node) will have an associated `vX.Y.Z` tag</span>
-  * <span style="color:orange">A `release/miner/vX.Y.Z` branch (miner) will have an associated `miner/vX.Y.Z` tag</span>
-* Both node and miner releases may have additional `vX.Y.Z-rcN` or `miner/vX.Y.Z-rcN` tags for release candidates
-* The `master` branch is typically the source for creating release branches
-* For emergency patch releases where we can't risk including recent `master` changes:
-  * <span style="color:blue">Node: `release/vX.Y.Z+1` will be created from `release/vX.Y.Z`</span>
-  * <span style="color:orange">Miner: `release/miner/vX.Y.Z+1` will be created from `release/miner/vX.Y.Z`</span>
+  * A `release/vX.Y.Z` branch (node) will have an associated `vX.Y.Z` tag
+  * A `release/miner/vX.Y.Z` branch (miner) will have an associated `miner/vX.Y.Z` tag
+* Both node and miner releases may have additional `vX.Y.Z-rcN` or `miner/vX.Y.Z-rcN` tags for release candidates.
 * As of 202408, the `releases` branch is no longer used and no longer tracks the latest release.  See [Why is the `releases` branch deprecated and what are alternatives?](#why-is-the-releases-branch-deprecated-and-what-are-alternatives).
 
 ## FAQ

documentation/misc/RELEASE_ISSUE_TEMPLATE.md

@@ -129,9 +129,9 @@
 
 ### Post-Release
 
-- [ ] Open a pull request against `master` with a merge of the `release/vX.Y.Z` branch. 
-   - [ ] Conflict resolution should ignore the changes to `version.go` (keep the `-dev` version from master). 
+- [ ] Open a pull request against `master` cherry-picking the CHANGELOG commits from the `release/vX.Y.Z` branch. 
    - Link to PR: 
+   - Assuming we followed [the process of merging changes into `master` first before backporting to the release branch](https://github.com/filecoin-project/lotus/blob/master/LOTUS_RELEASE_FLOW.md#branch-and-tag-strategy), the only changes should be CHANGELOG updates.  
 - [ ] Finish updating/merging the [RELEASE_ISSUE_TEMPLATE.md](https://github.com/filecoin-project/lotus/blob/master/documentation/misc/RELEASE_ISSUE_TEMPLATE.md) PR from `Before RC1` with any improvements determined from this latest release iteration.
 
 ## ❤️ Contributors