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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
