On Mon, Apr 18, 2016 at 10:34 AM, Kartikaya Gupta <[email protected]> wrote: > > My view is that if we have a lot of bugs and regressions, time spent > investigating and fixing those naturally acts as a backflow to new feature > work, which prevents the introduction of even more bugs and regressions. So > really time spent investigating these issues is good in that it encourages > a self-correcting cycle, rather than just adding more regressions and work > for everybody that will never get done. > > Of course, the tradeoff is that we have this goals system where you have to > state up front what you are going to do in a quarter and that makes it > harder to justify spending time on these other issues that often take a lot > of time as you poke around in unfamiliar code. Also falling behind on > features means we fall behind other browsers from a user perspective. My > interpretation of the push on quality, though, is that this is correct > tradeoff to make for us at this time, because great bug-free experiences > are more useful to us right now than a pile of half-baked features.
This is a good opportunity to spruik the nascent Project Uptime (https://wiki.mozilla.org/Platform/Uptime) which aims to improve stability. I'd like to highlight one sentence in David Bryant's announcement: "The overall responsibility to hit our stability target is something that falls on the entire platform organization, and in terms of priority, stability is second only to shipping e10s." In this context "stability" refers to crash rate, but with a little bit of flexibility and imagination we can extend it to things that adversely affect the user experience in similar ways, such as bad GC pauses. I understand that the quarterly deliverables system can distract from this kind of work. I would hope that all Platform managers would be flexible enough that if one of their employees said "I'm thinking about chasing this cluster of crashes for the next week or two, which may cause me to slip on a deliverable" they would be open to that suggestion. Nick _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
