LucidBugTriagePolicy

Revision 9 as of 2009-10-24 21:18:58

Clear message

Summary

This specification defines what the revised bug triage policy for Kubuntu versions >= should look like.

Rationale

Kubuntu tracked packages currently do get way to many bug reports, compared to the amount of people doing active bug triage. It is necessary to revise the policy of bug triage so that bug triage and bug management can be more efficient given the circumstances.

Scope and Use Cases

Use Cases

* Alex is Kubuntu user. From time to time he reports bugs against KDE packages at launchpad.net, his reports get processed quickly and resolved in the upcoming Kubuntu release. Important issues get resolved more quickly. Alex is happy to contribute something to the FLOSS community and sleeps well at night.

* Richard is developer. Richard wishes to be able to at any given time see what needs to be done to improve Kubuntu's packages. With a manageable list that tracks only packaging bugs and more serious upstream bugs, he can easily see what needs to be done without wading through hundreds of low priority upstream bugs, and help to resolve these issues more quickly.

* Jonathan is bug triager. Jonathan wishes to not have to maintain the drivers he wrote to interface his brain to the Launchpad API. With a bug policy that directs upstream bugs upstream, Jonathan is happy that he can more easily and efficiently prioritize and confirm the now-more-manageable amount of bugs in Launchpad.

* Stephan is upstream developer. Stephan likes to be able to receive bug reports from users with issues. With bugs going straight to upstream, Stephan can deal with these issues in a more timely manner as well as engage with the user for more effective debugging. As a result, the quality of both upstream and Kubuntu increase.

Policy

* Continue to track packaging issues and Kubuntu-specific wishlist items in Launchpad as usual. * Only track upstream bugs of High or Critical severity, as well as Medium-severity bugs that would fit SRU rationale once and if a fix becomes available.

Implementation

* Publicize policy change in various user venues, such as the Kubuntu and Ubuntu forums. * Close all existing bugs with a severity of low or wishlist that are being tracked upstream. * Create a nice list of pre-defined responses to aid with the above. They must not be overly polite to the degree where they sound robotic and canned. * Create a list of pre-defined bug responses to deal with common bug reports in general, using the same guidelines as above. * Do one last push to upstream currently non-upstreamed bugs, closing them if they do not fit the criteria mentioned in the policy.

CategorySpec