QA:SOP Blocker Bug Meeting

Blocker Bug Meeting SOP

Background

• Most Fedora events should be self-hosting and capable of being led by non-subject matter experts. This SOP sets forth how to arrange and lead a Blocker Bug Meeting.
• Proactive review and handling of blocker bug lists is the one of the best ways to make sure our releases ship as closely on time as possible. During the Fedora 12 release cycle, several Blocker Bug Days are explicitly scheduled to make this a reality.
• Blocker Bug Meetings are not owned by any one team in Fedora. They are a collaborative effort between Release Engineering, Quality Assurance, Development, and Project Management.

Setup

• Announce the Blocker Bug Meeting. Important information to include is:
  • Meeting time: 17:00 UTC (1 PM EDT)
  • Place: #fedora-bugzappers on irc.freenode.net
  • Link to blocker bug to be reviewed (send tree display version). For example: https://bugzilla.redhat.com/showdependencytree.cgi?id=446451&hide_resolved=1
  • Link to the criteria used to determine a blocker bug <<FIXME>>
• Announce the Blocker Bug Meeting to fedora-test-list@redhat.com and fedora-devel-list one week before the meeting.
• Send a reminder email about the Blocker Bug Meeting to fedora-test-list@redhat.com and fedora-devel-list one day before the meeting.

In Action

• Identify a person to capture action and after-meeting follow-up items. Most of this can be captured in the individual bugs, but it is nice to send a post meeting summary back to the lists explaining what was accomplished at the meeting, for example, how many bugs were reviewed, and next actions the attendees plan to take. This is also an attractive way to advertise what happens at the meeting to draw more participants.
• FIXME--what is a clear way to explain how a group of people can efficiently review the bugs on the blocker list?
• FIXME--we need a clearer set of criteria for explaining to newbies what constitutes a blocker bug and what doesn't. A decision tree would be excellent! https://fedoraproject.org/wiki/QA/ReleaseCriteria is a good start, but needs to be easier to consume and comprehend.
• FIXME--we need a wiki page that describes what kind of bugs belong on the <Release>Target tracker bug

Tear Down

• Send a summary of the meeting's findings and action items to fedora-devel-list and fedora-test-list. As part of the email include information about the date and time of the next meeting.