On Mon, 2019-06-17 at 09:20 -0400, pmkellly@frontier.com wrote:

Proposed additions to the Blocker Bug Procedure to cover Last Minute Blocker Bugs (tidied up version). In case we cover this today at the QA meeting.

Thanks for this, Pat, and sorry for the late reply. I will put this on the agenda for the next QA meeting, as we should move forward with it. For convenience, I'm reproducing Pat's proposal in plain text below. For clarity, the proposed text would be added to this page: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Reviewing_blocker_...

===

Reviewing Blocker Bugs:

(The following would be inserted after the second paragraph under the above section title I know we don't use indented paragraph numbering, it's an old long established habit. The advantage is that subordination is visually clear.)

3 Exceptions for Last Minute Proposed Blocker Bugs

3.1 The team must agree according to the two prior paragraphs in this section, that a Last Minute Proposed Blocker Bug has the character of a Blocker Bug before being process per this section.

3.2 A Last Minute Blocker Bug shall be evaluated for being delayed to the next release cycle according to the criteria below. A Last Minute Proposed Blocker Bug that meets any of the listed criteria may be delayed to the next release cycle as a Blocker Bug if the team agrees. Other Last Minute Proposed Blocker Bugs must be corrected before the current cycle Final Release.

3.2.1 Any bug that can not be fixed in a reasonable amount of time considering the current Release Cycle or due to complexity or resource constraints.

3.2.2 Any bug in non-vital system operation or release package installed application operation.

4 Delaying the current Release:

4.1 Delaying the current release cycle must take into account all of the following criteria.

4.1.1 Consider if the cause of the delay should have been caught earlier in the current cycle. What changes in process could help moving such discoveries earlier in the cycle?

4.1.2 Adding the current proposed delay to any prior delays, is the total delay becoming unacceptable in regard to Fedora release policy?

4.1.3 Will the current proposed delay enable other desirable work to be completed for the release?

4.1.4 Impact on down stream projects.

===

Overall I think I like your proposal more than my old one; it's clearer and more concise. I do think it'd be nice to start with a short preamble explaining what's going on, though, rather than just introducing the concept of a "Last Minute Blocker Bug" without explanation and then diving into procedural stuff. I also personally prefer less unnecessary capitalization. :P

I also have a few trivial wordsmithing notes - e.g. I wouldn't refer to "the team" as that's not wording used in the rest of the document; I'd use a form of words referring to the stakeholder groups, as that's what we do elsewhere in the page. But those probably aren't worth going through in exhaustive detail; if we can all broadly agree on a text we can make minor tweaks to it when actually updating the wiki.

Thanks again for the draft!