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

[Rouillard, John]

> -----Original Message-----
> From: Tobias Brox [mailto:tobiasb at tobiasb.funcom.com]
> Apropos killings, I think it makes sense to just change the status, and
> not actually kill it ... and then have a cleanup tool which might be used
> on old tickets whenever we run low on disk space.

Agreed. I think you already have a "dead" ticket status that can be used for
that.

> With my suggestions, nothing really bad will happen if the linking breaks
> somehow.  I don't think it will be needed to do stuff recursively, I only
> think it will be needed to do things on a ticket and the dependent
> tickets.  So a loop will be harmless, though it usually won't make any
> sense to have a loop (and eventually we should have a test on this).
> 
> If a ticket that is linked up "both ways" is killed, then there might be
> some problems handling that.  I think it might be wishable that if ticket
> A is dependent on ticket B is dependent on ticket C, and ticket B is
> killed, A should be dependent on C.

Transitivity I think is implicit both ways. Both as dependency (component)
and as derived tickets. That's why I suggested the tree structure in my
original message. The problem comes in where you can have loops, then
transitivity isn't true, and where to assign the tickets is no longer
obvious (well obvious to me 8-).

Example A

       Ticket1 is componet of ticket3
       Ticket2 is component of ticket3
       ticket4 is derived from ticket1
	 
does that mean that ticket4 is derived from ticket2 as well? Not necessarily
since ticket4 may not be required for ticket2 to be solved. In my model,
ticket1 can't be a component of another ticket if it has a derived ticket.
Ticket4 is ok as a derived ticket of ticket3. Killing ticket3 would result
in the following:

      ticket1 stands alone
      ticket2 stands alone
      ticket3 is a derived ticket for both ticket1 and ticket2

This keeps the dependencies of the original system since all requirements
flow from the top downward (i.e. there is an implicit tree transversal
order).

General directed graphs are useful beasts, but I think they are overly
general for a trouble ticket system. They also bring up dependency problems
that we couldn't find firm rules for at my previous job (we didn't want
people solving the relationship issue in an ad-hoc fashion).

One other thing I haven't seen mentioned is searching ticket text (like
reqglimpse). That was very useful when new people had to solve problems.
They would do a reqglimpse looking for certain words and see what the old
tickets had to say. It was a great learning/teaching tool. It was wonderful
for help desk people.

-- rouilj