## page was renamed from LEP/BugLinking
'''''This LEP was extracted from private project bug cloning. It must be integrated with the bug dependency LEP.''''

= Bug cloning and linking =

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

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.


== Rationale ==

We are creating private projects. There is a large risk that confidential
information will be disclosed if projects share bugs. Instead of supporting
multiple bug tasks per bug (where each bug target is a Canonical partner),
Launchpad could link bugs together so that Canonical employees can see
that the two bugs are linked, but the partners cannot.

It is common practice is to report another bug on the other project instead
of adding another task. The situation will continue to exist after Canonical
is using private projects, but the inconvenience can be solved. The form
that asks the user to select the affected target can also allow the user to
edit the title and comment. The linked bugs may share status like a bug
watch so that when the bug defined to be the origin is fixed, the copies are
updated.


== Stakeholders ==

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

<<Anchor(user-stories)>>
== User stories ==

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


== Constraints and Requirements ==

=== Must ===

 1. When reporting that a bug affects another target with a potentially different privacy situation, a user should not have to consider whether or not to clone the bug, but rather Launchpad must do it automatically if required.

 1. The form must prompt the user to edit the title and description <<BR>>
 The user must ensure the information does not disclose confidential
 information. Ideally, if the title and description are fine, then choosing
 the affected project is all that the user needs to do.

 1. Users with access to both linked bugs can see that they are linked. <<BR>>
 While users can clone bugs by re-reporting a bug, it is not possible to
 link the bugs. So in the many cases where this was done, engineers cannot
 easily track to cloned bugs.


=== Nice to have ===

 1. Linked bugs get status updates like bug watches. <<BR>>
 When the origin-bug (the zero-vector in an infestation) is fixed, the
 clones indicate that a fix is available, or is fixed automatically.

 1. Bug links can describe the relationship of the link. <<BR>>
 It is common for the fix for one bug to depend on another, it would be nice
 to express that. Some bugs are made invalid if another bug is fixed.

=== Must not ===

 1. Do not require user to learn another way to say the bug affects another
 project. <<BR>> The existing workflow must recognise the situation, and
 prompt for the extra information to clone the bug.
 

== Subfeatures ==

None.

== Workflows ==

 1. Affects project|distro clones private bugs instead of add a task. <<BR>>
 When a bug is private (explicitly private or because the project it
 belongs to is private), the form allows the user to edit the title
 and description and clones the bug and links it to the other bug.


== Success ==

=== How will we know when we are done? ===

 1. A user can clone a bug faster than he can recreate it.
 
 1. A bug without confidential information in the title and description
 can be created in the same number of presses as adding another bug task.

 1. A user can see that the linked bugs and knows the origin-bug.


=== How will we measure how well we have done? ===

 1. Maybe measuring the time saves tracking the unlinked re-reported bugs.


== Thoughts? ==

Curtis:
 * Bug links relate to bug tags. Bug tags define a "like" relationship and
 that usually needs to be qualified. Bug tags doe not support dependency,
 nor do they point the direction

=== jml ===

 * Does "origin" really matter?
 * Have you seen mpt's thoughts on bug linking / dependencies?
 * How visible are the bug links themselves?  Can I see that there are linked bugs?  If not, where do the events that change my bug come from?