QA:SOP Blocker Bug Meeting

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Corrected <pre> block that wasn't displaying properly)
(add a 'three hour time limit' section and replace #fedora-bugzappers with #fedora-blocker-review in line with idea of using a dedicated channel, per thread "Proposed changes to blocker bug meeting processes")
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Blocker Bug Meeting SOP =
+
= Background =
 
+
== 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.
 
* 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.
+
* These meetings are a part of the [[QA:SOP_blocker_bug_process]] and the [[QA:SOP_freeze_exception_bug_process]], and their purpose is to review proposed blocker and freeze exception bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and freeze exception 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.
 
* 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.
 
* 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 ==
+
= Meeting Setup =
  
=== 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>
 
<ul>
Line 18: Line 16:
 
or run:
 
or run:
 
   date -d '2010-03-19 16:00 UTC'</pre>
 
   date -d '2010-03-19 16:00 UTC'</pre>
</li><li>Place: #fedora-bugzappers on irc.freenode.net
+
</li><li>Place: [irc://irc.freenode.net/fedora-meeting #fedora-blocker-review] on irc.freenode.net
</li><li>Link to blocker tracker bug to be reviewed (send tree display version)
+
</li><li>Link to [http://qa.fedoraproject.org/blockerbugs/current list of bugs to be reviewed] from the blocker bug tracking webapp
</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>Link to the appropriate [[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><li>List of bugs to be reviewed.  A simple way to obtain this list by supplying the tracker bug number is:
+
</li><li>Link to the [[QA:SOP_blocker_bug_process]] and [[QA:SOP_freeze_exception_bug_process]]
<pre>bugzilla query --blocked=611991 \
+
</li><li>Link to this page
  --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>
 
</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].  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.
+
* 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.   
Line 39: Line 34:
  
 
<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 {{FedoraVersion|long|next}} 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
 
still unresolved by Friday, July 23, 2010, we would appreciate your attendance
 
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
+
at the {{FedoraVersion|long|next}} Alpha blocker meeting on freenode in the #fedora-blocker-review
 
channel at 16:00 UTC.
 
channel at 16:00 UTC.
  
 
The following information would be very helpful to have prior to Friday:
 
The following information would be very helpful to have prior to Friday:
a) whether you believe it is truly a blocker bug
+
a) whether you believe it is truly a blocker bug, and if so, which of the
 +
https://fedoraproject.org/wiki/Fedora_Release_Criteria it infringes
 
b) what additional information you need to troubleshoot or fix this bug
 
b) what additional information you need to troubleshoot or fix this bug
 
c) When you estimate having a fix ready
 
c) When you estimate having a fix ready
Line 59: Line 55:
 
This blocker bug has been marked as fixed.  If possible could you verify that
 
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 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
+
this task and adding a comment to this bug prior to the next {{FedoraVersion|long|next}} Alpha
 
Blocker meeting on Friday, July 23, 2010, would be most appreciated.
 
Blocker meeting on Friday, July 23, 2010, would be most appreciated.
  
Line 67: Line 63:
 
</li></ul>
 
</li></ul>
  
== In Action ==
+
= In Action =
  
The meeting leader should start the meeting and link to:
+
== Quorum ==
# 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.
+
Minimum active attendance for a meeting is three people, ideally one representing each of the stakeholder groups. If active attendance at the meeting drops below three people at any point, it must be ended or suspended until more people join.
  
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 ...
+
== Three hour time limit ==
# The meeting leader then sets the meeting topic to each bug on the list in turn (#topic bugurl)
+
 
 +
Blocker meeting should usually run for a maximum of three hours. Experience indicates that beyond this amount of time, participation and attention levels drop significantly. If a meeting has run for three hours and all bugs have not yet been covered, the meeting leader should [[#Tear_Down|wind up the meeting and organize a follow-up meeting to complete the work]], usually to take place the following day.
 +
 
 +
== Introduction ==
 +
 
 +
The meeting leader should open [http://qa.fedoraproject.org/blockerbugs/current/irc the blocker bug webapp's IRC page] in a text editor. This link will give you a template for running the meeting: introduction text and text for each bug which you can copy and paste straight into the meeting channel. It will be up to date as of the time you access the page.
 +
 
 +
The meeting leader should join [irc://irc.freenode.net/fedora-meeting #fedora-blocker-review] on irc.freenode.net and get the meeting started.  Use the [[Zodbot#Meeting_Functions|meetbot]] commands below to help capture minutes and direct the flow of the meeting.
 +
 
 +
# The meeting leader should start the meeting using the following lines:
 +
#* <code>#startmeeting FXX-blocker-review</code>
 +
#* <code>#meetingname FXX-blocker-review</code>
 +
#* <code>#topic Introduction</code>
 +
#* <code>Why are we here?</code>
 +
#* <code>#info Our purpose in this meeting 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.</code>
 +
#* <code>#info We'll be following the process outlined at:</code>
 +
#* <code>#link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting</code>
 +
#* <code>#info The bugs up for review today are available at:</code>
 +
#* <code>#link http://qa.fedoraproject.org/blockerbugs/current</code>
 +
#* <code>#info The criteria for release blocking bugs can be found at:</code>
 +
#* <code>#link https://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria</code>
 +
#* <code>#link https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria</code>
 +
#* <code>#link https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria</code>
 +
# The meeting leader should then paste the counts of proposed and accepted blocker and freeze exception bugs from the top of the IRC template.
 +
# 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.
 +
 
 +
== Review Proposed Blocker Bugs ==
 +
 
 +
Next, proceed through the list of bugs.  First, review the proposed [[QA:SOP_blocker_bug_process|blocker bugs]]. For each bug, this is the process:
 +
 
 +
# The meeting leader pastes the #topic, #link and #info lines from the IRC template
 
# 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 [[Fedora_Release_Criteria|Release Criteria]] for the release in question
 
# 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 [[Fedora_Release_Criteria|Release Criteria]] for the release in question
# If the bug is agreed to be a blocker, the bug secretary should add the word <code>AcceptedBlocker</code> (with that exact spelling and case) to the ''Whiteboard'' field
+
#* All meeting attendees can vote +1 or -1 to blocker status during discussion, and change their vote at any time
# 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 use every effort to try and reach strong consensus on the bug's status
# The meeting leader should summarize the discussion with <code>#agreed</code> and <code>#info</code> 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 <code>#action</code> item before moving on. For assistance hosting IRC meetings, see [[Zodbot#Meeting_Functions]].
+
#* If all such efforts fail, the meeting leader should tally the votes and propose an action based on the majority opinion. The meeting leader should consider only votes from members of the stakeholder groups (development, release engineering, QA and project management) in such a tally
# 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 [[BugZappers/StockBugzillaResponses#Blocker_Bug_Removal|removing blocker status]] and [[BugZappers/StockBugzillaResponses#Blocker_Bug_Downgrade_to_Target|downgrading to Target]]).
+
#* Use plenty of <code>#info ...</code> tags to record additional notes on the bug
 +
#* After discussion, the leader will seek feedback on a proposed action <code>proposed #agreed 123456 - accepted|rejected as a release blocker</code>
 +
#* Attendees can 'ack', 'nack' or 'patch' the proposed action, as a mechanism for catching typos or suggesting refinements. The meeting leader can adjust the proposed action at their discretion
 +
# The group should also consider the status of work on fixing the bug. It should be clear who currently has responsibility for each blocker bug and what the next required action is on each bug
 +
#* <code>#action tester - Will attempt to reproduce the issue reported  in 123456</code>
 +
#* <code>#action developer - Expects to have a patch available for testing later today</code>
 +
# The meeting leader should summarize the discussion with <code>#agreed</code> and <code>#info</code> 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 <code>#action</code> item before moving on.
 +
#* <code>#agreed 123456 - accepted|rejected as a release blocker</code>
 +
#* In some cases it may be impossible to make a definite decision until more information is available. In this case, use <code>#agreed 123456 - unable to determine status with currently available information</code>, and ensure there is an action item for someone to make sure the necessary information is available for the next meeting
 +
# Lastly, as directed in the [[QA:SOP_blocker_bug_process]], the bug secretary should update the bug report ''Comments'', ''Blocks:'' and ''Whiteboard'' fields as appropriate
 +
#* Summarize the meeting discussion in a new comment (see suggested stock responses for [[BugZappers/StockBugzillaResponses#Blocker_Bug_Removal|removing blocker status]] and [[BugZappers/StockBugzillaResponses#Blocker_Bug_Downgrade_to_Target|downgrading to Target]]).
 +
#* If the bug is agreed to be a blocker, add the text <code>AcceptedBlocker</code> (with that exact spelling and case) to the ''Whiteboard'' field
 +
#* If the bug is agreed to '''not''' be a blocker, add the text <code>RejectedBlocker</code> (with that exact spelling and case) to the ''Whiteboard'' field, and remove the blocker tracker bug from the Blocks: field
 +
#* If the decision could not be made, do not add any text to the ''Whiteboard'' field
  
 
{{admon/tip|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.}}
 
{{admon/tip|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
+
== Review Accepted Blocker Bugs ==
  
== Tear Down ==
+
The meeting should also review all existing accepted blocker bugs to ensure work is progressing on fixing them. Blocker status can be re-discussed and re-voted on if there is a reason to do so, otherwise the meeting should focus on ensuring the next steps in fixing the bug are clarified and the meeting leader should ensure appropriate #info and #action tags are added.
 +
 
 +
== Review Proposed Freeze Exception Bugs ==
 +
 
 +
Using the same procedure outlined above, review the [[QA:SOP_freeze_exception_bug_process|freeze exception bugs]]. It is not necessary to review previously accepted freeze exception bugs, in most cases. The Whiteboard fields for freeze exception bugs are ''AcceptedFreezeException'' and ''RejectedFreezeException''.
 +
 
 +
== Review <code>CLOSED</code>, but not <code>VERIFIED</code> Blocker Bugs ==
 +
If time and energy remain, the meeting leader may quickly review the list of previously <code>AcceptedBlocker</code> bugs that have been <code>CLOSED</code>, but were '''not''' <code>VERIFIED</code>.  This is intended as a quick review to highlight any critical bugs where additional testing is desired.  Use the queries below to find applicable bugs.
 +
 
 +
* [https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&type0-1-0=equals&order=Importance&value0-1-0=Tracking&field0-1-0=keywords&field0-0-0=alias&type0-0-0=regexp&value0-0-0=^{{FedoraVersion|short|next}} List of all {{FedoraVersion|short|next}} Tracking bugs].  Use this query to update the following queries with any new Tracking bugs.
 +
* List of <code>CLOSED</code>, but not <code>VERIFIED</code>, Blocker bugs:
 +
** [https://bugzilla.redhat.com/buglist.cgi?negate1=1&type1-0-0=changedto&type0-1-0=equals&field0-1-0=bug_status&field0-0-0=blocked&value2-0-0=Tracking&field2-0-0=keywords&type2-0-0=nowordssubstr&query_format=advanced&value0-1-0=CLOSED&value1-0-0=VERIFIED&type0-0-0=equals&value0-0-0=657616&field1-0-0=bug_status {{FedoraVersion|short|next}}Alpha]
 +
** [https://bugzilla.redhat.com/buglist.cgi?negate1=1&type1-0-0=changedto&type0-1-0=equals&field0-1-0=bug_status&field0-0-0=blocked&value2-0-0=Tracking&field2-0-0=keywords&type2-0-0=nowordssubstr&query_format=advanced&value0-1-0=CLOSED&value1-0-0=VERIFIED&type0-0-0=equals&value0-0-0=657618&field1-0-0=bug_status {{FedoraVersion|short|next}}Beta]
 +
** [https://bugzilla.redhat.com/buglist.cgi?negate1=1&type1-0-0=changedto&type0-1-0=equals&field0-1-0=bug_status&field0-0-0=blocked&value2-0-0=Tracking&field2-0-0=keywords&type2-0-0=nowordssubstr&query_format=advanced&value0-1-0=CLOSED&value1-0-0=VERIFIED&type0-0-0=equals&value0-0-0=617261&field1-0-0=bug_status {{FedoraVersion|short|next}}Blocker]
 +
* List of <code>CLOSED</code>, but not <code>VERIFIED</code>, freeze exception bugs:
 +
** [https://bugzilla.redhat.com/buglist.cgi?negate1=1&type1-0-0=changedto&type0-1-0=equals&field0-1-0=bug_status&field0-0-0=blocked&value2-0-0=Tracking&field2-0-0=keywords&type2-0-0=nowordssubstr&query_format=advanced&value0-1-0=CLOSED&value1-0-0=VERIFIED&type0-0-0=equals&value0-0-0=657617&field1-0-0=bug_status {{FedoraVersion|short|next}}Alpha Freeze Exception]
 +
** [https://bugzilla.redhat.com/buglist.cgi?negate1=1&type1-0-0=changedto&type0-1-0=equals&field0-1-0=bug_status&field0-0-0=blocked&value2-0-0=Tracking&field2-0-0=keywords&type2-0-0=nowordssubstr&query_format=advanced&value0-1-0=CLOSED&value1-0-0=VERIFIED&type0-0-0=equals&value0-0-0=657619&field1-0-0=bug_status {{FedoraVersion|short|next}}Beta Freeze Exception]
 +
** [https://bugzilla.redhat.com/buglist.cgi?negate1=1&type1-0-0=changedto&type0-1-0=equals&field0-1-0=bug_status&field0-0-0=blocked&value2-0-0=Tracking&field2-0-0=keywords&type2-0-0=nowordssubstr&query_format=advanced&value0-1-0=CLOSED&value1-0-0=VERIFIED&type0-0-0=equals&value0-0-0=657621&field1-0-0=bug_status {{FedoraVersion|short|next}} Freeze Exception]
 +
 
 +
== Open discussion ==
 +
While the meeting can run long, if time remains, it is nice to open up the meeting for any feedback or bugs not already discussed.
 +
* <code>#topic Open Discussion <your bugs here></code>
 +
 
 +
= Tear Down =
 +
 
 +
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
  
Send a summary of the meeting's findings and action items to [https://admin.fedoraproject.org/mailman/listinfo/devel devel@lists.fedoraproject.org] and [https://admin.fedoraproject.org/mailman/listinfo/test test@lists.fedoraproject.org].  As part of the email include information about the date and time of the next meeting.
+
# Confirm the next meeting time and date
 +
#* <code>#info Next meeting time - XX:XX UTC on $date</code>
 +
# Thank participants, and close the meeting
 +
#* <code>#endmeeting</code>
 +
# Send a summary of the meeting's findings and action items to [https://admin.fedoraproject.org/mailman/listinfo/test-announce test-announce@lists.fedoraproject.org].  As part of the email include information about the date and time of the next meeting.
  
 
[[Category:QA SOPs]]
 
[[Category:QA SOPs]]

Revision as of 05:06, 7 March 2013

Contents

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_freeze_exception_bug_process, and their purpose is to review proposed blocker and freeze exception bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and freeze exception 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:

Reminders

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 {{FedoraVersion|long|next}} 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 {{FedoraVersion|long|next}} Alpha blocker meeting on freenode in the #fedora-blocker-review
    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, and if so, which of the
    https://fedoraproject.org/wiki/Fedora_Release_Criteria it infringes
    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 {{FedoraVersion|long|next}} Alpha
    Blocker meeting on Friday, July 23, 2010, would be most appreciated.
    
    Thank you,
    your name
    

In Action

Quorum

Minimum active attendance for a meeting is three people, ideally one representing each of the stakeholder groups. If active attendance at the meeting drops below three people at any point, it must be ended or suspended until more people join.

Three hour time limit

Blocker meeting should usually run for a maximum of three hours. Experience indicates that beyond this amount of time, participation and attention levels drop significantly. If a meeting has run for three hours and all bugs have not yet been covered, the meeting leader should wind up the meeting and organize a follow-up meeting to complete the work, usually to take place the following day.

Introduction

The meeting leader should open the blocker bug webapp's IRC page in a text editor. This link will give you a template for running the meeting: introduction text and text for each bug which you can copy and paste straight into the meeting channel. It will be up to date as of the time you access the page.

The meeting leader should join #fedora-blocker-review on irc.freenode.net and get the meeting started. Use the meetbot commands below to help capture minutes and direct the flow of the meeting.

  1. The meeting leader should start the meeting using the following lines:
  2. The meeting leader should then paste the counts of proposed and accepted blocker and freeze exception bugs from the top of the IRC template.
  3. 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.

Review Proposed Blocker Bugs

Next, proceed through the list of bugs. First, review the proposed blocker bugs. For each bug, this is the process:

  1. The meeting leader pastes the #topic, #link and #info lines from the IRC template
  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
    • All meeting attendees can vote +1 or -1 to blocker status during discussion, and change their vote at any time
    • The meeting leader should use every effort to try and reach strong consensus on the bug's status
    • If all such efforts fail, the meeting leader should tally the votes and propose an action based on the majority opinion. The meeting leader should consider only votes from members of the stakeholder groups (development, release engineering, QA and project management) in such a tally
    • Use plenty of #info ... tags to record additional notes on the bug
    • After discussion, the leader will seek feedback on a proposed action proposed #agreed 123456 - accepted|rejected as a release blocker
    • Attendees can 'ack', 'nack' or 'patch' the proposed action, as a mechanism for catching typos or suggesting refinements. The meeting leader can adjust the proposed action at their discretion
  3. The group should also consider the status of work on fixing the bug. It should be clear who currently has responsibility for each blocker bug and what the next required action is on each bug
    • #action tester - Will attempt to reproduce the issue reported in 123456
    • #action developer - Expects to have a patch available for testing later today
  4. The meeting leader should summarize the discussion with #agreed and #info 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.
    • #agreed 123456 - accepted|rejected as a release blocker
    • In some cases it may be impossible to make a definite decision until more information is available. In this case, use #agreed 123456 - unable to determine status with currently available information, and ensure there is an action item for someone to make sure the necessary information is available for the next meeting
  5. Lastly, as directed in the QA:SOP_blocker_bug_process, the bug secretary should update the bug report Comments, Blocks: and Whiteboard fields as appropriate
    • Summarize the meeting discussion in a new comment (see suggested stock responses for removing blocker status and downgrading to Target).
    • If the bug is agreed to be a blocker, add the text AcceptedBlocker (with that exact spelling and case) to the Whiteboard field
    • If the bug is agreed to not be a blocker, add the text RejectedBlocker (with that exact spelling and case) to the Whiteboard field, and remove the blocker tracker bug from the Blocks: field
    • If the decision could not be made, do not add any text to the Whiteboard field
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.

Review Accepted Blocker Bugs

The meeting should also review all existing accepted blocker bugs to ensure work is progressing on fixing them. Blocker status can be re-discussed and re-voted on if there is a reason to do so, otherwise the meeting should focus on ensuring the next steps in fixing the bug are clarified and the meeting leader should ensure appropriate #info and #action tags are added.

Review Proposed Freeze Exception Bugs

Using the same procedure outlined above, review the freeze exception bugs. It is not necessary to review previously accepted freeze exception bugs, in most cases. The Whiteboard fields for freeze exception bugs are AcceptedFreezeException and RejectedFreezeException.

Review CLOSED, but not VERIFIED Blocker Bugs

If time and energy remain, the meeting leader may quickly review the list of previously AcceptedBlocker bugs that have been CLOSED, but were not VERIFIED. This is intended as a quick review to highlight any critical bugs where additional testing is desired. Use the queries below to find applicable bugs.

Open discussion

While the meeting can run long, if time remains, it is nice to open up the meeting for any feedback or bugs not already discussed.

  • #topic Open Discussion <your bugs here>

Tear Down

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

  1. Confirm the next meeting time and date
    • #info Next meeting time - XX:XX UTC on $date
  2. Thank participants, and close the meeting
    • #endmeeting
  3. Send a summary of the meeting's findings and action items to test-announce@lists.fedoraproject.org. As part of the email include information about the date and time of the next meeting.