Rename release blockers

Author: AThousandShips

index.rst

@@ -44,7 +44,7 @@ for your topic of interest. You can also use the search function in the top-left
    triage/about
    triage/workflow
    triage/guidelines
-   triage/release_blockers
+   triage/release_priorities
    triage/sprint_instructions
 
 .. toctree::

triage/release_blockers.rst renamed to triage/release_priorities.rst

@@ -1,30 +1,30 @@
-.. _doc_bug_triage_release_blockers:
+.. _doc_bug_triage_release_priorities:
 
-Release blocker tracking
-========================
+Release priority tracking
+=========================
 
-Release blockers are issues that we aim to fix before we release the
+Release priorities are issues that we aim to fix before we release the
 next version. There are a few different things to consider when
-determining if an issue is a release blocker or not. Generally any bug
+determining if an issue is a release priority or not. Generally any bug
 that has appeared during the current cycle should be considered release
-blockers (and assigned the “regression” label), if the issue isn’t
+priorities (and assigned the “regression” label), if the issue isn’t
 considered critical it will marked as not critical, see
 `severity <#severity>`__ below.
 
-Issues with new features can also be considered release blockers. This
+Issues with new features can also be considered release priorities. This
 is because once a feature is part of a released version (and isn’t
 considered experimental) it is much harder to change how that feature
 works without breaking compatibility (see the `release policy page <https://docs.godotengine.org/en/latest/about/release_policy.html#what-are-the-criteria-for-compatibility-across-engine-versions>`__).
 This means that fixing issues, especially minor issues that wouldn’t be
 critical otherwise, should be done early to avoid compatibility issues
 later.
 
-Release blockers have their own project, `4.x Release Blockers <https://github.com/orgs/godotengine/projects/61>`__.
+Release priorities have their own project, `4.x Release Priorities <https://github.com/orgs/godotengine/projects/61>`__.
 
 Severity
 --------
 
-Release blockers should also be assigned a severity, this is usually
+Release priorities should also be assigned a severity, this is usually
 handled by either the production team or the specific :ref:`area maintainers <doc_areas>`, so this is only a rough
 outline to use to assign this if you are able:
 

triage/workflow.rst

@@ -23,7 +23,7 @@ Triage checklist
    author to add the missing information.
 -  `Check for duplicates <#check-for-duplicates>`__.
 -  Check if the issue is a recent regression. If it is, add it to the
-   :ref:`release blocker tracker <doc_bug_triage_release_blockers>` and
+   :ref:`release priorities <doc_bug_triage_release_priorities>` and
    mark it as a “regression”.
 -  Add initial labels.
 -  `Assign a milestone <#assigning-milestones>`__ if relevant.
@@ -78,7 +78,7 @@ having tested development versions) please either ask the author to test
 with a stable version or test the bug yourself. If it *doesn’t* occur on
 a past release it is considered a regression and should be tagged with
 the “regression” label, and should also be added to the “4.x Release
-Blockers” project. See :ref:`doc_bug_triage_release_blockers` for details.
+Priorities” project. See :ref:`doc_bug_triage_release_priorities` for details.
 
 Try to tag an issue as specifically as possible, adding “needs testing”
 and “needs work” if necessary. Don’t worry about misidentifying issues,
@@ -104,20 +104,20 @@ Note that this is for assigning milestones to *open* issues, please see
 and milestones.
 
 Below is an outline of the different milestones we use, but as a general
-rule you can assume that issues that aren’t release blockers, or
+rule you can assume that issues that aren’t release priorities, or
 specific to ``3.x``, shouldn’t have milestones assigned.
 
 For the ``master`` branch:
 
 * ``4.x``: For Godot 4 in general, i.e. the ``master`` branch. We do not use the ``4.x`` milestone on issues, issues with no milestone are assumed to be relevant for the current development cycle.
-* *The current development version*: Should be assigned to issues that are :ref:`release blockers <doc_bug_triage_release_blockers>`, or otherwise prioritized for the current version.
+* *The current development version*: Should be assigned to issues that are :ref:`release priorities <doc_bug_triage_release_priorities>`, or otherwise prioritized for the current version.
 * *The next release version*: When we enter feature freeze we usually create a new milestone used for PRs that are approved but won’t make it into the current release, this milestone is not used for issues.
 * *Older Godot 4 versions*: This is used for issues that are only relevant for this specific version (or older versions), but not any newer version. An example of this would be an issue that was solved in ``4.5`` as part of an enhancement, but that enhancement cannot be cherry-picked for ``4.4`` and a separate issue is necessary to track the specific solution for ``4.4`` (and older, if relevant). For such issues it can also be relevant to add “[4.4]” at the beginning of the issue title to help clarify it is specific to this version.
 
 For Godot 3:
 
 * ``3.x``: For the ``3.x`` branch in general. Used for issues that are only relevant for the ``3.x`` version, and occurs on the current development version of ``3.x``. For these issues it can also help to add “[3.x]” at the beginning of the issue title to help identifying the issue.
-* Other Godot 3 milestones work the same way as for the ``master`` branch, except we do not track release blockers for ``3.x``.
+* Other Godot 3 milestones work the same way as for the ``master`` branch, except we do not track release priorities for ``3.x``.
 
 Testing an Issue
 ----------------