Defect Analyst Bug Review Dashboard
Defect Analysts have hundreds, if not thousands, of bug reports at which they could be looking. Their dashboard will be a collection of the highest priority bugs to review on a daily basis with links to reports of bugs matching specific criteria.
- Kate Stewart
- Brian Murray
- Brian Murray
- Series goal:
- Accepted for precise
- Milestone target:
- Started by
- Kate Stewart on 2012-01-09
- Completed by
- Ursula Junque on 2012-05-07
This blueprint was superseded by https:/
1) bugs assigned to the team
2) bugs tagged iso-testing (what about recently tagged?)
3) bugs that have transitioned away from Fix Released
4) bugs that have been set to High or Critical
5) bugs that have been set to Triaged
6) bugs that have been tagged regression-
7) bugs that have been Confirmed
8) bugs that are Incomplete w/ response
9) New bugs sorted by heat (assuming heat is useful)
This for a team of people who want to be involved in bug triaging
What kinds of information would be useful?
- Packages "trending": that had reported more bugs
- Packages receiving new bugs including information about the importance
- The 20? hottest bugs across all the packages (bug heat?)
- Finding bug reports that have been reopened (date_left_closed exists on a
- Bugs that are awaiting SRU verification (watch for comments ... people
commenting on them and not adding the verification-done tag)
- Bitesize bugs (as an ubuntu-server team member I want to find things I can work on)
- these appear in harvest (out of scope)
- Old bugs In Progress (both those that are assigned to team members and that
* For which of these priorities can Launchpad reports be used?
1, 9, 8
2 is possible if you just want to see the bugs that are tagged iso-testing
not possible to see ones that were recently tagged iso testing (talk to
isotracker people about this?)
3 to 7 - the field is in the database but it isn't queryable in the web
interface nor API...
* part of the reason for this is that the results of advanced does't confir that what you searched for is what you got (e.g. if you query for bug_reporter=
Data gathering should be separate from report creation.
Dashboard should show link to report and quantity in that report?
Look at http://
Collecting information across multiple packages
Report creation tools should be easy to access
- Currently http://
Aggregation of team stats into a overview for the release manager ... a summary at the top level
Search will start from packages / projects to which a team is subscribed
Our reports today (most of them):
- not possible to distinguish between a bug confirmed by the janitor and a
bug not confirmed by the janitor (http://
- date_last_updated changes when someone subscribes to a bug (http://
[brian-murray] Talk to stgraber regarding data dump from iso tracker bugs tagged iso-testing with date information (easier than using launchpad): DONE
[brian-murray] File bugs (a separate bug for each) on LP to be able to search given dates when statuses changed (3, 4, 5, 7) - (add that as a search parameter, date_since_
[brian-murray] Escalate https:/
[kate.stewart] review the definition of bug heat and determine if it is useful or not and what would be more useful if it isn't: interested people (mtaylor, ttx, kate.stewart, bdmurray, pedro, cgregan, Ursinha, mrevell, sinzui, victorzhou) Existing LP definition is https:/
File a bug against LP to be able to easily get the activity information of a bug through the api (LP: #929928): DONE
[ursinha] sketch proposals of what the dashboard should look like with some design input - work in progress putting information together, haven't looked for design input yet, though: POSTPONED
[brian-murray] File bugs about the bug_subscriber timeout (LP: #904339): DONE
2012/02 - Bug Heat definition felt to need some adjustment, but is generally useful. Current experiments with Bug Gravity - which is based on elements of the heat.
* Blueprints in grey have been implemented.