Bug Triage: Difference between revisions
(→Firefox 57 Queries: remove enhancements and [meta] bugs from the affecting or fix-optional query) |
(→Firefox 58 Queries: fix p1 query) |
||
| Line 37: | Line 37: | ||
= Firefox 58 Queries = | = Firefox 58 Queries = | ||
[https://mzl.la/ | [https://mzl.la/2h7U9vi P1 bugs which are affecting or fix-optional for Firefox 58]; these bugs should be reviewed to see if they are ''still'' P1s and if they should ''not'' be <tt>wontfix</tt>ed. | ||
[https://mzl.la/2ze7SY1 Bugs for which we don't know if they affect Firefox 58 by triage status]; un-triaged bugs should be reviewed as early in the cycle as possible. | [https://mzl.la/2ze7SY1 Bugs for which we don't know if they affect Firefox 58 by triage status]; un-triaged bugs should be reviewed as early in the cycle as possible. | ||
Revision as of 20:58, 2 November 2017
What we do
Mozilla's bugmaster develops policies and processes for managing bugs, their goal is to "leave no bug behind," and help Mozillians make crisp and actionable decisions on bugs, and enable them to follow-through on their decisions.
Triage Process
If you're triaging bugs in a component, Triage for Component Leads is the process we follow.
Initiative Process
There are a number of workflows in Bugzilla that are in addition to and often across our Component system. These initiative will modify our Initiative Template and the modified document will be linked below. Any special tagging required by these initiates will be registered as Metadata and also described in the Initiative document.
- Performance Initiative - Triage and tracking of bugs we believe are essential to Firefox's responsiveness and throughput. NOTE: Update of the Quantum Flow initiative.
Triage Scorecard
History is viewable as a Re:dash dashboard
Bug Farming
Automated cleanup of bugs is handled by the bug-husbandry-bot, under which regular and ad-hoc queries run.
Current Regular Queries
Intermittent Test Failure Cleanup
Resolves bugs filed from Orange Factor for intermittent test failures. Intermittent test failure bugs which have had no new failures in 21 days (as measured by comment count) and have not been reopened in the past week are resolved as INCOMPLETE.
Inactive Bugs
Resolves bugs in Firefox-related components which have no activity in at least one year. These bugs are resolved as INACTIVE.
Other Requests
File a bug in the Bulk Bug Edit Requests component.
Release Cycle Queries and Activities
1 week to branch
Move fix-optionals
Mark all unfixed, fix-optionals for upcoming release (beta) as wontfix and mark as ? for next release unless that status is set (nightly) (Query)
Update affecteds
Mark all unfixed, affected bugs for upcoming release (beta) as ? for next release unless that status is set (nightly) (Query)
Leave them marked as affected for upcoming release.
Branch day
- Update versions, milestones, tracking, and status
- Add status and tracking for nightly+1 but restrict to release drivers
Stale Bug Reports
- All open bugs without pending needinfos which have had no activity in a year
- All open bugs without pending needinfos with no activity in 2 years
- All open bugs without pending needinfos with no activity in 5 years
See also, the Chromium Project's automatic triage 'sheriffbot'.
Firefox 57 Queries
First Nightly: 2017-06-12
P1 bugs which are affecting or fix-optional for Firefox 57; these bugs should be reviewed to see if they are still P1s and if they should not be wontfixed.
Bugs for which we don't know if they affect Firefox 57 by triage status; un-triaged bugs should be reviewed as early in the cycle as possible.
Bugs filed later in the cycle should only be considered for fixes if they will result in a dot release if they are not addressed.
Firefox 58 Queries
P1 bugs which are affecting or fix-optional for Firefox 58; these bugs should be reviewed to see if they are still P1s and if they should not be wontfixed.
Bugs for which we don't know if they affect Firefox 58 by triage status; un-triaged bugs should be reviewed as early in the cycle as possible.
Bugs filed later in the cycle should only be considered if they will result in a dot release if they are not addressed.
Who we are
- Emma Humphries (:emceeaich), Bugmaster ehumphries@mozilla.com
- The individual triage leads in each bugzilla component
Projects
- Bug Handling: Making sure no bug is left behind
- Bugzilla Clean Up: End-of-life for Bugzilla components
- Bugzilla Folk Knowledge: Documenting how each team uses bugzilla metadata
- Bugzilla Training: Equip Mozillans with best practices on bugs
- Repeat Filers: Track contributions from new Mozillans, so we can get more people filing bugs earlier in the release cycle
Code
- Bugzilla Readable Statuses - enhancement to bugzilla.mozilla.com to help make the status of a bug more understandable
- Triage Center - tool for finding untriaged bugs, and other bugs that need attention
- Triage Report - scoreboard for components with most un-triaged bugs
Meetings
The bugmaster office has no scheduled meetings at this time.
Communication
Get in touch with us. Don't hesitate to communicate using:
- The IRC channel: irc.mozilla.org#bugmasters. Join us on IRC to say hello, introduce yourself, and talk about bugs, bugs, bugs. Questions are welcome!
- Joining the bugmaster mailing list to be informed of all the news and the discussions.
Useful Links
- Triage Leads - who is responsible for triaging new bugs in each Firefox component
- Bugmastering Guide - A guide helping on how to contribute to bug management and triage
- Whiteboard tags - A list of common whiteboard field values and flags used in Bugzilla