550
edits
Changes
First version
Bug Reports are a rough unit of quality, represent risk, and a unit of community interaction.
Responding to new bugs in a timely fashion, and coming to an actionable decision on the future of each bug means that: we can catch more regressions and other bugs that cause us to have to ship point releases, encourage contributors to file more good bugs, and reduce the psychic weight of bugs left in limbo on Mozillans.
==Scope==
This project covers bugs in Core, Toolkit, Firefox, and Fennec components in [https://bugzilla.mozilla.com/ Bugzilla].
==Triage Leads==
We've [https://docs.google.com/spreadsheets/d/10i30CFUPJM7snz0xX3czFJeBh2tNwjwjtI409DQw3x0/edit#gid=743363211 identified leads for 80% of these components]. These people will be responsible for making sure new bugs landing in components, are acted on in a timely fashion, new bugs are now being moved into components by volunteers and Mozilla's contractors. Triage leads are encouraged to delegate the work to other members of their team, and set up rotations for reviewing bugs [see Networking].
In a separate project, another team is building groups of volunteers to help with classification of new bugs in a component.
==Pilot Project==
During February 2016, we are running a pilot bug classification project with the Hello, DOM, and Developer Tools teams.
In daily triages, bugs are marked with one of the following whiteboard tags:
;btpp-fix-now: bug is a critical crash, regression, or security bug which should be worked on immediately. Bugs classified as such should have a developer assigned, a priority of `P1`, and flags set for the affected releases
;btpp-active: bug is being worked on, but is not critical. The bug should have a developer assigned
;btpp-triage-followup-YYYY-MM-DD: bug needs more information by YYYY-MM-DD, which is a week from the day this tag is assigned. Bug should have needinfo set, and the whiteboard tag removed when the needinfo flag is resolved. Once this is resolved, the triager must move it to one of the -fix-now, -active, -fix-later, -backlog, or -close states.
;btpp-fix-later: bug is not critical, not being worked on, but teams commits to scheduling within the next quarter
;btpp-backlog: bug is not critical, and the team has no plans to work on it, but will accept a patch
;btpp-close: bug has been closed. Teams are encouraged to close bugs if they do not plan to undertake the work.
Responding to new bugs in a timely fashion, and coming to an actionable decision on the future of each bug means that: we can catch more regressions and other bugs that cause us to have to ship point releases, encourage contributors to file more good bugs, and reduce the psychic weight of bugs left in limbo on Mozillans.
==Scope==
This project covers bugs in Core, Toolkit, Firefox, and Fennec components in [https://bugzilla.mozilla.com/ Bugzilla].
==Triage Leads==
We've [https://docs.google.com/spreadsheets/d/10i30CFUPJM7snz0xX3czFJeBh2tNwjwjtI409DQw3x0/edit#gid=743363211 identified leads for 80% of these components]. These people will be responsible for making sure new bugs landing in components, are acted on in a timely fashion, new bugs are now being moved into components by volunteers and Mozilla's contractors. Triage leads are encouraged to delegate the work to other members of their team, and set up rotations for reviewing bugs [see Networking].
In a separate project, another team is building groups of volunteers to help with classification of new bugs in a component.
==Pilot Project==
During February 2016, we are running a pilot bug classification project with the Hello, DOM, and Developer Tools teams.
In daily triages, bugs are marked with one of the following whiteboard tags:
;btpp-fix-now: bug is a critical crash, regression, or security bug which should be worked on immediately. Bugs classified as such should have a developer assigned, a priority of `P1`, and flags set for the affected releases
;btpp-active: bug is being worked on, but is not critical. The bug should have a developer assigned
;btpp-triage-followup-YYYY-MM-DD: bug needs more information by YYYY-MM-DD, which is a week from the day this tag is assigned. Bug should have needinfo set, and the whiteboard tag removed when the needinfo flag is resolved. Once this is resolved, the triager must move it to one of the -fix-now, -active, -fix-later, -backlog, or -close states.
;btpp-fix-later: bug is not critical, not being worked on, but teams commits to scheduling within the next quarter
;btpp-backlog: bug is not critical, and the team has no plans to work on it, but will accept a patch
;btpp-close: bug has been closed. Teams are encouraged to close bugs if they do not plan to undertake the work.
