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
