Re: Bug Program Next Steps

2016-02-02 Thread Gijs Kruitbosch
On 02/02/2016 18:04, Anne van Kesteren wrote: On Tue, Feb 2, 2016 at 6:50 PM, Boris Zbarsky wrote: But it gets worse. The typical lifetime of a bug goes like this. It gets reported to somewhere like Firefox:Untriaged (I think we have a guided form that automatically dumps things there or somet

Re: Bug Program Next Steps

2016-02-02 Thread Anne van Kesteren
On Tue, Feb 2, 2016 at 6:50 PM, Boris Zbarsky wrote: > But it gets worse. The typical lifetime of a bug goes like this. It gets > reported to somewhere like Firefox:Untriaged (I think we have a guided form > that automatically dumps things there or something?). Someone goes through > and triages

Re: Bug Program Next Steps

2016-02-02 Thread Justin Dolske
On Tue, Feb 2, 2016 at 7:44 AM, Benjamin Smedberg wrote: > To keep focus and avoid creeping scope, an explicit non-goal of this > program is to deal with the prioritization of non-critical bugs within a > team or component. The primary goal here is to solve the flow for incoming > bugs to a clea

Re: Bug Program Next Steps

2016-02-02 Thread Boris Zbarsky
On 2/2/16 12:04 PM, Richard Newman wrote: Once or twice a week Once a week is not nearly often enough. As far as I can tell, we have effectively 4.5 weeks or so of beta before things are locked down for ship. Lopping a week off that (or more precisely off whatever time is left after the bug

Re: Bug Program Next Steps

2016-02-02 Thread Emma Humphries
On Tue, Feb 2, 2016 at 9:04 AM, Richard Newman wrote: > Here's my very lightweight counter-proposal: > > Once or twice a week, automatically mail out two lists (in one email) to > the set of people Emma collected. The first are is UNCONFIRMED bugs. The > second is NEW bugs, not filed by one of th

Re: Bug Program Next Steps

2016-02-02 Thread Richard Newman
Here's my very lightweight counter-proposal: Once or twice a week, automatically mail out two lists (in one email) to the set of people Emma collected. The first are is UNCONFIRMED bugs. The second is NEW bugs, not filed by one of the reviewers or bug admins of that component, that haven't been to

Re: Bug Program Next Steps

2016-02-02 Thread Benjamin Smedberg
On 1/29/2016 6:45 PM, Emma Humphries wrote: 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 indicat

Re: Bug Program Next Steps

2016-02-01 Thread smaug
On 01/31/2016 08:35 PM, Axel Hecht wrote: I'm also generally concerned how UX bugs or crashes would fit into these buckets. UX bugs, and possibly any other flavor of ideation, have the majority of work associated with "should we do this or not". And crashes as a single crash stack are hardly ev

Re: Bug Program Next Steps

2016-02-01 Thread Dave Townsend
On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries 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

Re: Bug Program Next Steps

2016-01-31 Thread Axel Hecht
nefit from context. This one might just be a dependency of the ideas on how to get to more heavy stuff. And now to remember all that when I write my own heavy-weight stuff soon. More details inline. On 30/01/16 00:45, Emma Humphries wrote: Bug Program Next Steps Over the last week, I’ve aske

Re: Bug Program Next Steps

2016-01-30 Thread Marco Bonardo
On Sat, Jan 30, 2016 at 12:45 AM, Emma Humphries wrote: > 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

Re: Bug Program Next Steps

2016-01-29 Thread Gervase Markham
On 30/01/16 00:45, Emma Humphries wrote: > 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. Without wanting to pil

Re: Bug Program Next Steps

2016-01-29 Thread Emma Humphries
Richard, Many components have watchers, I am grateful for that. Some components don't. We need reviews in all components so we don't lose track of bugs we must fix to avoid a point release. We're applying consistent process across all components, because we must reduce the amount of noise in bugz

Re: Bug Program Next Steps

2016-01-29 Thread Richard Newman
> > 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. > In my experience, component watching adequately serves this purpose, and component

Re: Bug Program Next Steps

2016-01-29 Thread Eric Rescorla
On Fri, Jan 29, 2016 at 3:53 PM, Kyle Huey wrote: > On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries wrote: > >> 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

Re: Bug Program Next Steps

2016-01-29 Thread Kyle Huey
On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries wrote: > 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. > Why do we believe that

Bug Program Next Steps

2016-01-29 Thread Emma Humphries
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