Extend release notes to include "announce"

doc/_pages/release_playbook.md

@@ -68,10 +68,10 @@ the main body of the document:
   not the "Multibody" heading.
 * Expand all acronyms (eg, MBP -> MultibodyPlant, SG -> SceneGraph).
 * Commits can be omitted if they only affect tests or non-installed examples. {% comment %}TODO(jwnimmer-tri) Explain how to check if something is installed.{% endcomment %}
-* PRs that are tagged with release deprecation information _may_ appear twice.
-  They will be included once in the appropriate deprecation-related section
-  according to the deprecation tag. But they may also appear in their topical
-  section if they also include a tag such as "fix" or "feature".
+* PRs may appear in multiple sections, depending on the tags they have. For
+  example, a PR that includes a fix and new deprecation will appear in both the
+  fix and newly-deprecated sections. Generally, PRs will be included once in
+  each appropriate section according to the tags assigned to it.
 * In general you should mention deprecated/removed classes and methods using
   their exact name (for easier searching).
   * In the deprecation section you can provide the fully-qualified name as the

doc/_pages/reviewable.md

@@ -120,6 +120,16 @@ notes: feature`` or ``release notes: fix`` is fine; in the
 case of externals bumps, the notes document doesn't use separate
 sections for fix / feature anyway.
 
+**release notes: announce**<br/>
+
+Drake release notes will frequently highlight specific changes in its
+"Announcements" section. If a PR author (or subsequent reviewer) feels that
+the PR's change should be included in the announcements, they can add this tag
+to call the release engineer's attention to it. This is a helpful aid to the
+release engineer, but, at the end of the day, the release engineer has
+discretion to include PRs in announcements that have not been tagged and even
+omit PRs that _have_ been tagged.
+
 **When combining release notes labels:**
 
 - ``none`` must not be combined with any other label.
@@ -129,6 +139,9 @@ sections for fix / feature anyway.
   because usually the deprecation is concurrent with the addition of its
   replacement or due to some other new change. Only if the deprecation is the
   _sole_ content of the commit will ``newly deprecated`` be the only label.
+- ``announce`` will generally be combined with another label -- presumably the
+  label characterizing the nature of a change being announced. Most typically,
+  it will be partnered with a ``feature`` or ``fix`` label.
 
 # Joint Feature and Platform review
 

doc/_release-notes/template.txt

@@ -7,6 +7,8 @@ released: YYYY-MM-DD
 
 # Announcements
 
+<!-- <relnotes for announcements go here> -->
+
 * None
 
 # Breaking changes since v{prior_version}

tools/release_engineering/relnotes.py

@@ -311,6 +311,7 @@ def _update(args, notes_filename, gh, drake, target_commit):
             "breaking change": "breaking-changes",
             "newly deprecated": "newly-deprecated",
             "removal of deprecated": "deprecated-removed",
+            "announce": "announcements",
         }
         primary_used = False
         for severity in severities: