On Fri, Oct 26, 2012 at 10:03 PM, David Scravaglieri <[email protected]> wrote: > Hi, > > Doing a first session for reviewing basecamp+ priorities, we decided to > apply the following criterias: > > ************ > *P1*(assigned)- dogfood/smoketest blockers, required feature work for v1 > ship, demo blockers, certification requirements, l10n impact > > *P2*- Regressions, security bugs, severe crash/hang bugs, > > *P3*- Major usability bugs (completely broken UI, dataloss, crashers, > severe performance/memory issues)
I'm not sure that understand the reasoning behind this P2 vs. P3 split. In general we should front-load work that prevents further development and testing, as well as work that has high risk. The "major usability bugs" seems like something that can easily prevent further development and testing. So by that nature I think it's something that we'll often want to front-load. On the flip side, a regression could easily be something that isn't affecting a lot of users and that is expected to have an easy/simple fix. So could easily be work that doesn't need to be front-loaded. What we've been using in gecko triage is something like: *P1*(assigned)- dogfood/smoketest blockers, required feature work for v1 ship, demo blockers, certification requirements, l10n impact *P2*- Regressions, security bugs, severe crash/hang bugs, Major usability bugs (completely broken UI, dataloss, crashers, severe performance/memory issues). I.e. "everything not P1 or P3". *P3*- Things that we really want to fix, and that we want people to be working on, but that we might be able to live without come shipping day. For example things that improve APIs that we expose to web developers, small memory/performance improvements, web-compatibility breakage that only affects a small number of websites. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
