On Mon, 2019-06-17 at 09:20 -0400, pmkellly(a)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
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:
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
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!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora