Bug workflow - a wider view

[Henrik Nilsen Omma]

Hi,

Robert Collins linked to a very interesting video today on his blog. 
It's a Google tech talk by Mary Poppendieck called 'Competing On The 
Basis Of Speed' [1]. Highly recommended.

The main message was about getting the process right, and used both 
manufacturing, design and software engineering as examples. In each case 
QA is and integral part of the process, and must be seen as such.

In Ubuntu we are quite good at following the principles described in 
that talk in many areas. We release code early and often so it gets 
thoroughly tested by a large community; we stress test our CD generating 
machinery regularly with both daily builds and periodic milestones. We 
also refactor and improve our procedures constantly.

I'd like to bring more focus on the overall process into our bug work as 
well and the first step is to get a good overview of what we are doing 
and what we need. I'd like to get feedback from both developers and bug 
triagers on what procedures work for you and where the current 
bottlenecks are. How can we make the process simpler and more uniform so 
that more people will enjoy doing QA?

I'd prefer the discussion to not focus too much on the finer details of 
the tools (ie. feature wishlists of Launchpad or bughelper can be 
discussed separately), but rather the overall flow of feedback from our 
testers and users and how that can be used most efficiently to improve 
Ubuntu.

The current guide to bug triage is: 
https://wiki.ubuntu.com/Bugs/HowToTriage but this needs some updating 
IMO and not just to reflect recent Launchpad changes. I've started 
posting some of my thinking here: https://wiki.ubuntu.com/Bugs/WorkFlow 
Comments or edits are of course welcome!

Henrik

[1] 
http://video.google.com/videoplay?docid=-5105910452864283694&q=google+talks