Bug lifecycle

Currently informational LEP on the lifecycle of bugs, especially with respect to statuses, assignment and milestones.

Contact: Jonathan Lange
On Launchpad: https://blueprints.launchpad.net/launchpad/+spec/other-o-bug-lifecycle; bug-lifecycle

Rationale

Ubuntu is driving hard toward being a much better quality distribution. As a part of this drive, Ubuntu is reviewing how it uses bugs and bug states in Launchpad.

Our aim here is to collect use cases for how bugs are used, identify points of friction and perhaps turn these into new requirements for how Launchpad should behave.

Note that these use cases should come from all of our stakeholders, not just Ubuntu.

Stakeholders

User stories

As a developer
I want a simple UI shown to users
So that I avoid noise changes caused by them eg thinking "Confirmed" is stronger than "Triaged"

As a current developer or tester
I want to spend minimum time updating, correcting, or discussing bug statuses
so that I can spend maximum time fixing or testing bugs

As a potential developer or tester
I want bug statuses to be simple
so that I’m more likely to contribute to something I understand

As a person who didn’t report a particular bug
I want to see few, or no, stock responses from status changes
so that those responses don’t clutter the discussion and muddy search results

As a visitor to a bug report
I want to see clearly what needs to happen next
so that I’m more likely to do it (or look for someone to do it)

Confirm fixes

As a developer
I want to see bugs that I think are fixed but need user testing
so that $BENEFIT

Waiting for replies

As a developer
I want a drive-to-zero queue of bugs that have not yet been triaged
So I can make sure all bugs are at least read once by a developer.

As a developer
I want to see a list of bugs with replies to my requests (e.g. clarification needed from reporter, testing needed, etc.)
so that I can quickly start to act on issues that I had previously been blocked on

As a developer
I want bugs to be automatically marked not-incomplete when a user provides the needed information (like in Answers)
so that I don't need to manually set them back to confirmed/triaged.

Permissions

As a participant across multiple projects
I want bugs to be world-writeable by default
So that people don't get confused by complicated rules about who can change what when

As a developer
I want a way to lock particular bugs (either status, or comments, or both)
So that we can avoid contentious bugs being reopened/reprioritized without edit wars and without tight access control everywhere

Handling design

As a participant across multiple projects
I want common bug metadata used consistently across projects
So I don't get confused when my Unity bug is marked Incomplete

As a Unity developer
I want a list of bugs I can work on, excluding those that are waiting for design decisions (perhaps those assigned to the design team)
So I can choose one I can actually work on today.

As a designer
I want to distinguish between problems that are known, and problems where the solution has been designed and is ready to code
so that I can see what design work I need to do.

The Unity designers currently use a separate dummy project solely to track the design of solutions for Unity bugs, which are in turn marked “Incomplete” while waiting for a design. In Ubuntu Software Center I use “Confirmed” for problems without a designed solution, and “Triaged” where the desired behavior is either obvious or specified. —mpt

Constraints and Requirements

Must

What MUST the new behaviour provide?

Nice to have

Must not

What MUST it not do?

Out of scope

Subfeatures

None.

Success

How will we know when we are done?

How will we measure how well we have done?

Thoughts?

Other reading

LEP/BugLifecycle (last edited 2011-07-16 00:10:23 by mbp)