#221: Reduce Blocker Bug Review Meeting Length
--------------------------+-------------------------------------------------
Reporter: tflink | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 16
Component: Trac | Version:
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Comment (by tflink):
My first thought is to extend the same process that we're already using
for accepted/rejected blockers and NTH.
* Use a whiteboard keyword to indicate initial processing
* Severity, number of users impacted, possible workarounds, criteria
violation would need to be determined in order to be tagged
* Once proposed blockers are tagged as "processed" they can be reviewed
in the meeting.
* Bugs not tagged as processed would not be reviewed.
This way, we could do more of the research ahead of time and spend less
meeting time trying to answer the same questions for every new issue.
To facilitate processing, we could start with something similar to the
[https://fedoraproject.org/wiki/Current_Release_Blockers current release
blocker page] that is created from BZ data.
Eventually, it might be nice to have a bot go through the "unprocessed"
bugs and add a comment requesting that the reporter(s) and developer(s)
supply the information needed to process the bug. Something along the
lines of what is already in
[https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting#Requesting_Status_Before_The_Meeting
the blocker bug review meeting SOP]. However, the bot part could be done
later.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/221#comment:1>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
