docs: Capture UX-oriented practices for changelog (#9284)

CONTRIBUTING.md

@@ -153,10 +153,44 @@ If you are a VS Code user, you may want to add the following to your `.vscode/se
 Every fix, improvement, feature, or breaking change should be made in a
 pull-request that includes an update to the `CHANGELOG_PENDING.md` file.
 
+### What does a good changelog entry look like?
+
+Changelog entries should answer the question: "what is important about this
+change for users to know?" or "what problem does this solve for users?". It
+should not simply be a reiteration of the title of the associated PR, unless the
+title of the PR _very_ clearly explains the benefit of a change to a user.
+
+Some good examples of changelog entry descriptions:
+
+```
+- [consensus] \#1111 Small transaction throughput improvement (approximately
+  3-5\% from preliminary tests) through refactoring the way we use channels
+- [mempool] \#1112 Refactor Go API to be able to easily swap out the current
+  mempool implementation in Tendermint forks
+- [p2p] \#1113 Automatically ban peers when their messages are unsolicited or
+  are received too frequently
+```
+
+Some bad examples of changelog entry descriptions:
+
+```
+- [consensus] \#1111 Refactor channel usage
+- [mempool] \#1112 Make API generic
+- [p2p] \#1113 Ban for PEX message abuse
+```
+
+For more on how to write good changelog entries, see:
+
+- <https://keepachangelog.com>
+- <https://docs.gitlab.com/ee/development/changelog.html#writing-good-changelog-entries>
+- <https://depfu.com/blog/what-makes-a-good-changelog>
+
+### Changelog entry format
+
 Changelog entries should be formatted as follows:
 
 ```md
-- [module] \#xxx Some description about the change (@contributor)
+- [module] \#xxx Some description of the change (@contributor)
 ```
 
 Here, `module` is the part of the code that changed (typically a

RELEASES.md

@@ -121,6 +121,11 @@ branch (see above). Otherwise:
 3. Prepare the changelog:
    - Move the changes included in `CHANGELOG_PENDING.md` into `CHANGELOG.md`. Each RC should have
      it's own changelog section. These will be squashed when the final candidate is released.
+   - Ensure that there is a "release highlights" or "release summary" paragraph
+     after the version heading describing what we feel are the most important
+     changes in this release from a user's perspective. This paragraph should
+     answer the question: "why should users upgrade to this version?", and with
+     specific reasons (not generic ones like "more bug fixes").
    - Run `python ./scripts/linkify_changelog.py CHANGELOG.md` to add links for
      all PRs
    - Ensure that `UPGRADING.md` is up-to-date and includes notes on any breaking changes