From Fedora Project Wiki

Line 20: Line 20:
*:  date -d '2010-03-19 16:00 UTC'</pre>
*:  date -d '2010-03-19 16:00 UTC'</pre>


Use the following schedule to announce the event.
=== Meeting Reminders ===
* One week before the meeting, send announcement to [https://admin.fedoraproject.org/mailman/listinfo/test-announce test-announce@lists.fedoraproject.org]
* Two days before the meeting, send reminder to [https://admin.fedoraproject.org/mailman/listinfo/test-announce test-announce@lists.fedoraproject.org] and [https://admin.fedoraproject.org/mailman/listinfo/devel devel@lists.fedoraproject.org]
* Two days before the meeting, send reminder to [https://admin.fedoraproject.org/mailman/listinfo/test test@lists.fedoraproject.org] and [https://admin.fedoraproject.org/mailman/listinfo/devel devel@lists.fedoraproject.org]


== In Action ==
== In Action ==

Revision as of 13:50, 15 July 2010

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. Include the following important information in the announcement:

Meeting Reminders

In Action

The meeting leader should start the meeting and link to

  1. The bug list s/he will be working from
  2. This page, reminder attendees the purpose and scope of the meeting

The meeting leader should find someone who is willing to act as a bug secretary, making changes to bugs in Bugzilla as necessary. This role can be shared around during the meeting if desired.

Next, proceed through the list of bugs. For each bug ...

  1. The meeting leader then sets the meeting topic to each bug on the list in turn (#topic bugurl)
  2. 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
  3. If the bug is agreed to be a blocker, the bug secretary should add the word AcceptedBlocker (with that exact spelling and case) to the Whiteboard field
  4. 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
  5. 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
  6. Lastly, the bug secretary 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
Idea.png
Need more time?
Sometimes it is difficult to reach consensus on whether a bug should block a particular milestone. Given that there may be many bugs to review, it is recommended that no more than 5 minutes be spent reviewing a bug. If additional time is needed, note who has the action items to follow-up on the issue after the meeting, and move on to the next bug in the list.

Finally, after the list of bugs has been reviewed, identify who is responsible for the #Tear_Down process. Typically, this is the meeting leader's responsibility, but it doesn't hurt to clearly identify who will be

Tear Down

Send a summary of the meeting's findings and action items to devel@lists.fedoraproject.org and test@lists.fedoraproject.org. As part of the email include information about the date and time of the next meeting.