Differences between revisions 5 and 13 (spanning 8 versions)

This LEP contains information from the Bug Linking LEP

Bug Relationships

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.

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

Consider clarifying the feature by describing what it is not?

Link this from LEP

Rationale

Why are we doing this now?

What value does this give our users? Which users?

Bug links are a way of indicating that two bugs are related.

From LEP/BugLinking:
Using the affect project or distro link will disclose private information in bug comments, commentators, and subscribers to the other project if the project is added as a bug task to the bug. The link could copy the public portion of the bug and permit the user to redact the description to create a new bug. The two bugs are linked and users with permissions to see both projects/bugs may see that they are linked. The links could explain their relationship, such as IS, LIKE, or DEPENDS.

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)

Copied from LEP/BugLinking

OEM (Joey Stanford, Steve Magoun, Cody A.W. Somerville)
Hardware enablement (Chris Van Hoof, Hugh Blemings)
Ubuntu (Bryce Harrington)

User stories

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 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.

From the BugLinking LEP:

As a driver of a private project
I want clone and link a bug that affects another project
so that confidential info is not disclosed to the other project

As a contributor to a private project
I want clone and link a bug that affects another project
so that confidential info is not disclosed to the other project

As a contributor to multiple projects
I want to be able to clone a bug from one project to another project
so that I can have separate conversations about the bug, each with their own disclosure level

Constraints and Requirements

Must

Provide the ability to say that one bug is related to another in some way.
Ensure that relationships between bugs shouldn't (usually) alter the way that either of those bugs behave
Provide the ability to mark a bug as a "meta bug" of two or more other bugs.
Provide 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.

Nice to have

Bug duplication described as a Bug Relationship.
Dependency graphs for bugs
Provide the inverse of "Must" #4: i.e. make it possible to create a private clone of a public bug.

Must not

Out of scope

Completely replacing (and removing) Blueprints.

Subfeatures

Other LaunchpadEnhancementProposals that form a part of this one.

Bug Linking

Success

How will we know when we are done?

We will know that this feature is complete when we can accurately model Launchpad feature development stories using bug relationships rather than bug tags (see thoughts).

How will we measure how well we have done?

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.

-  ⇤ ← Revision 5 as of 2011-09-01 15:52:54 → 
  Size: 3541
  Editor: gmb
  Comment:
+   ← Revision 13 as of 2011-09-26 09:42:48 → ⇥
  Size: 5276
  Editor: gmb
  Comment:
-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/Drafting/BugRelationships
''This LEP contains information from the [[LEP/BugLinking|Bug Linking LEP]]''
-Line 8:
+Line 9:
-'''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 20:
+Line 21:
+Bug links are a way of indicating that two bugs are related.

'''From [[LEP/BugLinking]]''':<<BR>>
Using the affect project or distro link will disclose private information
in bug comments, commentators, and subscribers to the other project if the
project is '''added''' as a bug task to the bug. The link could copy the
public portion of the bug and permit the user to redact the description to
create a new bug. The two bugs are linked and users with permissions to
see both projects/bugs may see that they are linked. The links could
explain their relationship, such as IS, LIKE, or DEPENDS.
-Line 22:
+Line 34:
-''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)

''Copied from LEP/BugLinking''
 * OEM (Joey Stanford, Steve Magoun, Cody A.W. Somerville)
 * Hardware enablement (Chris Van Hoof, Hugh Blemings)
 * Ubuntu (Bryce Harrington)
-Line 25:
+Line 46:
-<<Anchor(story-name>)>>

=== $STORY_NAME ===

'''As a ''' $PERSON<<BR>>
'''I want ''' $FEATURE<<BR>>
'''so that ''' $BENEFIT<<BR>>


<<Anchor(ubuntu-developer>)>>
=== Ubuntu Developer ===
-Line 42:
+Line 51:
-<<Anchor(upstream-maintainer)>>
=== Upstream maintainer ===
""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
""So that"" I can track the bug in my project separately from the dependency bug.

<<Anchor(oem-services>)>>
=== OEM Services ===

'''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>>


<<Anchor(lp-project-manager>)>>
=== Launchpad Project Manager / TA ===
+'''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 63:
+Line 59:
-<<Anchor(lp-dev>)>>
=== Launchpad Developer ===
+'''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 70:
+Line 67:
+'''From the [[LEP/BugLinking|BugLinking]] LEP:'''
-Line 71:
+Line 69:
-''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 ''' driver of a private project<<BR>>
'''I want ''' clone and link a bug that affects another project<<BR>>
'''so that ''' confidential info is not disclosed to the other project<<BR>>

'''As a ''' contributor to a private project<<BR>>
'''I want ''' clone and link a bug that affects another project<<BR>>
'''so that ''' confidential info is not disclosed to the other project<<BR>>

'''As a ''' contributor to multiple projects<<BR>>
'''I want ''' to be able to clone a bug from one project to another project<<BR>>
'''so that ''' I can have separate conversations about the bug, each with their own disclosure level
-Line 77:
+Line 86:
- * Provide the ability to say that one bug is related to another in some way.
 * Ensure that relationships between bugs shouldn't (usually) alter the way that either of those bugs behave
 * Provide the ability to mark a bug as a "meta bug" of N other bugs (where N > 1).
 * Provide 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. Ensure that relationships between bugs shouldn't (usually) alter the way that either of those bugs behave
 3. Provide the ability to mark a bug as a "meta bug" of two or more other bugs.
 4. Provide 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.
-Line 85:
+Line 94:
- * Bug duplication described as a Bug Relationship.
+. Bug duplication described as a Bug Relationship.
 2. Dependency graphs for bugs
 3. Provide the inverse of "Must" #4: i.e. make it possible to create a private clone of a public bug.
-Line 89:
+Line 100:
-''What MUST it not do?''
+=== Out of scope ===
-Line 91:
+Line 102:
-=== Out of scope ===
+. Completely replacing (and removing) Blueprints.
-Line 97:
+Line 108:
+ * [[LEP/BugLinking|Bug Linking]]
-Line 101:
+Line 114:
+We will know that this feature is complete when we can accurately model Launchpad feature development stories using bug relationships rather than bug tags (see thoughts).
-Line 102:
+Line 117:
-Line 105:
+Line 122:
-''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.

launchpad development

Diff for "LEP/BugDependencies"