diff --git a/docs/release-playbook.md b/docs/release-playbook.md
index c963760bbf..b7ce61d68d 100644
--- a/docs/release-playbook.md
+++ b/docs/release-playbook.md
@@ -77,8 +77,8 @@ While the release is active, you should make sure to do the following:
     *   Before closing a release blocker issue, add a comment indicating how the issue was resolved, for better tracking (e.g. `cherry-picked in #XYZ` - see [this example](https://github.com/bazelbuild/bazel/issues/16629#issuecomment-1302743541))
 *   Periodically check downstream tests that are run against the release branch to catch any breakages early on in the process. If you see any failures that don't appear at HEAD, reach out to the Bazel team, open an issue if needed, and add the issue to the release blockers list.
 *   When enough PRs have been cherry-picked and the release is nearing a ready state, create a release candidate (see [below](#create-a-release-candidate)).
-    *   One week before pushing the final release candidate, go through all the remaining issues on the milestone to triage and add the "nice-to-have" label.
-    *   When a few days pass and no more release blockers show up, push the candidate as the release (issues and pull requests with the "nice-to-have" labels can move to the next release if they are not resolved/merged yet). Otherwise, rinse and repeat the steps above. 
+    *   One week before pushing the final release candidate, go through all the remaining issues on the milestone to triage and add the "soft-release-blocker" label.
+    *   When a few days pass and no more release blockers show up, push the candidate as the release (issues and pull requests with the "soft-release-blocker" labels can move to the next release if they are not resolved/merged yet). Otherwise, rinse and repeat the steps above. 
 *   Keep the task list in the release tracking issue updated and check boxes as you follow the release process.
     *   In particular, try and keep the estimated release date updated.
 *   If there is a request to backport a fix to a previous minor release, then add the "potential N.x cherry-picks" label (for example, if we just released 7.2.0 release, but there is a request to make some changes to fix 6.4.0, then we should put the label, "potential 6.x cherry-picks" label). If there are about five or more issues/PRs with the label, then we should start a discussion to release a new minor release for the previous LTS track.