#886: Add support for Master tickets
-------------------------------+--------------------------------------------
Reporter: dmurphy25@csc.com | Owner: cboos
Type: enhancement | Status: assigned
Priority: normal | Milestone: 1.0
Component: ticket system | Version: 0.7.1
Severity: normal | Resolution:
Keywords: |
-------------------------------+--------------------------------------------
Comment (by dmbrucker@gmail.com):
I'm really interested in this feature, it will really add some useful
workflow capabilities. I think it would be better, though, to make it more
generic: don't have a special type of ticket for a Master Ticket. A ticket
is a ticket is a ticket, each capable of N-levels of dependence and
reference. It should be the context of the reference that gives a ticket
its meaning in relation to the other tickets.
I see three types of relationships:
1) '''Depends on/Depended on by''': This would be a true blocking
relationship; the ticket could not be resolved until each ticket it
depends on is resolved. It does not necessarily mean that any ticket is
the parent or child of the other, just that there is a required order to
their completion. One ticket may be depended on by multiple other tickets,
i.e. Tickets A and B both depend on C. A ticket can be in any milestone
greater then or equal to the highest milestone of its dependencies.
2) '''Parent of/Child of''': This is the task+subtask context described
here and #31. The parent encapsulates a portion of work that is
accomplished through its collection of children. A child can only have one
parent. This type is definitely different then a milestone. The Milestone
page could either include or elide the child tickets, with the opposite
view being available with another checkbox below "Show already completed
milestones". Moving a ticket to another milestone would include the option
of also moving some or all its children. Individual child tickets could be
left in milestones lesser then their parents, especially if they are
depended on by a ticket in the lesser milestone.
3) '''Duplicate of''': All of the tickets describe a similar
bug/feature/request/problem. If A is a duplicate of B, and B is a
duplicate of C, then A is a duplicate of C. Taken as a group of tickets,
they all talk about pretty much the same thing. Since trac uses a linear
display of comments, instead of threaded, it might be better to keep the
tickets unmerged for readability and context. Rather then merging the
tickets, an interesting way of handling this might be to create a new
ticket of type 2 above, that is the parent of all the duplicate tickets,
just so it would be easy to find all the dups and see what had been
discussed in each.
Each of these relationships is independent of the rest. One ticket can
depend on another ticket of which it is not the parent. A parent can
explicitly depend on one of its children, requiring the child to be
resolved first. One ticket can be the parent of 9 other tickets, 3 of
which are duplicates. Etc. There may be more relationships that would be
useful to implement in the future.
This is a lot of description, and is basically just a brain dump. My main
point is that tickets should be generic when it comes to relationships. I
think it will help to keep them more usable and extensible later.
--
Ticket URL: <
http://projects.edgewall.com/trac/ticket/886>
The Trac Project <
http://trac.edgewall.com/>