= Bug lifecycle =

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

'''Contact:''' Jonathan Lange <<BR>>
'''On Launchpad:''' https://blueprints.launchpad.net/launchpad/+spec/other-o-bug-lifecycle; [[https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=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 ==

 * Kate Stewart, Ubuntu Platform, 2011-04-20
 * Allison Randal, Ubuntu Platform
 * Martin Pool, upstream developer
 * Matthew Paul Thomas, Ubuntu Software Center

== User stories ==

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

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

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

'''As a''' person who didn’t report a particular bug <<BR>>
'''I want''' to see few, or no, [[https://wiki.ubuntu.com/Bugs/Responses|stock responses]] from status changes<<BR>>
'''so that''' those responses don’t clutter the discussion and muddy search results

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

<<Anchor(confirm-fixes)>>
=== Confirm fixes ===

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

=== Waiting for replies ===

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

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

 ''Implicit assumption: Following up to a reporter who has replied to a request is more urgent than following up to an initial report. —mpt''

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

=== Permissions ===

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

As a developer<<BR>>
I want a way to lock particular bugs (either status, or comments, or both)<<BR>>
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<<BR>>
I want common bug metadata used consistently across projects<<BR>>
So I don't get confused when my Unity bug is marked Incomplete

As a Unity developer<<BR>>
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)<<BR>>
So I can choose one I can actually work on today.

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

''The Unity designers currently use [[https://launchpad.net/ayatana-design|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? ==

 * Confusing states: Incomplete with(out) answer, Invalid/  Opinion, Confirmed / Triaged and Fix Committed / Fix Released, Inprogress/FixCommitted, Triaged/Undecided
 * In-app documentation of bug statuses would ''really'' help
 * There is no way we can find a set of statuses that will match everyone's workflows, but there is value in a common set of canonical statuses. One way to solve it is to use a global simplified status (mpt's list) with a per-project configurable list of substatuses that will map the workflow of the project. Declined +opinion. In Progress +needstesting. That substatus would show in bug searches, be more than a simple tag. – ttx
 * Looking at what kind of workflow-related tags people use is a good way of gaining insight as to use cases

== Other reading ==

 * IssueTracker
 * https://dev.launchpad.net/LEP/TrackingQualityAssurance
 * https://wiki.mozilla.org/BugzillaWorkflowImprovements
 * https://dev.launchpad.net/LEP/OnlySeriesTasks
 * https://wiki.ubuntu.com/AllisonRandal/BugSurveyDraft