release: Extend instructions for the release shepherd

This adds the following:
- Find a new volunteer for the release shepherd if needed.
- Consider experimental features for promotion/demotion.

The latter could need more detailed explanation, but I guess we can
add those once we have the planned metrics for feature flags. For now,
I just wanted to have that point in so that it is not completely
forgotten.

Signed-off-by: beorn7 <beorn@grafana.com>

Co-authored-by: Levi Harrison <git@leviharrison.dev>

RELEASE.md

@@ -70,7 +70,7 @@ If a bug fix got accidentally merged into main after non-bug-fix changes in main
 
 Maintaining the release branches for older minor releases happens on a best effort basis.
 
-### 0. Updating dependencies
+### 0. Updating dependencies and promoting/demoting experimental features
 
 A few days before a major or minor release, consider updating the dependencies.
 
@@ -85,6 +85,10 @@ you can skip the dependency update or only update select dependencies. In such a
 case, you have to create an issue or pull request in the GitHub project for
 later follow-up.
 
+This is also a good time to consider any experimental features and feature
+flags for promotion to stable or for deprecation or ultimately removal. Do any
+of these in pull requests, one per feature.
+
 #### Updating Go dependencies
 
 ```
@@ -155,3 +159,5 @@ For release candidate versions (`v2.16.0-rc.0`), run the benchmark for 3 days us
 If the release has happened in the latest release branch, merge the changes into main.
 
 Once the binaries have been uploaded, announce the release on `prometheus-announce@googlegroups.com`. (Please do not use `prometheus-users@googlegroups.com` for announcements anymore.) Check out previous announcement mails for inspiration.
+
+Finally, in case there is no release shepherd listed for the next release yet, find a volunteer.