← Back to team overview

ubuntu-bugcontrol team mailing list archive

Re: Why not triaging confirmed bugs instead of new ones?

 

On Sat, Jul 19, 2014 at 12:53:43AM +0200, Alberto Salvia Novella wrote:
> In the triage guide (http://tinyurl.com/kz4netu) there's a list for
> suggested bugs for being triaged, which basically is one of reports
> being untouched and not confirmed.

Its rather confusing but "triaging" is a process and "Triaged" is a bug
task state in Launchpad. For people new to the triaging process looking
at "untouched bugs", those that are New, does make sense as they likely
contain the greatest number of actions to perform. Subsequently, there
are lots of things for people to do to those bug reports, with Confirmed
bugs there is probably less work to do.

> Although confirming bugs could be taken into consideration, for
> triaging wouldn't it be better to suggest confirmed bugs instead?

For setting bug tasks to a Triaged state, yes looking at Confirmed bugs
first makes sense.

> Also it seems to me that shorting bugs with higher heat rather than
> with higher importance could be a good idea for triaging, since you
> will be looking at bugs with higher appearance first in a phase
> where most bugs haven't got any importance set yet.
> 
> So the list will be:
> <https://launchpad.net/ubuntu/+bugs?field.searchtext=&field.status%3Alist=CONFIRMED&orderby=-heat>

Given that the ability to set the importance of bug tasks is restricted
to a specific group of people I would first look at importance and then
at bug heat. So something like this:

Confirmed and Critical ordered by heat in descending order
Confirmed and High ordered by heat in descending order
...

If you were to just order the bug task list by heat you'd miss the value of
the importance, since it is not included in the heat calculation[1].

[1] https://dev.launchpad.net/Bugs/BugHeat#Algorithm

--
Brian Murray
Ubuntu Bug Master

Attachment: signature.asc
Description: Digital signature


Follow ups

References