Release Management/Engineering Dashboard

From MozillaWiki
Jump to: navigation, search

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).


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.

Existing Dashboards

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 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
  • Ability to add an additional custom flag & priority level to include in the view (eg: blocking-basecamp+)

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


  • "critical" bug queries, with weighting based upon query, priority and criticality
    • tracking for release or blocking-fennec, combined with other queries
  • "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 (?)
  • "feature" bug queries
    • basecamp
    • k9o
    • has '[feature]' in the whiteboard


See etherpad for up-to-the-minute schedule.





Communicating to Company

Feature Requests