On Wednesday, February 18, 2015 at 5:55:32 PM UTC+2, fra...@mozilla.com wrote: > On Wednesday, February 18, 2015 at 12:06:44 PM UTC+1, Julien Wajsberg wrote: > > Le 18/02/2015 11:46, Michael Henretty a > > écrit : > > > > > > > > > > > > > > On Wed, Feb 18, 2015 at 12:37 AM, > > Frederik Braun <fbr...@mozilla.com> > > wrote: > > > > > > > > > > > > I had the impression a lot of > > components just don't have any people > > > > watching them. :/ Is triage a program manager job? I > > honestly wouldn't > > > > even know whom to poke.. > > > > > > > > > > > > > > > > > > The unfortunate truth here is that > > unless a bug get's nominated to block a release, it might > > never get looked out. There are some nice module owners that > > follow their component and triage the new bugs that come in > > (see Julien's email above), but this level of attention is not > > uniform across the FxOS components. I agree this is a huge > > problem and we need to fix it if dogfooding is to be > > effective. > > > > > > > > > > > > > > I'd argue that it's also important for our other users. Not only for > > dogfooding. > > > > > > > > > > > > > > > > > > > > As a corollary, if a bug does not get marked to block a > > release, the chances of it getting worked on/fixed are > > relatively small since resources are already constrained for > > blockers. The end result is we get a lot of "papercut" bugs > > [1] that everyone is aware of but nobody has the time to fix. > > > > > > > > > > Nobody has any time for anything. > > > > But the good thing is that time can be taken :) > > > > > > > > If you spend 1 week fixing an important performance bug, maybe you > > can take 2 hours in this week to fix this papercut bug. (and it will > > really take ~0.5 days including review and fixing review comments). > > If every member of the team fixes a papercut bug each week... we'll > > be in a good shape :) > > > > > > > > I don't think we need much more process to fix these. We only need > > to acknowledge that some bugs will fill in all the available time > > you have, regardless of how much time you have. So you need to > > reclaim part of this time to work on these bugs that don't work like > > this, and papercut bugs are these bugs. > > > > > > > > > > > > > > > > Leveraging the community with mentored > > bugs only solves part of the problem. The other part would be > > a greater focus on polishing our existing experience vs. > > adding new features. It's tough though, eg. do we take the > > time to add email thread grouping, or should we focus on list > > scrolling performance? We are already playing catch up to > > products that have vastly more resources, so the reality is we > > must both add new features and polishing existing ones > > simultaneously. This is why dogfooding across ALL of Mozilla > > (developers, UX, marketplacers, platformers, EVERYONE) is so > > important. Only with everyone feeling the pain can we make the > > most informed decision about what are the important polish > > bugs and features. Making far reaching decisions about the > > future of our device without intimate knowledge of what it's > > like to use our phone on a daily bases is the opposite of > > helpful. We need everyone dogfooding. > > > > > > > > > > > > > > Yes. > > > > > > > > -- > > > > Julien > > i agree with julien here. the answer is not more process but pride of > ownership. i've worked with people in the past that no matter what made sure > the components they've touched/owned are as free of bugs as possible. it has > its own challenges -- no question there -- but over time, it pays for itself. > > there was a presentation for v3 by clord which touched up on just fixing > papercuts and bugs we've known to exist for some time. i'm a big fan of that. > we're far from perfection -- point of diminishing return is not in sight yet! > > faramarz
"pride of ownership", even in a wider context, this is the key word! _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
