launchpad development|
Size: 3890
Comment:
|
Size: 4152
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| '''''Talk to the product strategist soon after cutting a first draft of this document''''' | ''This LEP contains information from the [[LEP/BugLinking|Bug Linking LEP]]'' |
| Line 22: | Line 22: |
| ''Who really cares about this feature? When did you last talk to them?'' | ''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 29: |
<<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 34: |
| <<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 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. |
| Line 55: | Line 42: |
<<Anchor(lp-project-manager>)>> === Launchpad Project Manager / TA === |
|
| Line 63: | Line 46: |
| <<Anchor(lp-project-manager-2>)>> === Launchpad Project Manager / TA (part II)=== |
|
| Line 69: | Line 49: |
<<Anchor(lp-dev>)>> === Launchpad Developer === |
|
| Line 80: | Line 56: |
'''From the [[LEP/BugLinking|BugLinking]] LEP''' '''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 |
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: Link to a blueprint, milestone or (best) a bug tag search across launchpad-project
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?
Stakeholders
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 Canonical OEM services developer
I want to be able to create a private clone of a public bug (or vice versa)
so that public and OEM-specific discussions can take place about the bug without undue disclosure of confidential information
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.
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.
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 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.
Nice to have
- Bug duplication described as a Bug Relationship.
Must not
What MUST it not do?
Out of scope
Subfeatures
Other LaunchpadEnhancementProposals that form a part of this one.
Success
How will we know when we are done?
How will we measure how well we have done?
Thoughts?
Put everything else here. Better out than in.
