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