From Fedora Project Wiki
(drop nth adjustment draft category) |
(Corrected <pre> block that wasn't displaying properly) |
||
| Line 11: | Line 11: | ||
=== Announcement === | === Announcement === | ||
Announce the Blocker Bug Meeting. Include the following important information in the announcement: | Announce the Blocker Bug Meeting. Include the following important information in the announcement: | ||
<ul> | |||
<li>Meeting time in the format: {{#time: H:i | 16:00 UTC}} UTC ({{#timel: H:i | 16:00 UTC - 4 hours}} EDT, {{#timel: H:i | 16:00 UTC + 1 hours}} CET). To help participants convert UTC to their local time, the following text can be used. | |||
<pre> | |||
To convert UTC to your local time, take a look at | |||
http://fedoraproject.org/wiki/Infrastructure/UTCHowto | |||
or run: | |||
date -d '2010-03-19 16:00 UTC'</pre> | |||
</li><li>Place: #fedora-bugzappers on irc.freenode.net | |||
</li><li>Link to blocker tracker bug to be reviewed (send tree display version) | |||
</li><li>Link to nice-to-have tracker. Note, the nice-to-have tracker list always includes the blocker trackers. For example, https://bugzilla.redhat.com/showdependencytree.cgi?id={{FedoraVersion|short|next}}-accepted&hide_resolved=1 | |||
</li><li>List of bugs to be reviewed. A simple way to obtain this list by supplying the tracker bug number is: | |||
<pre>bugzilla query --blocked=611991 \ | |||
--bug_status=NEW,ASSIGNED,ON_DEV,MODIFIED,POST,ON_QA,FAILS_QA,PASSES_QA,REOPENED,VERIFIED,RELEASE_PENDING \ | |||
--outputformat="%{bug_id} :: %{bug_status} :: %{component} :: %{assigned_to} :: %{summary} :: %{url}"</pre> | |||
</li><li>Link to the apropriate [[Fedora Release Criteria]] (e.g. [[Fedora_{{FedoraVersionNumber|next}}_Alpha_Release_Criteria|Alpha]], [[Fedora_{{FedoraVersionNumber|next}}_Beta_Release_Criteria|Beta]] or [[Fedora_{{FedoraVersionNumber|next}}_Final_Release_Criteria|Final]]) to guide decision making during the meeting | |||
</li></ul> | |||
=== Reminders === | === Reminders === | ||
* Two days before the meeting, send reminder 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]. Both the [https://admin.fedoraproject.org/mailman/listinfo/devel devel] and [[https://admin.fedoraproject.org/mailman/listinfo/test test] mailing lists are subscribed to [https://admin.fedoraproject.org/mailman/listinfo/test-announce test-announce], so no additional announcements are needed. | ||
=== Requesting Status Before The Meeting === | === Requesting Status Before The Meeting === | ||
The meeting is most productive when we have the latest information to work with. Often this requires specifically requesting more information in the bug. Review each of the open blocker bugs and review the comments to see if the bug is progressing. | The meeting is most productive when we have the latest information to work with. Often this requires specifically requesting more information in the bug. Review each of the open blocker bugs and review the comments to see if the bug is progressing. | ||
Here are some examples text that might help solicit information: | If the bug does not appear to be making progress, request more information. Here are some examples text that might help solicit information: | ||
<ul><li> Set the bug to ''needinfo-assignee'' ... | |||
<pre> | <pre> | ||
Please help us save time at this week's Fedora 14 Alpha Blocker Bug review | Please help us save time at this week's Fedora 14 Alpha Blocker Bug review | ||
meeting by adding your comments on the assessment of this bug. If this bug is | meeting by adding your comments on the assessment of this bug. If this bug is | ||
| Line 52: | Line 52: | ||
Thank you, | Thank you, | ||
your name | your name | ||
</pre> | </pre> | ||
</li><li>Set the bug to ''needinfo-reporter'' | |||
<pre> | <pre> | ||
Dear Bug Reporter, | Dear Bug Reporter, | ||
| Line 68: | Line 64: | ||
Thank you, | Thank you, | ||
your name | your name | ||
</pre> | </pre> | ||
</li></ul> | |||
== In Action == | == In Action == | ||
Revision as of 19:28, 24 November 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.
- These meetings are a part of the QA:SOP_blocker_bug_process and the QA:SOP_nth_bug_process, and their purpose is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
- 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.
- 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.
Meeting Setup
Announcement
Announce the Blocker Bug Meeting. Include the following important information in the announcement:
- Meeting time in the format: 16:00 UTC (12:00 EDT, 17:00 CET). To help participants convert UTC to their local time, the following text can be used.
To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2010-03-19 16:00 UTC'
- Place: #fedora-bugzappers on irc.freenode.net
- Link to blocker tracker bug to be reviewed (send tree display version)
- Link to nice-to-have tracker. Note, the nice-to-have tracker list always includes the blocker trackers. For example, https://bugzilla.redhat.com/showdependencytree.cgi?id=F42-accepted&hide_resolved=1
- List of bugs to be reviewed. A simple way to obtain this list by supplying the tracker bug number is:
bugzilla query --blocked=611991 \ --bug_status=NEW,ASSIGNED,ON_DEV,MODIFIED,POST,ON_QA,FAILS_QA,PASSES_QA,REOPENED,VERIFIED,RELEASE_PENDING \ --outputformat="%{bug_id} :: %{bug_status} :: %{component} :: %{assigned_to} :: %{summary} :: %{url}" - Link to the apropriate Fedora Release Criteria (e.g. Alpha, Beta or Final) to guide decision making during the meeting
Reminders
- Two days before the meeting, send reminder to test-announce@lists.fedoraproject.org. Both the devel and [test mailing lists are subscribed to test-announce, so no additional announcements are needed.
Requesting Status Before The Meeting
The meeting is most productive when we have the latest information to work with. Often this requires specifically requesting more information in the bug. Review each of the open blocker bugs and review the comments to see if the bug is progressing.
If the bug does not appear to be making progress, request more information. Here are some examples text that might help solicit information:
- Set the bug to needinfo-assignee ...
Please help us save time at this week's Fedora 14 Alpha Blocker Bug review meeting by adding your comments on the assessment of this bug. If this bug is still unresolved by Friday, July 23, 2010, we would appreciate your attendance at the Fedora 14 Alpha blocker meeting on freenode in the #fedora-bugzappers channel at 16:00 UTC. The following information would be very helpful to have prior to Friday: a) whether you believe it is truly a blocker bug b) what additional information you need to troubleshoot or fix this bug c) When you estimate having a fix ready Thank you, your name
- Set the bug to needinfo-reporter
Dear Bug Reporter, This blocker bug has been marked as fixed. If possible could you verify that this problem is in fact fixed in the latest build? Your help in completing this task and adding a comment to this bug prior to the next Fedora 14 Alpha Blocker meeting on Friday, July 23, 2010, would be most appreciated. Thank you, your name
In Action
The meeting leader should start the meeting and link to:
- The bug list s/he will be working from
- 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. Address blocker bugs first. Address nice-to-have bugs after the blocker bugs, if time / motivation remain. For each bug ...
- 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
- 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 - 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
- The meeting leader should summarize the discussion with
#agreedand#infobefore 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#actionitem before moving on. For assistance hosting IRC meetings, see Zodbot#Meeting_Functions. - 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 (see suggested stock responses for removing blocker status and downgrading to Target).
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.
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.