Launchpad bug workflow change

[Henrik Nilsen Omma]

Hi all,

Instead of answering each point made by each person I will try to 
explain the reasoning behind this change in a more structured way.

The reality is that the development team is flooded with open bugs ATM 
and we need to take steps to improve this situation. We have over 30 000 
open bugs presently and only 88 members of ubuntu-dev. Not all these 
bugs will ever be fixed by ubuntu-dev; some will be fixed upstream, by 
other distros, by other volunteer developers; some are duplicates and 
some will be rejected. But the fact is that as it stands today 
ubuntu-dev potentially has to consider all those 30 000 bugs because 
there could be serious problems hiding there.

The current triage process is not solving that problem and does not look 
likely to scale as we get more users and bugs. We must look at ways of 
enhancing the process to:

 * Attract more bug triagers into the bugsquad
 * Provide better training so more people can in turn join ubuntu-qa
 * Structure the division of work better to reduce duplication of effort

The bug triage process must be improved at all levels, not just in the 
bugsquad and ubuntu-qa but also within the development teams. We should 
also encourage more people to join ubuntu-dev as this group performs 
both important development and triage work.

So far I think most will agree. It seems that the controversy centers 
around the restricted use of In Progress, Fix Committed and Fix 
Released. There is also a feeling that Todo and Triaged are superfluous. 
I will try to address these.

The Triaged and Todo states and their new restricted nature is important 
to improving our workflow. Other restrictions are useful for other 
reasons, but also have disadvantages and the answer may be to reduce the 
restrictions on some of those.

 * Triaged -- The bugs in the Triaged state are known to have a certain 
quality and completeness. They will have the right package, have enough 
information, have a reasonably accurate priority, etc. The reason we 
know this is that it has been vetted by someone that we know is an 
experienced bug triager, a member of ubuntu-qa. Any other triager can 
place a bug in Complete, which many have pointed out means nearly the 
same as Triaged. That's correct but the key difference is precisely that 
Triaged has been checked by someone in ubuntu-qa, which is a very 
valuable piece of information about that bug. Someone in the bugsquad 
learning to triage will take bugs from New to Incomplete through to 
Confirmed where a more experienced triager will look at it. If the first 
person has made mistakes in the process then corrections are made and 
lessons are learned. When the bugs triaged by the bugsquad member are 
generally correct then that person should be admitted to ubuntu-qa.

 * Todo -- A developer now mainly has to look at the trusted Triaged 
pile of bugs and will decide to move some onto the active ToDo list. The 
ToDo state seems to be another duplicate of the old 'Confirmed' that 
only developers can set. Again, therein lies its importance. This allows 
developers to control their own todo list, which is something they were 
previously struggling to do. Large packages like ubiquity, openoffice 
and firefox have over 500 open bugs that must be sorted not only 
relative to their intrinsic importance but also when they will be worked 
on. The relation between the Triaged and Todo states also provides a 
mechanism for developers to feed back information to ubuntu-qa about how 
bugs should be handled for that particular package.

 * WontFix -- This new value has been restricted to ubuntu-qa and 
developers. Since only otherwise valid bugs should be marked as WontFix 
it is important that this be done by a person who in some way represents 
the project because it is expression of the features we care about and 
the reasons for rejecting a bug may not be clear to the submitter.

 * In Progress, Fix Committed, Fix Released -- these are states related 
to the development (bug fixing) process. They would normally follow 
after the Todo state but there are clearly exceptions to this, esp. 
relating to upstream bugs. These settings have been restricted to 
developers but I personally have no problem with opening these up to 
ubuntu-qa or/and the bugsquad.

In my view, if a bug triager is cable to determine correctly when a bug 
should be WontFix and can confirm that a bug fix from bupstream has been 
applied in Ubuntu and is now working, etc. they qualify for ubuntu-qa 
and should be admitted there. I believe we should be growing ubuntu-qa 
faster tan we are ATM. As a project we may decide that this in not the 
correct way to handle it and may coose instead to give more powers to 
the bugsquad.

In the development teams we have formal processes of review and 
sponsorship. Submitted work is looked at by more experienced people. 
This ensures the quality of what is committed remains high and helps 
people improve their skills. We currently don't have such a formal 
process on the triage side. There will always be a tendency to think 
that what we are doing currently is about right, but if you don't try to 
make changes you will never test that assumption and will not be able to 
find potential improvements.


Henrik