Release Management/Engineering Dashboard
Contents
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.
Existing Dashboards
- Bugs Ahoy! by Josh Matthews - See http://www.joshmatthews.net/bugsahoy/
- bzhome by Heather Arthur - See http://harthur.github.com/bzhome/
- Bugzilla-Dashboard by Atul Varma - See <bugzilla_username> http://hg.toolness.com/bugzilla-dashboard/raw-file/tip/index.html?username=<bugzilla_username>
- FirefoxOS Status by Dietrich, along with Basecamp Blockers
- l10n-triage, beta dash, l10n dash in wiki by Axel (aka Pike in IRC)
- Socorro Releases by Lonnen, talk to him about how he's automating it
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
- 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
Definitions
- "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
Schedule
See etherpad for up-to-the-minute schedule.
