incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <>
Subject [Apache Bloodhound] Proposals/BEP-0006 added
Date Mon, 11 Feb 2013 13:55:54 GMT
Page "Proposals/BEP-0006" was added by matevzb
Comment: initial draft
= BEP 6 : Ticket Relations #overview


|| '''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:
  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.
  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.
  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,
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.

The "Manage Relations" button will open up the full form for adding and removing ticket relations,
presented in the image below.

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.

=== 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
* 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

== Resources
Source code management is powered by [ Apache™ Subversion].

UI mockups were made using Balsamiq Web Demo []

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

=== Trac plugins

== Copyright
Copyright © 2009-2012 The [ Apache Software Foundation] [[BR]] 
Licensed under the [ 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.

Page URL: <>
Apache 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 .

View raw message