Differences between revisions 2 and 20 (spanning 18 versions)

Bug Relationships

Bug relationships in Launchpad will allow users to record the relationships between two or more bugs in the system. So, where one bug is blocking another being fixed, that can be shown as a relationship and so on.

Contact: gmb
On Launchpad: Bugs tagged story-bug-dependencies

What this is not

A reimplementation of Blueprints (though as a side effect of its development we may see Blueprint usage drop off for some use-cases).
Anything to do with bug cloning and linking as detailed in LEP/BugLinking.

Rationale

Bug relationships are an oft-requested feature of the Launchpad Bug Tracker. As Launchpad has moved into feature-based development it has become more important to be able to track how much of the work on a given feature is done, whilst also tracking whether or not the feature itself can be considered complete.

Once Bug Relationships are implemented, developers will be able to declare the dependecies between two or more bugs. That means that they can clearly see, when starting a task, which bugs must be dealt with in which order. This can save a great deal of time, especially when (in the case of Launchpad, for example) it's not always obvious to a developer that other bugs block the one that they've just picked up.

Stakeholders

Launchpad Team Lead (Francis Lacoste)
Launchpad Project Manager (Matthew Revell)
Launchpad Technical Architect (Robert Collins)
Launchpad Squad Leaders (Gary Poster, Julian Edwards, Curtis Hovey, Deryck Hodge)
OEM (Joey Stanford, Steve Magoun, Cody A.W. Somerville)
Hardware enablement (Chris Van Hoof, Hugh Blemings)
Ubuntu (Bryce Harrington)

User stories

Long-form

As a Launchpad developer, working on feature XYZ, I want to be able to know where to start my work. Initially, I may think that I should start with Bug A, which is the simplest of the bugs tagged for the feature. However, further investigation reveals that Bug A is blocked by Bug B and Bug C. These bugs are not actually related to each other, but they are both in turn blocked by Bug D. The dependency graph for Bug A now looks something like this:

    D
  /  \
 B    C
  \  /
   A

Therefore, I need to start working not on Bug A, but on Bug D.

Short-form

As an Ubuntu developer
I want to be able to mark a bug as being blocked by another bug
so that it is obvious in which order bugs need to be tackled

As an upstream project maintainer
I want to be able to mark a bug in my project as being the result of a bug in a dependency
So that I can track the bug in my project separately from the dependency bug.

As an upstream project maintainer
I want Launchpad to notify me when all the dependencies for a bug have been resolved. So that I can commence work on the dependant bug.

As a Launchpad Project Manager (or TA)
I want to be able to mark bug X as a "meta bug" of bugs A, B and C
so that I can use the bug tracker to track the development of features

As a Launchpad Project Manager (or TA)
I want Launchpad to automatically close a meta-bug once all its child bugs are closed
so that I only have to watch the one bug in order to know that a given feature is complete

As a Launchpad developer
I want to be able to see the dependency/relationship tree for a bug
so that I know where to start with my work to fix the bug.

Constraints and Requirements

Must

Provide the ability to say that one bug is related to another in some way.
Provide the ability to mark a bug as a "meta bug" of two or more other bugs. The status of "meta" bugs will be automatically managed by Launchpad, so that "meta" bugs are resolved only when all the bugs which they encompass are resolved.
Provide a way to display clearly to users what needs to happen for a bug to become unblocked or, in the case of meta bugs, what must happen for a bug to be resolved.

Nice to have

Dependency graphs for bugs

Must not

Out of scope

Completely replacing (and removing) Blueprints.

Subfeatures

Success

How will we know when we are done?

A user will be able to say that the resolution of one bug is blocked by one or more other bugs.
Users will receive notifications when all the dependencies of a bug are resolved.
A user will be able to declare that a bug will be automatically resolved when all its dependencies are resolved.
We will be able to model Launchpad feature development stories using bug relationships rather than bug tags.

How will we measure how well we have done?

We will measure how often the identified stakeholders' teams each mark bug dependencies per week
We can review bug comments for newly filed bugs for the stakeholder groups to see if bug dependencies are now being modeled in the data rather than in the comments
We can review the percentage of bugs mentioned in comments that are not duplicates or related via a dependency chain; should this percentage differ significantly from the value before we implemented bug relationships it would indicate significant uptake of this feature (assuming other factors remain approximately stable).

Thoughts?

I've no idea how to measure success at this stage. I'd like to say "people use this more than they use Blueprints" but that's a) not a metric and b) foolish.
We probably need a lot of buy-in from the non-LP stakeholders to be able to consider this "done" but I'm not sure what form that buy-in would take.

Comments

gary 2011-09-26: Thank you, Graham! My comments got long, so I moved them to a separate page.

-  ⇤ ← Revision 2 as of 2011-09-01 12:08:47 → 
  Size: 2595
  Editor: gmb
  Comment:
+   ← Revision 20 as of 2011-10-11 10:41:00 → ⇥
  Size: 6152
  Editor: matthew.revell
  Comment: Clarify separation from bug linking
-Deletions are marked like this.
+Additions are marked like this.
 Line 1:
-'''''Talk to the product strategist soon after cutting a first draft of this document'''''
+## page was renamed from LEP/BugRelationships
-Line 5:
+Line 4:
-Bug relationships in Launchpad will allow users to record the links between two or more bugs in the system. So, where one bug is blocking another being fixed, that can be shown as a relationship and so on.
+Bug relationships in Launchpad will allow users to record the relationships between two or more bugs in the system. So, where one bug is blocking another being fixed, that can be shown as a relationship and so on.
-Line 8:
+Line 7:
-'''On Launchpad:''' ''Link to a blueprint, milestone or (best) a bug tag search across launchpad-project''
+'''On Launchpad:''' [[https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=story-bug-dependencies|Bugs tagged story-bug-dependencies]]
-Line 10:
+Line 9:
-''Consider clarifying the feature by describing what it is not?''
+== What this is not ==
-Line 12:
+Line 11:
-''Link this from [[LEP]]''
+. A reimplementation of Blueprints (though as a side effect of its development we may see Blueprint usage drop off for some use-cases).
 2. Anything to do with bug cloning and linking as detailed in [[LEP/BugLinking]].
 Line 16:
-''Why are we doing this now?''
+Bug relationships are an oft-requested feature of the Launchpad Bug Tracker. As Launchpad has moved into feature-based development it has become more important to be able to track how much of the work on a given feature is done, whilst also tracking whether or not the feature itself can be considered complete.
 Line 18:
-''What value does this give our users? Which users?''
+Once Bug Relationships are implemented, developers will be able to declare the dependecies between two or more bugs. That means that they can clearly see, when starting a task, which bugs must be dealt with in which order. This can save a great deal of time, especially when (in the case of Launchpad, for example) it's not always obvious to a developer that other bugs block the one that they've just picked up.
 Line 22:
-''Who really cares about this feature? When did you last talk to them?''
+ * Launchpad Team Lead (Francis Lacoste)
 * Launchpad Project Manager (Matthew Revell)
 * Launchpad Technical Architect (Robert Collins)
 * Launchpad Squad Leaders (Gary Poster, Julian Edwards, Curtis Hovey, Deryck Hodge)
 * OEM (Joey Stanford, Steve Magoun, Cody A.W. Somerville)
 * Hardware enablement (Chris Van Hoof, Hugh Blemings)
 * Ubuntu (Bryce Harrington)
-Line 26:
+Line 33:
-<<Anchor(story-name>)>>
+=== Long-form ===
-Line 28:
+Line 35:
-=== $STORY_NAME ===
+As a Launchpad developer, working on feature XYZ, I want to be able to know where to start my work. Initially, I may think that I should start with Bug A, which is the simplest of the bugs tagged for the feature. However, further investigation reveals that Bug A is blocked by Bug B and Bug C. These bugs are not actually related to each other, but they are both in turn blocked by Bug D. The dependency graph for Bug A now looks something like this:
-Line 30:
+Line 37:
-'''As a ''' $PERSON<<BR>>
'''I want ''' $FEATURE<<BR>>
'''so that ''' $BENEFIT<<BR>>
+{{{
    D
  /  \
 B    C
  \  /
   A
}}}

Therefore, I need to start working not on Bug A, but on Bug D.
-Line 35:
+Line 48:
-<<Anchor(ubuntu-developer>)>>

=== Ubuntu Developer ===
+=== Short-form ===
-Line 43:
+Line 54:
-<<Anchor(oem-services>)>>
+'''As an''' upstream project maintainer <<BR>>
'''I want''' to be able to mark a bug in my project as being the result of a bug in a dependency<<BR>>
'''So that''' I can track the bug in my project separately from the dependency bug.
-Line 45:
+Line 58:
-=== OEM Services ===
+'''As an''' upstream project maintainer <<BR>>
'''I want''' Launchpad to notify me when all the dependencies for a bug have been resolved.
'''So that''' I can commence work on the dependant bug.
-Line 47:
+Line 62:
-'''As a ''' Canonical OEM services developer<<BR>>
'''I want ''' to be able to create a private clone of a public bug (or vice versa)<<BR>>
'''so that ''' public and OEM-specific discussions can take place about the bug without undue disclosure of confidential information <<BR>>
+'''As a ''' Launchpad Project Manager (or TA) <<BR>>
'''I want ''' to be able to mark bug X as a "meta bug" of bugs A, B and C<<BR>>
'''so that ''' I can use the bug tracker to track the development of features<<BR>>
-Line 51:
+Line 66:
+'''As a ''' Launchpad Project Manager (or TA) <<BR>>
'''I want ''' Launchpad to automatically close a meta-bug once all its child bugs are closed<<BR>>
'''so that ''' I only have to watch the one bug in order to know that a given feature is complete<<BR>>
-Line 52:
+Line 70:
-''Have as many as you like. Group user stories together into meaningfully deliverable units. They'll be used as the driving elements of exploratory testing QA.''
+'''As a ''' Launchpad developer <<BR>>
'''I want ''' to be able to see the dependency/relationship tree for a bug<<BR>>
'''so that ''' I know where to start with my work to fix the bug.<<BR>>
-Line 58:
+Line 79:
- * The ability to say that one bug is related to another in some way.
 * Relationships between bugs shouldn't (usually) alter the way that either of those bugs behave
 * The ability to create a public "clone" of a private bug, so that OEM-specific bugs that rely on community interactions for fixes can be exposed for outside contributions without the OEM's internal conversations having to be made public.
+. Provide the ability to say that one bug is related to another in some way.
 2. Provide the ability to mark a bug as a "meta bug" of two or more other bugs. The status of "meta" bugs will be automatically managed by Launchpad, so that "meta" bugs are resolved only when all the bugs which they encompass are resolved.
 3. Provide a way to display clearly to users what needs to happen for a bug to become unblocked or, in the case of meta bugs, what must happen for a bug to be resolved.
-Line 65:
+Line 86:
- * Bug duplication described as a Bug Relationship.
+. Dependency graphs for bugs
-Line 69:
+Line 90:
-''What MUST it not do?''
-Line 73:
+Line 92:
+. Completely replacing (and removing) Blueprints.
-Line 74:
+Line 95:
-''Other LaunchpadEnhancementProposal``s that form a part of this one.''
-Line 81:
+Line 100:
+. A user will be able to say that the resolution of one bug is blocked by one or more other bugs.
 2. Users will receive notifications when all the dependencies of a bug are resolved.
 3. A user will be able to declare that a bug will be automatically resolved when all its dependencies are resolved.
 4. We will be able to model Launchpad feature development stories using bug relationships rather than bug tags.
-Line 82:
+Line 107:
+. We will measure how often the identified stakeholders' teams each mark bug dependencies per week
 2. We can review bug comments for newly filed bugs for the stakeholder groups to see if bug dependencies are now being modeled in the data rather than in the comments
 3. We can review the percentage of bugs mentioned in comments that are not duplicates or related via a dependency chain; should this percentage differ significantly from the value before we implemented bug relationships it would indicate significant uptake of this feature (assuming other factors remain approximately stable).
-Line 85:
+Line 114:
-''Put everything else here. Better out than in.''
+ * I've no idea how to measure success at this stage. I'd like to say "people use this more than they use Blueprints" but that's a) not a metric and b) foolish.
 * We probably need a lot of buy-in from the non-LP stakeholders to be able to consider this "done" but I'm not sure what form that buy-in would take.

== Comments ==

 * gary 2011-09-26: Thank you, Graham! My comments got long, so I moved them to [[/GaryComments|a separate page]].

launchpad development

Diff for "LEP/BugDependencies"