Launchpad bug workflow change

[Scott Kitterman]

On Wed, 20 Jun 2007 12:13:57 +0200 Henrik Nilsen Omma <henrik at ubuntu.com> 
wrote:
>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.

Thank you for trying again.  I don't think lack of understanding on this 
end is the problem.

>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.

Agreed, but making life harder for people who have not yet qualified to 
upload directly does not advance this goal.

snip.

> * 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.

Once again I agree on the goal, but not that your change (the additional restrctions) further 
that goal.

>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 can see the point in the new states.  At worst they just won't get used 
much.  The potential for harm comes with the additional restrctions.

As an aside, why was the most controversial aspect of these changes not 
mentioned in your message to devel-announce?

>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.

snip
> * 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.

This rationale continues to avoid the very important use case of people 
working on bug fixes that are not yet official developers.

> * 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.

Makes sense (and qa is easy enough to get into).

> * 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.

This is the real problem in my view and runs counter to what will be helpful in getting new 
volunteer developers.  Most new developer volunteers do not start with triaging.  They start 
with a particular bug they want to fix.  Even your revised proposal raises new barriers to 
entry.  I expect you'll argue the barrier is small, but why raise even 
small barriers?

>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.

All of which is about triaging, not fixing.

>In the development teams we have formal processes of review and 
>sponsorship. Submitted work is looked at by more experienced people. 

Yes and this change does not suite that process well.

>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.
>
Asking the community for input BEFORE making the change might have been 
another approach.  Having read your message over several times, I don't 
think lack of understanding has anything to do with my objections.

Scott K