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

[Tobias Brox]

> > Anyway, I think nothing really bad can happen if somebody creates a
> > loop on mistake.
> 
> I'm not sure about that. The easiest way to find ticket dependencies/track
> completion is to do a traveral of the tree. If a loop is created, then the
> traversal code need to determine that a loop exists and stop walking that
> portion of the tree. I guess the loop detection code wouldn't be that bad,
> but I would prefer it not to be necessary
> for heavily used programs like rtq or the web interface.

Well, if you're worried about wasting processor cycles, I don't think
that's a big issue.  As I see it, at a typical installation, only some
small part (20% maybe) of the tickets needs to be linked somehow, and only
some small part of this needs to be linked more than once.  There won't
really be often that a loop check would need to traverse a big graph.

> > In my system, it would not make sense to make a ticket dependent
> > on a request that is either stalled or resolved.  I think it 
> > makes sense to test this as well.
> 
> Strange. That happens a lot where I have been.

Ok, you're right.

> > #1: user A says "mail server is not working, and i demand compensation
> > since I've paid for using this mail server"
> > #2: user B says "mail server is not working"
> > #3: 1st line support "spawns" #3: "mail server is not working"
> > 	to techincal support
> > #4: request from 1st line support to the customer billing department:
> > 	"please make a reduction for user A"
> > 
> > > does that mean that ticket4 is derived from ticket2 as well?
> > 
> > Uhm ... no?  Absolutely not?
> > 
> > Request #4 and #3 will be open, the others stalled, in my system.
> 
> But 1 and 2 aren't stalled (see below) really.

In my system (that is actually up running today) they will be - and it
generally makes sense, I think.  We don't want to bother more with the
individual users complaining that the mail server is down until we've
actually fixed the mail server, and when we've actually fixed the mail
server we'd like to send mail to all of them. (the latter is not possible
as of my system today)

> Work is progressing just under another ticket number.

Exactly!  Work is progressing under ticket #3 and #4, which is individual
tickets, except that they are linked up to #1 and #2.  When #3 and #4 was
created, parts from #1 was quoted, so the content is easy available in #3
and #4.  #1 and #2 will be opened as soon as #3 and #4 is resolved. 
Anyone that are viewing #3 or #4 through the web ui might click links to
have a look at the stalled requests.  That's how my system of today works,
and it actually works quite nice.

> The state of ticket 3 is also the state of
> tickets 1 and 2.

In your system, maybe.  In my ideas, it's only up to the user to
distinguish "group tickets" from "parent tickets".  When handling the
pending ticket, the WebRT user should indicate if the dependent should be
resolved and/or if the reply should go also to the dependent requestors.
If #3 is resolved, and #4 is open, and a user asks for "resolve parent
ticket", then #2 will be resolved, but not #1.  Anyway, in my system a
WebRT user can force #1 to be resolved.  And it might make sense (it
quite often does make sense here) when the external requestor doesn't need
to be informed about the outcome of request #4 (i.e. if a lot of
users report about a serious abuse done by an employee, it might result
into new tickets, "investigate incident" and "see what we can do with this
employee".  Those things are seldom relevant for the external requestor, 
but it makes sense to link it up anyway).

> In my scheme ticket4 is the problem. You are right in that
> it belong to ticket1, but it makes
> life a hassle, because closing ticket 3 no longer implies that ticket1 can
> be closed. Only when ticket4 and ticket3 are closed is ticket1 closed.

I just don't think it is a problem using my general dependencies.  With
group tickets and derived tickets there are such problems - because the
design is a bit too static.

> In my case, they would never have been closed/stalled. Maybe we need 
> another status for those tickets. Then they would be moved to open status
> from this new status.

We've come down (particularly by investigating usage and theoretical usage
patterns here) that the open/stalled/resolved/killed statuses are
sufficient when combined with the possibility to "spawn" new requests.
People often want to have more/different status settings, and it also
makes sense allowing it, but it always boils down to that each
site-specific status can be mapped into one of the four above.

We had an old in-house-built bug tracking tool with slightly different
status levels.  There were "fixed" which ment that it was fixed, but QA
should still have a look at it, and it was "resolved" which ment that QA
had actually tested the fix.  In my system, it would be one queue for QA
and one queue for the programmers - when somebody finds a bug, they enter
a ticket into the QA queue ("seems like a bug, test this"), and QA
"spawns" the ticket into a bug report ticket in the programmers queue.  At
this point, the ticket in the QA queue is stalled, and the bug report is
open.  Eventually the programmers resolve the bug report, and the ticket
in the QA queue will reopen.

> Also we seem to be using stalling differently. Stalling was used for
> suspending work pending an outside event. Ticket stalled too long implied
> that somebody wasn't getting the assistance they needed to do their job.

That's where alarm tools come into play.  There already exists such a tool
for rt 1.0, and it's quite important I think.  My idea is to always set
the due date (i.e. auto-set it to some monthes in advance) and
unresolved tickets approaching the due date should initiate an email 
alarm.

> That's fine I can handle top == left and bottom == right. I think both ways
> work.
> I was just using an analogy to a tree (um the CS kind with the trunk at the
> top).

I think that what we have is a graph, and not a tree.  Well, maybe it
usually will be like a tree with a root anyway.

[ about general directed graphs ]
> > It's a general approach, and I love it.
> 
> But then the algebra of the system is more complex.

No, actually I've kept complexity at a bare minimum in my current RT.
People are allowed to set up dependency links, which might be followed
(as clickable links) through the UI.  Except for this, the only
"automatic" thing there is in the system is that a stalled dependent
ticket gets reopened when the dependency (lower/righter) gets resolved ...
and that an open ticket gets stalled if we make it dependent on an open
ticket.  This tiny simple little algoritm handles the workflow great in
our company!

The additions I'd like to see for 2.0 is:

- Possibility for a user to send replies to the requestors of the
dependent tickets.  As I see it, we don't need recursivity here, so it
shouldn't be complex and it wouldn't really need to check for loops.

- Possibility for a user to request the dependent tickets to be resolved.
This might be a little bit complex, but I see no problems with it.

- Nice view of graphs.  This might be complex, but it's not that
important, I think (Bugzilla has such a graph view, as there is seldom
more than only a few tickets beeing linked together, I've never seen it
be used for anything other than bragging about how nice it would be if
there was more dependencies.. :)

> Well one issue I see is that you can't close ticket1 when you close ticket3
> in the example above.

That's very easy - in my system, there is nothing stopping a user from
doing just that.  And I think it's OK.

> Sending email on ticket3 that the problem is solved isn't
> true for ticket1 because s/he still want's a fee reduction which may or may
> not be done.

Well, that might be an issue, but as long as the support workers pay
attention, it will be just OK.

First of all, I think any site should have a strict policy that any email
sent out to more than one requestor should not appear as a private email.
So I think it's wrong to send this email:

"We've just received your email about the mail server beeing down.  Well,
the problem is fixed now.  Thanks for your report, and have a happy
weekend".

...while this one is OK to send, also to requestor of #1:

"This email is sent to everybody that have been complaining about our mail
server beeing down.  Well, it's now up running again - and we're going to
buy more disk so this won't happen again.  If this email doesn't answer
your original request, please write a reply.  Thanks for your report."

...particularly if support (when handling #1) also wrote a more specific
reply ("We've sent your request about compensation to the billing
department").

> How do you handle that issue? The easiest way would be to enforce no ticket
> is closed till all of its dependents are closed, but it breaks the rule that
> a group ticket closing closes all its components.

Keep It Simple Stupid.  No enforcements, no rules and it will work just
fine.  No distinction between "group tickets", "derived tickets", etc,
except maybe in the users mind ... it's all just tickets to RT.

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