From Fedora Project Wiki

(update with links to release criteria)
(drop a fixme now we have real release criteria)
Line 26: Line 26:
* 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.
* 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'''--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
* '''FIXME'''--we need a wiki page that describes what kind of bugs belong on the <Release>Target tracker bug



Revision as of 15:58, 7 December 2009

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:
  • Announce the Blocker Bug Meeting to test-announce@lists.fedoraproject.org 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

  • The meeting leader should start the meeting and again link to the bug list s/he will be working from
  • The group should agree on one person to update each bug appropriately in Bugzilla after it has been discussed (the 'bug updater')
  • The meeting leader then sets the meeting topic to each bug on the list in turn (#topic bugurl)
  • The group then agrees whether the bug is still accepted as a blocker; if not, whether it is downgraded to target or dropped from the list entirely. This decision should be based on the Release Criteria for the release in question
  • The group then considers the status of work on fixing each blocker bug. It should be clear who currently has responsibility for each blocker bug and what the next required action is on each bug
  • For each bug, the meeting leader should summarize the discussion with a #agreed item before moving on to the next bug. If specific action beyond the immediate update of the bug report is needed, it should be noted with a #action item before moving on
  • After each bug has been discussed, the bug updater should update the bug report as appropriate, always including a note that the comments and/or changes are a result of the blocker bug meeting
  • 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 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.