QA:SOP Blocker Bug Meeting

From FedoraProject

Jump to: navigation, search

1 Background
2 Meeting Setup
3 In Action
4 Tear Down

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=F17-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 15 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 15 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, 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 Fedora 15 Alpha
Blocker meeting on Friday, July 23, 2010, would be most appreciated.

Thank you,
your name

In Action

Introduction

Join #fedora-bugzappers on irc.freenode.net and get the meeting started. Use the meetbot commands below to help capture minutes direct the flow of the meeting.

The meeting leader should start the meeting using the following meeting functions:
- #startmeeting FXX-blocker-review
- #meetingname FXX-blocker-review
- #topic Introduction
The meeting leader should provide the following information at the start of the meeting:
1. The bug list s/he will be working from
  - #link http://bugzilla.redhat.com/...
2. This page, reminder attendees the purpose and scope of the meeting
  - #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_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.

Review Proposed Blocker Bugs

Next, proceed through the list of bugs. First, review the proposed blocker bugs. For each bug, follow the procedure below.

The meeting leader then sets the meeting topic to each bug on the list in turn using the format #topic BUG_URL - BUG_SUMMARY as shown below:
- #topic https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123456 - Crash reported in when doing foo
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
- 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
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
- #action tester - Will attempt to reproduce the issue reported in 123456
- #action developer - Expects to have a patch available for testing later today
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
Lastly, as directed in the QA:SOP_blocker_bug_process, the bug secretary should update the bug report comments 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
- If the decision could not be made, do not add any text to the Whiteboard field

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 Nice-to-have Bugs

Using the same procedure outlined above, review the nice-to-have bugs, and if time / motivation remain, review the untested AcceptedBlocker bugs.

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.

List of all F17 Tracking bugs. Use this query to update the following queries with any new Tracking bugs.
List of CLOSED, but not VERIFIED, Blocker bugs:
List of CLOSED, but not VERIFIED, Nice-to-have 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

Confirm the next meeting time and date
- #info Next meeting time - XX:XX UTC on $date
Thank participants, and close the meeting
- #endmeeting
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.

Retrieved from "https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting"

Category: QA SOPs

Fedora

Personal tools

Views

wiki

Navigation

sub-projects

Search

Toolbox

QA:SOP Blocker Bug Meeting

From FedoraProject

Contents

Background

Meeting Setup

Announcement

Reminders

Requesting Status Before The Meeting

In Action

Introduction

Review Proposed Blocker Bugs

Review Nice-to-have Bugs

Review `CLOSED`, but not `VERIFIED` Blocker Bugs

Open discussion

Tear Down

Fedora

Personal tools

Views

wiki

Navigation

sub-projects

Search

Toolbox

QA:SOP Blocker Bug Meeting

From FedoraProject

Contents

Background

Meeting Setup

Announcement

Reminders

Requesting Status Before The Meeting

In Action

Introduction

Review Proposed Blocker Bugs

Review Nice-to-have Bugs

Review CLOSED, but not VERIFIED Blocker Bugs

Open discussion

Tear Down

Review `CLOSED`, but not `VERIFIED` Blocker Bugs