> > So: with the way we're using Rank right now, it wouldn't make sense ever > to have a tracking+ bug (a bug we care about but not enough to fix in for > the next release), with a rank 1 (release blocker).
Agreed - if it's a blocker, it doesn't make sense to have it tracking+ since its blocking* a release.* * a bug tagged to a release with a rank of 1 and importance `blocker` is a > release blocker. > * a bug tagged to a release with a rank of 1 and importance `normal` means > try and get this fixed as a matter of urgency but it's not a blocker > When it comes to tracking against a release, I find that rank usually becomes irrelevant. Usually things fall into 3 buckets: blocker, feature for release, nice to have. I'd like to see tracking 'normal' bugs against a release be more of a commitment while using [nicetohave] to indicate stretch goals. * a feature bug tagged to + with a rank 1 and importance `normal` means > pick this one first when you run out of release tagged bugs > * an engineering bug tagged to + with a rank 1 and importance `major` > means get this done ASAP, ahead of any other bugs of the same rank. > * an engineering bug tagged to + with a rank 1 and importance `normal` > means this is important but not more important than a feature bug of the > same rank. > I'm not sure if we want to distinguish between engineering bugs vs feature bugs vs regressions. I think the priority of any of those issues should be folded into what we perceive as its rank. I just don't want to end up in the scenario where we are saying that this bug with rank 1 is actually super rank 1 vs normal rank 1 because its regression/feature/eng task. I really like the idea of including severity though. I think just including that instead of differentiating between bug types will add clarity. On Wed, Apr 27, 2016 at 5:06 AM, Emily Toop <et...@mozilla.com> wrote: > I think our bug ranking would need to differ based on whether a bug is > tagged to tracking+ or tracking version. A meaning of rank 1 being a > release blocker when a bug is tracking a version makes total sense, but as > James pointed out, makes little sense when the bug is tracking +, where the > meaning is far more "pick this one next as soon as you run out of version > tracking bugs". > > We also have the problem that engineering focused tasks are normally > tracked as + alongside feature focused ones. In this case, again, the ranks > mean slightly different things. For feature focused bugs, the top ones are, > as mentioned above, an order of priority - pick this one next - whereas for > engineering tasks it is an indication of need. Something with a rank 1 is > an engineering task that is desperately needed, but not tagged to a version > as it's not a release blocker, however someone needs to get this done ASAP. > > With this in mind, James's link explaining how priority and severity can > be combined might solve this problem. Rank can be used to determine > priority, and Bugzilla has the importance fields that we can use to > determine the severity of things. > > Therefore, how about this (or some combination of it)? > * a bug tagged to a release with a rank of 1 and importance `blocker` is a > release blocker. > * a bug tagged to a release with a rank of 1 and importance `normal` means > try and get this fixed as a matter of urgency but it's not a blocker > * a feature bug tagged to + with a rank 1 and importance `normal` means > pick this one first when you run out of release tagged bugs > * an engineering bug tagged to + with a rank 1 and importance `major` > means get this done ASAP, ahead of any other bugs of the same rank. > * an engineering bug tagged to + with a rank 1 and importance `normal` > means this is important but not more important than a feature bug of the > same rank. > > On 26 April 2016 at 23:59, James Hugman <jhug...@mozilla.com> wrote: > >> I was trying to work out scope of what we're doing here since the last >> time we talked about this. >> >> We're currently using the tracking flags to indicate if we care about it, >> but using a rank (essentially because bugzilla already had a flag) to >> indicate how much we care about it if we don't care enough to put it in a >> tacking-x.x+ list. >> >> We were also using it as a way of ordering that list of bugs, relative to >> each other – on the assumption that these would be periodically re-ordered >> depending on our changing priorities. >> >> So: with the way we're using Rank right now, it wouldn't make sense ever >> to have a tracking+ bug (a bug we care about but not enough to fix in for >> the next release), with a rank 1 (release blocker). >> >> See also: >> http://bugfinding.blogspot.co.uk/2013/09/defect-severity-and-defect-priority.html >> which is quite helpful. >> >> – James >> >> On Tue, Apr 26, 2016 at 9:39 PM, Stefan Arentz <sare...@mozilla.com> >> wrote: >> >>> I’ve made a small start with a bug ranking scheme: >>> https://github.com/mozilla/firefox-ios/wiki/Bug-Rank >>> >>> Add some more descriptions please. >>> >>> S. >>> >>> >>> _______________________________________________ >>> mobile-firefox-dev mailing list >>> mobile-firefox-dev@mozilla.org >>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>> >>> >> >> _______________________________________________ >> mobile-firefox-dev mailing list >> mobile-firefox-dev@mozilla.org >> https://mail.mozilla.org/listinfo/mobile-firefox-dev >> >> > > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
