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 <[email protected]> > 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 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
