launchpad development
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
- 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
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
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
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?
- 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
