Release Management/Engineering Dashboard

Overview of Project

This initial work is part of the GNOME Outreach Program for Women internship that will take place from January 2 - April 2, 2013. Our selected applicant, Lianne Lee, will be working on the first round of design, deployment, and testing for this project. The goal is to end up with a v1.0 dashboard that can be viewed by either individual or team with their bug priorities viewable in a way that encourages 'burning down' on the most sought-after work first.

A second goal of this dashboard is to give the Release Management team a way to view the overall progress for each release & channel's tracked bugs throughout the 6 week cycle so that areas that are being overlooked can be caught quickly, ensuring that the quality of a release is not compromised by missed issues (where that can be known via bug flags & queries).

Design

Goal: To ensure that critical bugs are fixed before a necessary deadline, non-critical fixes still get attention in a timely fashion, and to make obvious what work is assigned or could be assigned to an individual.

P1 Requirements

• Need an account created on bugzilla that can view security bugs
• Ability to drill down the org chart and see bugs per individual and then grouped by team/manager
  • See phonebook script here that already does a little bit of this
  • We'll want to improve our ability to track based on org chart (outreach to managers to put 'manager' in their details, for example, or auto-grouping people based on depth? Other ways to track who is on what team)
• Ability to drill down a bugzilla chart to see related bugs and create groupings (Could add a library in https://github.com/mozilla/bztools that will provide related bugs quickly for a bug)

P2 Requirements

• Graphs to see the bug counts in each list over time - will help managers track progress as well
• Ability to assign bugs and change priority/criticality through the interface

Dashboard spec (by individual)

eg: url/<bugzilla_email>

For work in (Beta, Aurora, Critical, Feature, Nightly) queries:
{{ CHANNEL }}: {{ VERSION }} - {{ STATUS }} (eg: FF18 - Beta 5 goes to build today, shipping on 1/7)
* Sec-critical bugs
* Tracking non-sec bugs
* Unassigned critical bugs in watched components (please take these!)
* Your team's critical bugs

Dashboard spec (by product & component)

eg: url/<product>?<component>

Beta: FF13 (code freeze passed, released in 1 day)
Critical bugs in these components
Aurora: FF14 (code freeze in X days, released in Y days)
Critical bugs in these components
Other high priority work
High priority bugs in these components
Feature bugs
Feature bugs in these components

Definitions needed

• Define "critical" bug queries, with weighting based upon query, priority and criticality

tracking for release or blocking-fennec, combined with other queries

• Define "other high priority" bug queries, with weighting based upon query, priority and criticality
  • topcrash (startupcrash before reproducible before others sorted by first report)
  • sg: (crit before moderate, sorted by first report)
  • performance (?)
• Define "feature" bug queries
  • basecamp
  • k9o
• Has '[feature]' in the whiteboard