On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries <e...@mozilla.com> wrote: > Bug Program Next Steps > > Over the last week, I’ve asked you to step up and identify developers who > will be responsible for bugs triaged into their component (in Firefox, Core, > Toolkit, Fennec iOS, and Fennec Android.) > > Why This Matters > > Bugs are a unit of quality we can use to see how we’re doing. > > > We believe that the number of outstanding, actionable bugs is the best > metric of code quality available, and that how this number changes over time > will be a strong indicator of the evolving quality of Firefox. Actionable > bugs are those with the status NEW for which the next action required - if > any - is unambiguous: does the bug need immediate attention, will it be > worked on for a future release, will it be worked on at all? > > > There are two parts to maintaining the value of that metric. First, we want > to make better assertions about the quality of our releases by making clear > decisions about which bugs must be fixed for each release (urgent) and > actively tracking those bugs. The other is the number of good bugs filed by > our community. Filing a bug report is a gateway to greater participation in > the Mozilla project, and we owe it to our community to make quick and clear > decisions about each bug. > > > Making decisions on new bugs quickly helps us avoid point releases, and > gives positive feedback to people filing bugs so that they will file more > good bugs. > > What’s Your Role > > Starting in the second quarter of this year, if you’ve taken on a component, > I’m expecting you or your team to look at the bugs which landed in the > component on a more frequent basis than a weekly triage.
I'm concerned about making this sort of demand when the component owner is not an employee, or is the expectation that only employees would be in these roles? > In February, we’re starting a pilot with four groups of components where > we’ll get the process changes and field tested, so that we can we can take > the changes to all the affected bugzilla components for review and comment > before we implement them across all of the work on Firefox. > > Hold on, we already have a weekly triage! > > That’s fantastic, but a weekly pace means we miss bugs that affect upcoming > releases. So I’m expecting you to scan that list of inbound bugs daily for > the urgent ones (I’ll define urgent below) and put them into one of the > states described in the next section, the others can go into your regular > triage. > > At Your Regular Triage > > You’ll look at the bugs which landed in your component and decide on how to > act on them using the states described in the next section. > > We don’t have a regular triage > > This is a process which you’ll need to start, and the bug program team will > help with this. > > This is potentially a lot of work for one person > > Looking at the urgent bugs does not have to be one person’s task. You can > have a rotation of people doing this. Look at the Core::Graphics triage wiki > for an example of what you could be doing. > > Bug States > > Initially, these states will be marked in bugzilla.mozilla.org using > whiteboard tags during the pilot. The bugzilla team will be making further > changes once we’ve settled on a process. > > > You’ll be looking at bugs in your component as they land, in your component. > We expect most of these will be NEW bugs, but some will be in UNCONFIRMED. > > > There are four states you’ll need to decide to put each bug, and in your > reviews between your team’s weekly triages, we want you to be on the watch > for bugs with characteristics which make getting it in front of someone > urgent: these are bugs with crash, topcrash, regression, or dataloss > keywords; crash logs linked in comments; references to mozregression > results; and others. > > > The bug should not remain in this state after your review of it. > > > You’ll need to decide which of the following states you’ll move this bug > into, if you can’t you’ll need to be taking action: such as getting someone > to run mozregression, need info’ing a domain expert, looking at checkins, > and whatever else techniques you have to get a bug reduced. > > > Once you have an understanding of the bug, you should assign it to one of > these states. > > Urgent > > Assigned to a developer, release tracking flags nominated, and set at > priority `P1`. If the bug is being worked on by somebody from outside your > core team, a team mentor should be assigned. > > > All these need to be set for the bug when you assign it to this state. This > state is for bugs you find in your daily review which need a developer > immediately. > > > If the bug is not in need of immediate attention, then your team’s process > should land the bug in one of the following states. > > Backlog > > This is a NEW bug that the team acknowledges is a bug, but is not a current > priority, but will consider taking on. If the bug contains regression, > crash, topcrash, or similar keywords and metadata, then the team can explain > why it’s not a high priority. > > Is a Bug, Not Prioritized > > This is a terminal state for a NEW bug. We acknowledge the bug exists, it > affects people, but it is not important enough to warrant working on it. The > team will review and accept patches from the community for this bug report. > > Closed > > This is a terminal state for a NEW bug. After review, the bug is not > something that can be worked on, or describes existing and expected > behavior. > > Other States > > There are other states we’re looking at for bugs. These will cover a bug as > it’s worked on, as ASSIGNED as is doesn’t provide useful information as to > progress; flag bugs that have stalled, or needing code reviews, or sheriff > attention; bugs that are on a release train; and bugs with fixes in general > or ESR version. I think there is a missing state here. One where it isn't worth our time to attempt to reproduce but would accept a patch for if one was forthcoming. I see this a lot where edge-case reporters file something that affects them but very few other people. Sometimes it can take time to verify that the bug report is accurate but realistically I already know that even if it is it would fall into the not prioritized state. Maybe these bugs should just go straight there, or maybe we should just close them, but we should be clear on that. > Timeline > > Now: finish finding component responsible parties > > February: pilot review of NEW bugs with four groups of components, draft new > process > > March: comment period for new process, finalize process > > Q2: implement new process across all components > > Q3: all newly triaged bugs following the new process > > > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
