[rt-users] Some features I'd like to see

[Tobias Brox]

Follow up to the devel list.  I think the discussion about future design
belongs there :)

> Cool. One thing I implemented in req was the ability to split tickets.
> It used an X-req-parent header for a pointer to the parent ticket and a
> X-Req-child: and X-Req-child_done: headers for a list of the sub-tickets.
> Then a sub-ticket was closed, the child was moved to the X-Req-child_done
> header, and the parent ticket couldn't be closed till all the child tickets
> were closed.
> 
> Sounds like hiearchical tickets will provide this functionality.

I think there is quite some different kinds of hierarchies out there.  I
think "Links" in general makes more sense than hierarchies, and then
having "hierarchy" as a linking action.

The kind of hierarchy you describe above is like a project hierarchy.  One
request represents a worktask, and can be divided into several smaller
worktasks.  The main worktask is dependent on all the children worktasks
to be done.  This is more project management than request tracking.  RT as
of today is not a very well designed project management tool, but anyhow
we hope to do some efforts on this after 2.0 is released.  It's a top-down
approach, you have one ticket (with one requestor, often), and you split
it into several tickets ... might be same requestor, but different owners.

Another hierarchical need Jesse has described and which I agree is needed
very much is something that can replace the "merge"  functionality of rt
1.0.  The point is that several users complain about one issue, and it
should be easy to address all of those users sending only one mail.  At
the other hand, merging the requests like in 1.0 isn't always the right
thing to do, particularly not when dealing with external support.  You
want to address the requestors and their individual requests without
sending all other requestors mail about it.

Then there is a third kind of "hierarchicalliness" which we've already
implemented here and which we use freqently.  It might be quite related to
the first kind ... it's dependency.  As we use it here it's more about
workflow than anything else.  Example:

External requestor writes a request (#1) handled and owned by 1st line
support worker.

1 line support worker replies to #1 and the external requestor that this
issue might require some work.

1 line support worker writes a new request (#2), marking that #1 is
dependent on #2. #1 (automaticly) gets stalled, as 1 line support doesn't
have to worry about it for a while. #2 is handled and owned by some
experts. 

#1 is automaticly reopened when #2 is closed.

1 line support communicates to the external requestor that the issue is
dealt with.

-- 
Tobias Brox (alias TobiX) - +4722925871 - _urgent_ emails to
sms at tobiasb.funcom.com.  Check our upcoming MMORPG at 
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades, 
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)