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

[Tobias Brox]

This mail got really huge.  Maybe I should have gone through it some more
times just to be sure.  The dependency links will be there in 
RT 2.0, the rest is mostly thinking about how to develope it after 2.0.

I suddently realized that both "Grouping", "Parent-Child" and
"Interrelationships" can be done by only using my Dependency links if
they're made a bit more powerful. I don't think it makes much sense making
a difference on the tickets regarding how they're linked together.  Any
ticket might be dependent on any other ticket.  I think it makes sense.

> Jesse>Eventually I see several distinct ticket types:
> Jesse>      * User Request
> Jesse>      * Trouble Ticket
> Jesse>      * Bug
> Jesse>      * Task

I think what Jesse is thinking about here are extentions to the "regular" 
ticket today ... related to the different usages for RT.  I hope we can
get this possible through some kind of "extention module" system rather as
static, integrated part of RT.  RT 2.0 is missing some way to add/modify
ticket actions "dynamicly", but I hope we can do some changes after the
2.0 release.

As it is in 2.0, we only have one class, Ticket.  As of 2.0 it has some
things related to worktask, but else it's quite close to "User Request",
I'd daresay ... and why not, RT (both 1.0 and 2.0) is primarly designed
for handling user requests.


1. USER REQUEST

A pure user request have one (and only one) requestor, is typically
initiated by an email (but eventually a phone call or similar) and doesn't
contain much more information than the communication, the status, the
owner and the timestamps.

On some sites a priority field is needed.  In a pure user request, it
should be set automaticly, based on site (queue) policy.  One way is by
looking up the priority from a requestor table ... it would typically be
sane to give people who are paying for proffesional support highest
priority, while giving a very low priority to stupid non-paying people who
are frequently nagging for help.  It might also make sense to alter the
priority after certain rules, i.e.  respecting priority wishes from the
requestor, if the subject line contains a significant amount of exlamation
marks ('!') or uppercase letters, the priority should drop considerably
for requestors not registered as paying customers, while it should
increase fot the paying customers, if the word "windows" or "microsoft" is
mentionated, the priority should drop, etc. 

Some sites might need due dates.  Those should also be set automaticly,
based on site (queue) policy.  It might make sense to have policies like
"all requests should be answered to within 60 minutes for registered
paying customers and 24 hours for non-registered users", etc.

A pure user request does not involve more work than giving an answer.  The
due date / priority affects are typically used for selecting the order
mails are answered in.  It's not common to postpone resolving requests.

2. TROUBLE TICKET

I'd daresay this is the typical requests a technical support department
might get ... configuration troubles, etc.  It can be a bit similar to
bugs, but it's not related to software development.

3. BUG TICKET

Bug ticket has with software bugs to do.  This is not relevant for all RT
users, so I'd daresay we should try to make it as an extention package. 
but quite a lot of us use RT in environments where software is developed
or maintained, and it might make some sense using RT as a light-weight bug
tracking tool.  The requestor is either the person reporting the bug, or a
person working as 1st line support. 

In a typical bug tracking tool, some extra information about the status
is needed, typically containing something like "could not reproduce
bug", "bug fixed", "will not be fixed", "could not locate bug", "duh -
this is not a bug, this is a feature!" etc.

There should also be more information related to the priority, i.e.
"critical security bug", "critical stability bug", "bug might be worked
around", etc.

A persistant, editable comment field might be nice in addition to the
normal correspondence/comments.

Each bug is associated with a module of code and/or a project (might be a
worktask). Etc. 

Priorities will usually be set by the requestor (bug report submitter).  
Usually the due dates are for "remove all (critical) bugs (related to
module X)" rather than for the individual bugs. 

A typical bug requires a small and quite unpredictable amount of work.


4. (WORK)TASK

A task is a worktask, a Ticket in a project management tool.  RT is not a
project management tool, but it might make sense storing small
worktasks there anyway.  Some bugs will eventually need more work, thus
they become (or initiates) a worktask.

We would at least need those extra fields when/if we're going to 
develope RT into a full-fledged project manager:

- Time/Resources spent (billing field - will be included in the 2.0
Tickets)

- Planned start date

- Estimated total time consume

- Progress done (i.e. "60% finished")

- Maybe multiple workers might be associated with one ticket
(though, I'd say that in most cases it's better/easier to create new
subtickets).

- Due date

- Static Priority (how important it is to get started and finished
quickly)

- Final Priority (how important it is to reach the deadline)

- Dynamic Priority (automaticly set priority, dependent on the static
priority, the due date and the progress)

.......

As I see it, workflow and category overlapping might be handled by
creating new tickets and setting up dependency links.  What we get is not
one hierarchy, rather a n:n relationship between tickets.  I can't see a
problem with that.  A user can, but should not, make any loops.  Maybe the
"link" action should always check for loops and eventually return an
error. 

Loops aren't really a problem in the scheme below anyway.  It's possible
to send a reply to "requestors of this ticket + tickets dependent on this
ticket" instead of just "requestors of this ticket" ... but not possible
to do a recursive scan after requestors.  Actually I think that for the
very most practical situations you only want to send a reply to two levels
of a hierarchy.  Eventually it should be possible to kill off requests
which has dependencies, and the dependency links should bypass the killed
request (for dealing i.e. with duplicated bug reports).

I think it should be possible/wishable to set some attributes at the
dependency links, but in the examples below I'm only using a general 
"dependency link"

Examples:


SEVERAL USER REQUESTS -> ONE BUG:
=================================

1. A user sends a mail which arrives as a User Request (1)
ticket (#41). The mail sounds something like "I have problems".

2. First line support initiates a dialogue with the requestor, to get the
problems a bit clearer defined.

3. First line support clicks at a link with the name "Search in bug
database".  He discovers that Ticket #23 is a Bug Report (3) that matches
the bug found.  

4. First line support presses a "Link" button. #41 gets marked as
"dependent" on #23. #41 gets stalled.

5. Somebody fixes the bugs and resolve #23.  All dependent, including #41
gets opened.

6. First line support sees one of the opened user requests, and he
decides to send a mail to all those that has reported the bug that it's
now fixed.

7. First line support enters #23 and chooses "write reply".  He writes a
message, he choose "resolve" and ticks a box for "Include the dependent
ticket(s)".  The message goes to all dependent ticket, that is all user
requests about this bug.  All dependent tickets that are not dependent on
other non-resolved tickets gets resolved.

Many user requests can be dependent on one bug report.  One user request
can also be dependent on several bug reports if the requestor reports more
than only one bug in the same email.


ONE BUG THAT ACTUALLY IS A WORKTASK
===================================

8. Request #42 comes in, action 1., 2. and 3. is repeated but nothing
found in the bug database.  First line support resolves the request,
becuase the external user is not really interessted in the bugfix.

9. 1st line support clicks at "create new bug report" and enter
information about the bug. Ticket #43 is created, #42 is dependent on
#43.

10. #43 gets worked on, and somebody discovers that the software module
has to be redesigned completely to fix this bug.  A Work Task (4) (Ticket
#44) is created (redesign this piece of shit).  #43 gets dependent on #44
and stalled.

11. New tickets #45, 46 and 47 is made (Work Tasks (4), subtasks of #44),
and ticket #44 is made dependent on those.  Every time a subtask is
completed, a reply/resolve at "this and dependent" is done (like in action
7).

12. Eventually as the last of the three subtasks gets resolved, Ticket #44
also gets resolved.  As #44 is resolved, #43 (the bug) is opened.  The
owner of the bug fixes up what might be left of the bug and resolves it.
The user request is resolved and stays so.

One user request can be dependent on one bug report that can be dependent
on one worktask which might be dependent on several (sub) worktasks.


THE FULL HARDDISK SYNDROME
==========================
13. The mail server harddisk goes full, and 50 users report that the mail
server seems jammed.

14. 1st line support writes a Trouble Ticket (2) (#158) "mail server is
down" to technical support.

15. 1st line support links all the 50 user reports to the trouble ticket
somehow (the cli is usually a nice to have in such cases).

16. Technical support immediately logs in and finds a big old log file he
which can be deleted.  He resolves the request, and writes three new
requests. One to himself; "Clean up the disk" (#159) and one to the local
hard disk provider (#78 at the HD providers site) asking them to send more
disks, and one to himself; "Install disk" (#160). #158 is marked dependent
on #161, #161 is dependent on HD #78,  and #158 is also dependent on #159.

17. 1st line support goes to #158 and writes a reply to all those 50
users.

50 user requests can be dependent on one trouble ticket that is taken care
of immediately.  This (resolved) trouble ticket can be dependent on two
worktasks (...well, probably it's easier to use trouble tickets here), and
one of the worktasks can even be dependent on an external request.

I hope those examples are understandable, and that you agree this is a
quite possible way to do things.  If you need more examples to be
convinced, just name it ... the same if you think other ideas (mainly to
separate dependency linking and different kinds of hierarchicallness)

Instead of "transitions", we just spawn new requests.  We have been doing
that for a long time locally with great success.

>     ticket  - an item that has an assigned ID number takes up space in queue
>               etc. It can have one or more derivedtickets, if it does then
>               it is the parent of the derived tickets. (alias ticket)

I think all kind of tickets should be a subclass of Ticket.  I think
you're doing it more complex than necessary when making differences like
this, and I also thinks it gets more static.  I think differing tickets by
the (content) class of the request makes more sense, I hope it will make
it easier to build site-specific extentions.

> Daniel>that things like orphaned requests didn't appear in the
> relationships.
> 
> What's an orphaned request? Derived, component and grouptickets are
> all first class tickets. In a rtq they should all show up. The
> derived, component, group etc are just a series of links that impose a
> different logic on the ticket. At worst case an "orphaned" request
> would just be a ticket.

I agree, all tickets should by default not be linked (other than to
which queue they appear in), thus beeing "orphans".

A queue is defined by which group of persons should handle it more than
content and class.  Our keyword system should do it easy to sort and
classify requests.

> Agreed. However something like this can be the output of rtq (sorted by num)
> for the diagram above:

I agree there must be a minimum of linking information at the queue
view, i.e. the total count of dependent requests and the count of
dependencies.  It would also be nice to get up a graph-view of linked
requests.

> I don't know about intuitive, but I think this is
> understandable.

I think both mine and your appraoch isn't too intuitive - particularly not
when more complex issues are dealt with.  I hope Meri might do some
miracles regarding that issue... :)  We have good experiences creating new
dependent requests to the production from the 1st line support, I've made
a "spawn" button beside the reply/comment buttons.  It quotes a
transaction just like reply/comment, but makes a request in a new queue. 
If the 1st line support don't think the user wants to be bothered more,
they resolve the dependent request ... eventually it gets stalled until
the production has resolved their request.  At the other hand, I don't
think anyone but me understands the usage of the rather cryptical form
"Mark this request as dependent at request #<input ...>" which might make
the request dependent on an existing ticket, like a bug report or an
existing "the disk is full" trouble ticket in the technical support queue. 

> I digess a bit. Buy some disk would be appropriate if the trouble
> ticket was "Can we stop running out of disk space every thursday" but
> not if the ticket was "I'm getting an out of disk space error".

In my model, it's completely OK to make a resolved request dependent on
another request.  What it really means is either "This request is stalled
until the dependencies are resolved" or "the new request is originating
from the old one".  Therefore it might make sense creating a new trouble
ticket "Can we stop running out of disk space every thursday" which the
resolved trouble ticket "Out of disk space error!" is dependent on. 

> If the message was the latter, then the "buy more disk space ticket"
> should become a separate request. This separate request may have
> derived tickets of "analyze disk space needs", "bid purchase of
> disks", "take systems down for disk install"....

Quite often there are limits for how much it is interessting to store in
RT.  I think RT should be more a tool for communication and request
tracking than documenting every piece of work a person has done and is
going to do during a day :)  "Spawning" requests make most sense when
it's done to a new queue.  I.e. if another person/department is in charge
of "buying disks" and/or "analyze disk needs" and/or "bid purchase of
disks" it makes sense "spawning" the request, if not it's better to
actually do the work. :)

> If the user is complaining about running out of disk space every
> thursday, then "clean out a bit of space" and "buy some disk" would be
> appropriate derived tasks. In fact the ticket may become a component
> ticket for an already outstanding ticket on "need to get more disk".

If "need to get more disk" is already there, "The mail server shouldn't go
down every thursday" should clearly be marked as dependent on "need to get
more disk".

> >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.
> 
> Actually, it is the first kind. Project management is primarily
> workflow/depenndency tracking and finding out which tasks have to be
> don in parallel or serial order and the longest path to get the task
> done.

Yeah, I guess you're right.  Actually I think everything can be done by a
proper usage of dependency links :)

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