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

Schedule
Milestones
Deployment
Documentation
Testing
Communicating to Company
Feature Requests
Bugs