The short version: we believe that the number of outstanding bugs in a component is the best metric we have of the overall health and quality of that component. We will test this belief by dramatically improving the efficiency of ingest and processing of new bugs, and would like two to four component managers and their teams to participate in this experiment.
The longer verison: The Firefox team has committed to improving how we manage the bugs reported in each bugzilla.mozilla.org component of Firefox, Core, and Toolkit. As of late 2015, we're already burning down our backlog of bugs. Now we're starting the next stage of the work: identifying the people who can make a decision on the status and future of a triaged bug, and automatically bringing that bug to their attention. I've linked a google spreadsheet, similar to :overholt's wiki page (but easier to edit) with a tab for each product: FF, Core, Toolkit, and each platform for Fennec,. I ask all of your to identify a developer, or manager who will take responsibility for deciding the status and next action required of newly-triaged bugs in each Bugzilla component. That responsibility could be a rotation (as is done in Graphics and Networking) or shared between a couple of people. Component owners can also expect support from the community and Participation teams: Mike Hoye is working on getting community members to volunteer their time helping component owners determine if a bug is a duplicate, not a bug, severe or blocking. In order for this process to be succesful, the responsible person will need to make a judgement call about the bug that makes the next steps clear: assigining it to a developer and a release, acknowledging it's a valid bug but it will not be worked on, that it's in a backlog of bugs to be worked, pushing it back for more information or closing it as invalid/duplicate/incomplete. These states are not set in stone, and so we're asking for three or four components to step up and try this so we can quickly work up a proposal for standard decision-tree process. If successful, this will become the standard process across all components. Once the pilot's done, we'll bring a proposed set of dispositions and rules to this group for comment before implementation. But before we start on that, we need you to identify responsible parties for components; this shouldn't take long, so after next Wednesday, January 27th, I will start pestering you all to get the remaining gaps filled. Thank you for your help with this first step. -- Emma https://docs.google.com/spreadsheets/d/10i30CFUPJM7snz0xX3czFJeBh2tNwjwjtI409DQw3x0 Note: when filling out the sheet, please use the person's name, bugmail, or irc handle (whichever is the most approriate identifier.) There are preliminary entries which I've copied from :overholt's wiki page. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform