Update bugs guide to use "Blocks Release" field.

Also tweaked the bug reporting steps to better reflect our actually
current workflow.

re #2343
https://pulp.plan.io/issues/2343

docs/dev-guide/contributing/bugs.rst

@@ -46,6 +46,17 @@ necessary, the bug may be commented on requesting more information or
 clarification from the reporter. When a bug has enough information, its
 *Priority* rating set and is marked as triaged using the *Triaged* boolean.
 
+Blocking Bugs
+-------------
+
+All Redmine Issues have a "Blocks Release" field. This field refers to upcoming
+Platform Release versions that *cannot* be released until this bug is fixed.
+
+For example, if a blocking issues is discovered in Pulp 2.4.6, and 2.4.7 is the next Platform
+Release version, then the issue's "Blocks Release" field should be set to ``2.4.z``. If the bug
+also affects the next Platform Release of Pulp, such as 2.5.2, the issue's "Block Release" field
+should also include ``2.5.z``.
+
 .. _security disclosures:
 
 Security Disclosures
@@ -78,23 +89,25 @@ Developer
    state to ``ASSIGNED``.
 #. The developer creates a new remote branch for the bug on their GitHub fork.
 #. When the fix is complete, the developer submits a pull request for the bug into the appropriate
-   branch (master, release branch, etc.). It's appreciated by the reviewer if a link to the bug
-   is included in the merge request, as well as a brief description of what the change is. It is
-   not required to find and assign someone to do the review.
+   branch (master, release branch, etc.). A link to the bug should be included in the merge request,
+   as well as a brief description of what the change is. It is not required to find and assign
+   someone to do the review.
 #. When the pull request is submitted, the developer changes the status of the bug to ``POST`` and
-   sets the appropriate target release.
-#. Wait for someone to review the pull request. The reviewer will assign the pull request back to
-   the developer when done and should also ping them through other means. The developer may take
-   the reviewer's comments as they see fit and merge the pull request when satisfied. Once merged,
-   set bug status to ``MODIFIED``. It is also helpful to include a link to the pull request in a
-   comment on the bug.
+   includes a link to the open pull request.
+#. Wait for someone to review the pull request. The reviewer(s) will either approve the pull request
+   or request changes that must be addressed before the pull request can be merged. Pull requests
+   should have at least one approved review and no reviews requesting changes before being merged.
+   Once merged, set the bug status to ``MODIFIED``. If the next platform release version is known,
+   set the "Platform Release" field appropriately. Otherwise, leave it blank and it will be set
+   during the next platform bugfix release.
 #. Delete both local and remote branches for the bug.
 
 .. note::
   See :doc:`branching` for more information on how to create branches for bug fixes.
 
 Reviewer
 ^^^^^^^^
+
 #. When reviewing a pull request, all feedback is appreciated, including compliments, questions,
    and general Python knowledge. It is up to the developer to decide what (if any) changes will
    be made based on each comment.
@@ -147,8 +160,8 @@ Priorities are defined as follows.
 ========    ===============================================================================
 Priority    Description
 ========    ===============================================================================
-Urgent      Extremely important, such as issues that must be fixed before the next release.
-High        Very important, but not blocking the next release.
+Urgent      Most important. Non-Urgent issues should not be worked on before this issue.
+High        Very important, generally worked on after Urgent Priority issues.
 Normal      Average importance, generally worked on after High Priority issues.
 Low         Not very important, generally worked on after Normal Priorty issues.
 ========    ===============================================================================

docs/dev-guide/contributing/building.rst

@@ -286,15 +286,26 @@ fedorapeople::
 Reconcile Redmine Issues
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Before starting a release build, ensure that there are no issues in a ``MODIFIED`` state without
-a Target Platform Release (See the "``MODIFIED`` - No Release" report in Redmine). All ``MODIFIED``
-issues should include a link to the pull request for the related bugfix or feature, and the
-target release can usually be determined by examining the destination branch of the pull
-request. If in doubt, consult with the developer that fixed the issue to know which target
+Before starting a release build, ensure that there are no issues
+blocking the version of Pulp about to be released by checking the
+`Open Blockers <https://pulp.plan.io/projects/pulp/issues?query_id=75>`_ report in Redmine.
+
+If a release is not blocked, make sure that any issues in a ``MODIFIED`` state that apply
+to the branch being released have the Platform Release field set correctly. See the
+`MODIFIED - No Release <https://pulp.plan.io/projects/pulp/issues?query_id=65>`_ report in Redmine
+for a list of issues that are ``MODIFIED`` but not value for the Platform Release field.
+
+All ``MODIFIED`` issues should include a link to the pull request for the related bugfix or feature.
+The target release can be determined by examining the destination branch of the pull request:
+
+* Changes made on an ``x.y-dev`` branch belong in the next bugfix (Z) release.
+* Changes made on master go into the next feature (Y) release.
+
+If in doubt, check with the developer that fixed the issue to determine which target
 release is appropriate.
 
 Similarly, if there are any issues that are ``NEW``, ``ASSIGNED``, or ``POST`` and inappropriately given
-a Target Platform Release, set the Target Platform Release field to none on those issues.
+a Platform Release, set the Platform Release field to none on those issues.
 
 Submit to Koji
 ^^^^^^^^^^^^^^