Le 18/02/2015 11:46, Michael Henretty a écrit : > On Wed, Feb 18, 2015 at 12:37 AM, Frederik Braun <fbr...@mozilla.com > <mailto: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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
