Why not triaging confirmed bugs instead of new ones?

Alberto Salvia Novella es20490446e at gmail.com
Wed Jul 23 17:00:51 UTC 2014


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.

Alberto Salvia Novella:
> 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.

What comes out from these conversations is that it will be better to 
prototype and measure step by step rather than having a conversation 
about it without something palpable, specially being this process so 
interlaced that everyone will have a very different opinion about it.


Alberto Salvia Novella:
 > If Launchpad could treat End Of Life bugs automatically I think it
 > will be a great success.

I think this the exception from the above. It is just pretty clear, just 
by looking at:

  - The quantity of open bugs (http://tinyurl.com/25t3v6): 129308
  - The known quantity of bugs for the supported releases 
(http://tinyurl.com/l5dhlhc): 35333

The second is only the 27% of the first.

These numbers make evident that:

  - The quantity of open bugs (129308) is unmanageable for any team 
right now, even for discovering critical bugs.

  - The 73% of bugs have the potential of being End Of Life.

  - Automatizing the management of End Of Life bugs will make a huge 
difference in quality, even if the automation algorithm expires a few of 
them wrongly in the beginning.


Regards.




More information about the Ubuntu-quality mailing list