Firefox/4/Triage
Contents
Queries for Daily Triage
- Firefox 4 Blocker Nominations
- see nominations that were marked not blocking in the past 12 hours
- see the issues identified by QA
- Existing Firefox 4 Blockers
- Patch approval requests
Firefox 4 Blockers
A blocker is an issue which must be resolved before the indicated milestone is considered completed. Potential resolutions include:
- fixing the issue (RESOLVED FIXED),
- identifying the issue as invalid (RESOLVED INVALID/WORKSFORME),
- deciding that the issue will not be fixed (RESOLVED WONTFIX),
- identifying a duplicate issue that has already been decided to be a blocker or non-blocker (RESOLVED DUPLICATE),
- moving the requirement for resolution to a future milestone.
Whether or not a specific issue will block a release is a judgement call made by component leads and product drivers. Appeals can be made to module peers and owners, whose decision must be respected as final. Appeals can also be made if the context around a blocker has changed since the decision.
An issue may be considered to be a blocker if it is:
- a regression of key product functionality from a previous release,
- a significant regression of performance as indicated by our tests,
- a new source of product instability,
- it is a reproducible sg:crit,
- a significant implementation error of a supported web standard,
- it is a requirement for a feature or technology planned for the milestone,
- a user experience problem deemed significant by the user experience team,
- a very noticeable user interface polish issue in the primary browser UI,
- judged to be so by a component lead or product driver.
Nominating an issue as a blocker
To nominate an issue as a blocker, change the blocking2.0 flag to ? and be sure to include the following information:
- why you think the issue should block,
- what the risk is of not addressing the issue,
- what the risk is of the potential fix (if known),
- what caused the issue.
Triage
Blocker nominations represent potential risk to the product schedule. To keep an accurate view of the state of the product, component leads and product drivers should answer nomination requests frequently in regular triage sessions.
Renominating an issue as a blocker
Component leads and product drivers will often "triage" as many as 100 blockers at a time, and mistakes can be made. Rationale should be given as to why an issue does or does not block a milestone. If you disagree with that rationale, feel free to renominate with an explanation as to the source of the disagreement.
Note: while contributors are allowed to have differing opinions, please do not renominate a bug unless you believe that the component lead erred in judgement or rationale. "Because I want this feature" is not a valid reason for renominating a bug for blocking.
Triage Queries
The following queries may be useful for people running triage sessions, or trying to get a sense of the status of various releases.
Global
Blocker Noms (ALL blocking2.0:?)
Beta N Blockers (blocking2.0:betaN)
All Beta Blockers (blocking2.0:beta)
All Blockers (blocking2.0:beta,final)
QA during Beta cycles (Whiteboard:[4b])
approvals (flag:approval2.0?)
Front End
Blocker Noms (ALL blocking2.0:? :toolkit,firefox)
Beta 4 Blockers (blocking2.0:beta4 :toolkit,firefox)
Beta 5 Blockers (blocking2.0:beta5 :toolkit,firefox)
Beta 6 Blockers (blocking2.0:beta6 :toolkit,firefox)
Beta 7 Blockers (blocking2.0:beta7 :toolkit,firefox)
Beta 8 Blockers (blocking2.0:beta8 prod:toolkit,firefox)
Beta 9 Blockers (blocking2.0:beta9 prod:toolkit,firefox)
Beta N Blockers (blocking2.0:betaN :toolkit,firefox)
All Beta Blockers (blocking2.0:beta :toolkit,firefox)
All Blockers (blocking2.0:beta,final :toolkit,firefox)
Misc
Bugs waiting to land (blocking:beta,final sw,kw:land,checkin)
