You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@bloodhound.apache.org by Apache Bloodhound <bl...@incubator.apache.org> on 2013/02/11 14:55:54 UTC

[Apache Bloodhound] Proposals/BEP-0006 added

Page "Proposals/BEP-0006" was added by matevzb
Comment: initial draft
Content:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
= BEP 6 : Ticket Relations #overview

[[PageOutline]]

|| '''BEP''' || 6 ||
|| '''Title''' || Ticket Relations ||
|| '''Version''' || Draft ||
|| '''Last-Modified''' ||  ||
|| '''Author''' ||  ||
|| '''Status''' || Draft ||
|| '''Type''' || Standards Track ||
|| '''Content-Type''' || [wiki:PageTemplates/Proposals text/x-trac-wiki] ||
|| '''Created''' ||  ||
|| '''Post-History''' ||  ||

----


== Abstract
One of the deficiencies in the ticket handling workflow is the lack of any kind of ticket relations. Although referencing other tickets is possible in the fields that support WikiFormatting (e.g. comments), this is far from ideal. In order to fully support advanced ticket handling workflows, implementation of first-class ticket relations is vital.


== Motivation
Most, if not all competing issue tracking products provide at least one type of ticket relations. Attracting a wider audience in terms of both customers and developers may prove even more difficult without such functionality.
There are several Trac plugins available which implement ticket relations to some extent, however without support for multiple relation types.


== Proposal
Ticket relations can be implemented either as a Bloodhound addon, or as a Trac plugin. The latter may be the preferred choice, as Trac users could also benefit from this feature.

^This has also been discussed to some extent on the bloodhound-dev mailing list, Ryan proposed merging two existing Trac plugins (!MasterTicketsPlugin and !SubticketsPlugin) into one, and continuing from there.^

=== Details
Ticket relations are defined by source ticket, target ticket and relation type. Source and target tickets can belong to different products.
The following relation types shall be implemented by default:
 Duplicate::
  indicates the defect was already reported in another ticket. This type should be bound to the "duplicate" ticket state. When a ticket is resolved as duplicate, users should be required to enter the ID of the original ticket.
 Parent/child::
  allows for splitting "larger" tickets into sub-tickets for more fine-grained control. This is especially useful for the "task" type tickets. Multiple levels of hierarchy should be supported.
 Dependency/blocker::
  a ticket cannot be resolved until all of its dependencies have been resolved.

Additionally it should be possible to define custom relation types with no semantic meaning through the admin interface.

=== Ticket Relations with Regards to Other New Features
==== Multiproduct (BEP-0003)
In addition to relations within one product, this feature will allow referencing tickets from other products as well. This will enable easier tracking of closely related products, e.g. a Bloodhound ticket could be marked as dependent on a Trac ticket, or vice-versa.

==== Improved Search Architecture (BEP-0004)
The new search functionality should also allow searching for ticket relations. This will enable users to quickly find dependencies, duplicates, sub-tasks etc. Search should also be inter-product, i.e.
able to find related tickets from other products.


=== User interface
Ticket relations will be displayed in the ticket view, below the ticket properties as depicted in the image below. The ticket view will also allow for removal of relations, one at a time, by clicking on the remove icons.
[[Image(ticket_relations_1.png)]]

The "Manage Relations" button will open up the full form for adding and removing ticket relations, presented in the image below.
[[Image(ticket_relations_2.png)]]

Handling of duplicates will be bound to marking a ticket as a duplicate. In that case the user will also have to enter the ID of the duplicate ticket.
[[Image(ticket_relations_3.png)]]

=== Constraints
Each ticket can have multiple relations to other tickets, and those relations can be of different types. There are however certain constraints that should enforced by implementation:
* A ticket with parent/child relationships cannot relate to its ancestors or descendants with another relation type (i.e. a parent cannot be marked as a duplicate/blocker of its children or vice-versa).
* Parent/child relationships should be "one-way" (i.e. tree hierarchy, not a graph with backward relationships).
* Parent/child relationships cannot reference multiple products.
* A ticket cannot be marked as a duplicate of a ticket from a different product.
* A ticket cannot be marked as a duplicate of a newer ticket (only vice-versa).
* A ticket cannot be marked as a blocker of another ticket, and be blocked by the same ticket.

=== Usage Scenarios
Some usage scenarios may need additional/special handling:
* What to do if a duplicate is reopened, i.e. it turns out it wasn't a duplicate after all? Should the duplicate relation be removed (and user informed beforehand)?
* Should parent/child relations be allowed only for tasks and possibly enhancements? Does it make sense for defects to be split in this manner?

== Backwards compatibility
In general there are no compatibility issues with previous versions, except for the duplicate relations. Currently duplicate tickets are only marked as such, with no indication of which ticket is the original in question. Since the duplicate ID will become required, existing tickets will either need to be upgraded somehow, or left as they are and handled in a special manner.


== Resources
Source code management is powered by [http://subversion.apache.org/ Apache™ Subversion].

UI mockups were made using Balsamiq Web Demo [http://builds.balsamiq.com/b/mockups-web-demo/]


== References
=== Bloodhound Proposals
* [wiki:BEP-0003 BEP 3 : Multi-product architecture]
* [wiki:BEP-0004 BEP 4 : Improved search architecture]

=== Trac plugins
* https://trac-hacks.org/wiki/MasterTicketsPlugin
* https://trac-hacks.org/wiki/SubticketsPlugin
* https://trac-hacks.org/wiki/TicketRelationsPlugin
* https://trac-hacks.org/wiki/TracTicketReferencePlugin

== Copyright
Copyright © 2009-2012 The [http://www.apache.org Apache Software Foundation] [[BR]] 
Licensed under the [http://www.apache.org/licenses/LICENSE-2.0 Apache License, Version 2.0].

Apache Bloodhound, Apache, the Apache feather logo, and the Apache Bloodhound project logo are trademarks of The Apache Software Foundation.
-------8<------8<------8<------8<------8<------8<------8<------8<--------

--
Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0006>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker

This is an automated message. Someone added your email address to be
notified of changes on 'Proposals/BEP-0006' page.
If it was not you, please report to .