[rt-devel] RE: [rt-users] Some features I'd like to see
Rouillard, John
RouillardJ at brevard.cc.fl.us
Sat Mar 18 17:08:51 EST 2000
Jesse>From: Jesse [mailto:jesse at pallas.eruditorum.org]
Jesse>On Sat, Mar 18, 2000 at 11:07:01AM -0500, Daniel Rinehart wrote:
...
Daniel>1) Grouping: This supersedes the "merge" functionality. Two or more
Daniel>requests on the same subject can be associated with each other and
then
Daniel>actions can be done on the complete set, a subset, or the individual
Daniel>request. This would also allow easy "unmerging" or "splitting"
requests,
Daniel>should you change your mind.
I like the grouping functionality. It allows a meta ticket to be
created while still maintaining the individuality of the sub
tickets. Merging loses the individuality of the subtickets. But it
does make it impossible for a subticket to be open while the parent
ticket is closed (since there is no subticket after the merge).
Daniel>2) Parent-Child: Single Parent multiple Child. This allows the
Daniel>ability to create dependencies or subtasks. It would also allow
Daniel>the ability to divide up a multiple request, request into sub
Daniel>requests which could then be assigned to different people (most
Daniel>likely by creating new requests and associating them)
In the modified req, if the request had portions of work that could be
done in parallel, or that were handled by different people, the ticket
was split (sort of the opposite of merge) into multiple
parts. E.G. the ticket says: "bring system foo on line". A sub ticket
would be "Put network card in foo an test" which would be assigned to
our pc hardware guy. A second ticket would be "install standard
software on foo" assigned to one of the low level support people. The
parent ticket would be assigned to the network admin to actually
install the pc on the net and hook up the wires.
This falls into the parent child model nicely.
Daniel>3) Interrelationships: This is where things get icky, but if
Daniel>done, would add a lot of flexibility or power to the
Daniel>system. Allow groups to be either the parent or child in a
Daniel>relationship. A example: 5 different people send is requests
Daniel>that the mail spool is full. Use grouping to associate them to
Daniel>together. The create 2 child requests one of which is assigned
Daniel>to an admin to find a quick solution while the other is
Daniel>assigned to purchasing to order more disk space.
...
Jesse>Eventually I see several distinct ticket types:
Jesse> * User Request
Jesse> * Trouble Ticket
Jesse> * Bug
Jesse> * Task
(see below for definitions, but is a Task equivalent to a derived
ticket, and maybe a user requiest equivalent to a ticket?)
Jesse>These aren't firm distinctions. In earlier iterations of
Jesse>this, I really only had Requests, Tasks and Bugs..
Jesse>But I thiink these four make sense.
Jesse> The users would send in Requests describing the problem
Jesse>that they were experiencing.
In the current system a request is the same as a trouble ticket. Send
a request get a ticket # back.
Jesse>An administrator would open a Trouble Ticket and associate
Jesse>all the user requests with it.
Sounds like a "trouble ticket" is a groupticket. Bug has me totally
stumped however.
May I suggest the following terminology (Jesse, your teminology is
just a bit confusing to me as to what plays what role.):
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)
groupticket - a ticket that has a number of other tickets called
components that relate to it. (same idea as a merge ticket
but all of the tickets retain their individuality). It can
have
one or more derivedtickets, if it does then it is the parent
of
the derived tickets. (alias group)
componentticket - a ticket that has one and only one group ticket
associated with it. When the groupticket is closed, this
ticket is also closed. It does not have derived
tickets. A component ticket can't have derived
tickets. (alias component)
derivedticket - a ticket that has one and only one (parent) ticket
associated with it. In order for the parent ticket to be
closed, the derived ticket must be closed. (alias derived).
The following transitions can occur:
ticket -> group by adding a component to the ticket.
ticket -> component by being named as a component to a ticket
(compare to being merged)
component -> group by adding a component to the ticket
ticket -> derived by having an assigned parent ticket.
At first glance I don't think its that icky if you keep component and
derived tickets separate. There is only one common ancestor for the
shrub that is created namely the group ticket.
+ componentA
group/component1 component2 component3 componentn
| | | |
+---------------+-----+---+----------+
|
groupticket
|
+--------------+-----+------------+---------------+
| | | |
derived1 derived2 derived3 derived4
+ derivedA
Daniel> Logic would be needed to make sure that loops weren't created and
If the components and derived's were kept separate, I think the logic
would be "a ticket that is a component of another ticket can't have a
derived ticket". The derived ticket would have to become a derived
ticket of "groupticket". By creating a groupticket we are claiming
that the solution of the groupticket also solves all component
tickets. We also claim (by creating derived tickets) that all derived
tickets must be finished before the group ticket (and therefore the
component tickets) can be resolved.
Also derived tickets can have more derived tickets and component
tickets can have more component tickets, but component tickets
shouldn't have derived tickets, nor should derived tickets have
component tickets. Since you can't solve a ticket that has derived
elements without solving all derived elements, you can't get derived
tickets that are open while their parents are closed.
If the above two rules aren't followed, then you can get loops in the
tree structure above and have open tickets whose parent's are closed.
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.
Daniel>Finding intuitive ways to show this to users gets interesting.
Agreed. However something like this can be the output of rtq (sorted by num)
for
the diagram above:
Heirarchy Num ! Owner Age Told State Requestor Subject
------------------------------------------------------------------
<< 81 50 rouilj 5 day 5 day open Rouillard componentA
< 82 50 rouilj 5 day 5 day open Rouillard group/component1
< 83 50 rouilj 5 day 5 day open Rouillard component2
< 84 50 rouilj 5 day 5 day open Rouillard component3
< 107 50 rouilj 5 day 5 day open Rouillard component4
86 50 rouilj 5 day 5 day open Rouillard groupticket
> 87 50 rouilj 5 day 5 day open Rouillard derived1
>> 106 50 rouilj 5 day 5 day resol Rouillard derivedA
> 89 50 rouilj 5 day 5 day open Rouillard derived2
> 91 50 rouilj 5 day 5 day resol Rouillard derived4
> 129 50 rouilj 5 day 5 day open Rouillard derived3
I don't know about intuitive, but I think this is
understandable. Please note that I can draw diagrams of arbitrary
complexity, but I really don't think that most uses of this system
need to get that far. In my experience, I maybe had to merge maybe 5%
of the tickets, we usually got to major things before too many people
complained. The subrequest stuff was used more often because of the
specialization of tasks, but still I would say less than 15% of the
time. Most of the traffic through the system was good old plain
tickets with no other encumbrences. I expect that your milage may
vary.
Jesse also said:
>An administrator would open a Trouble Ticket and associate all the
>user requests with it. Then, she would create two children of the
>trouble ticket "Clean out a bit of >space" and "Buy some disk"
BEGIN DIGRESS
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".
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"....
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".
END DIGRESS
Tobias Brox said:
>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.
...
>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.
Jesse>But anyway, I don't think you've gone off the deepend. or, if
Jesse>you have, so have I.
Daniel> Maybe I'm just rambling, maybe I've gone off the deep end, but I
Daniel>thought I'd throw it out.
Waiting in the water (hey at least it keeps the flames at bay 8-)).
-- rouilj
More information about the Rt-devel
mailing list