Why not triaging confirmed bugs instead of new ones?

[Alberto Salvia Novella]

Alberto Salvia Novella:
 > I realized that users could not confirm private bugs; so new bugs
 > must be included for sure in any list intended for triaging.

Not exactly true: just new private bugs will be required, which are a 
minority compared to the hole list of new bugs.


Brian Murray:
> 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.

90% of these actions are:

- Invalidating End Of Life bugs.
- Invalidating unconfirmed bugs.

Which doesn't translate into a quality improvement in Ubuntu. Lean calls 
everything under this category a waste.

This means that by pushing out these two actions, we will be able to do 
ten times more work in the same period:

- Invalidating End Of Life bugs can be automatized.
- Invalidating unconfirmed bugs is implicit when a bug doesn't get 
reported by anyone else.


C de-Avillez:
 > Better to err on caution, and make this manual.

As seen in practice, looking through the above errors doesn't make 
Ubuntu to be shipped with better quality; but to keep bug controllers 
busy with old stuff that most probably got rotten, and let pass obvious 
errors you will see day after day in the operating system.

This encourages people to filter these bugs, rather than checking them 
ones one by one. So leaving good old reports abandoned, as it already 
happens.


Brian Murray:
 > 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.

Perhaps a good approach will be to set importances first for every 
confirmed bug, then continue with the triaging; since this will warrant 
to be spending every triaging piece of work in the most important things 
first.

At least this is what Six Sigma suggests: shorting first, then shining.


Regards from a lost place in the mountain.