Mailing List Archive

[Wozz]
> #1) Keystone has a nice feature that allows you to automatically mail
> different FAQ responses out to a customer. I find myself typing the same
> responses over and over, and it'd be a real time saver to have some sort of
> faq database to send via a button.

We already have this feature in our 1.0 version which we run locally at
this office. I will of course priority this, as we can't merge to the
next version of RT before this behavoir works.

[Charlie]
> I remember someone posting patches to add signtaures.

Yep, we have that, too :)

[Wozz]
> What I typically do with these complaints is merge them into one
> ticket. I'd love to be able to send out one reply when the
> situation is resolved and not have all the complaintants email
> addresses be in the To: line. People get sensitive about that.

[Charlie]
> Quite rightly too.

I guess Jesse has already mentionated the hierarchy idea he has, but I
don't think we've thought much about how to deal with the to-line. There
are two possibilities as I see it, sending one mail for each requestor, or
sending a mail with a fake to-line and all addresses at the bcc-line.
What do you preffer?

[Charlie]
> I patched our local server to send mail using the smtpsend method of
> Net::Mail (not sure of those details, but you'll get the picture).

Mail::Internet, I'd daresay - and those patches are used by me, now.

> The
> recipient list then didn't appear in either the To: headers. I seem to
> remember that some others didnt like the idea of using SMTP mail (concerns
> about availability).

Right on. Actually I do have problems with this. I daily get RT errors
because it can't send mail ... it either times out or gets rejected by the
mail server for different reasons (i.e. my load suddently rose to 12 as an
nfs server fell out - and sendmail denied receiving email. Well, I will
eventually move RT to a server without nfs-mounted file systems, but
anyway..). Increasing the timeout setting is not an option ... the web
user will often have to wait for the timeout. It's better to get a
bounce, I think.

--
Tobias Brox (alias TobiX) - +4722925871 - _urgent_ emails to
sms@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)

> > Cool. One thing I implemented in req was the ability to split tickets.
> > Sounds like hiearchical tickets will provide this functionality.
> I think there is quite some different kinds of hierarchies out there. I
> the first kind ... it's dependency. As we use it here it's more about
> workflow than anything else. Example:

I think that last point is the most important. Different places
that use RT are going to have very different work flows in how tickets are
assigned, dealt with, merged, etc. Given the more modular design of RT2 I
think the following might be something to consider.

Using grouping and parent-child relationships, combined with
logic, a default set of work flows can be created, but also allow
customization based on a particular site's needs.

1) Grouping: This supersedes the "merge" functionality. Two or more
requests on the same subject can be associated with each other and then
actions can be done on the complete set, a subset, or the individual
request. This would also allow easy "unmerging" or "splitting" requests,
should you change your mind.

2) Parent-Child: Single Parent multiple Child. This allows the
ability to create dependencies or subtasks. It would also allow the ability
to divide up a multiple request, request into sub requests which could
then be assigned to different people (most likely by creating new requests
and associating them)

3) Interrelationships: This is where things get icky, but if done, would
add a lot of flexibility or power to the system. Allow groups to be either
the parent or child in a relationship. A example: 5 different people send
is requests that the mail spool is full. Use grouping to associate them to
together. The create 2 child requests one of which is assigned to an admin
to find a quick solution while the other is assigned to purchasing to
order more disk space.

Logic would be needed to make sure that loops weren't created and
that things like orphaned requests didn't appear in the relationships.
Finding intuitive ways to show this to users gets interesting.

Maybe I'm just rambling, maybe I've gone off the deep end, but I
thought I'd throw it out.

-- Daniel R. <danielr@ccs.neu.edu> [http://www.ccs.neu.edu/home/danielr/]

On Sat, Mar 18, 2000 at 11:07:01AM -0500, Daniel Rinehart wrote:
>
> I think that last point is the most important. Different places
> that use RT are going to have very different work flows in how tickets are
> assigned, dealt with, merged, etc. Given the more modular design of RT2 I
> think the following might be something to consider.
>
> Using grouping and parent-child relationships, combined with
> logic, a default set of work flows can be created, but also allow
> customization based on a particular site's needs.
>
> 1) Grouping: This supersedes the "merge" functionality. Two or more
> requests on the same subject can be associated with each other and then
> actions can be done on the complete set, a subset, or the individual
> request. This would also allow easy "unmerging" or "splitting" requests,
> should you change your mind.
>
> 2) Parent-Child: Single Parent multiple Child. This allows the
> ability to create dependencies or subtasks. It would also allow the ability
> to divide up a multiple request, request into sub requests which could
> then be assigned to different people (most likely by creating new requests
> and associating them)
>
> 3) Interrelationships: This is where things get icky, but if done, would
> add a lot of flexibility or power to the system. Allow groups to be either
> the parent or child in a relationship. A example: 5 different people send
> is requests that the mail spool is full. Use grouping to associate them to
> together. The create 2 child requests one of which is assigned to an admin
> to find a quick solution while the other is assigned to purchasing to
> order more disk space.
>
> Logic would be needed to make sure that loops weren't created and
> that things like orphaned requests didn't appear in the relationships.
> Finding intuitive ways to show this to users gets interesting.
>


This actually sounds a lot like what I was already planning :)
Eventually I see several distinct ticket types:
* User Request
* Trouble Ticket
* Bug
* Task

These aren't firm distinctions. In earlier iterations of this, I really only had Requests, Tasks and Bugs..
But I thiink these four make sense. In this system,
The users would send in Requests describing the problem that they were experiencing.
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"

But anyway, I don't think you've gone off the deepend. or, if you have, so have I.

jesse

> Maybe I'm just rambling, maybe I've gone off the deep end, but I
> thought I'd throw it out.
>
> -- Daniel R. <danielr@ccs.neu.edu> [http://www.ccs.neu.edu/home/danielr/]
>
>
>
> _______________________________________________
> Rt-devel mailing list
> Rt-devel@lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel
>

--
jesse reed vincent -- jrvincent@wesleyan.edu -- jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
--------------------------------------------------------------
...realized that the entire structure of the net could be changed to be made
more efficient, elegant, and spontaneously make more money for everyone
involved. It's a marvelously simple diagram, but this form doesn't have a way
for me to draw it. It'll wait. -Adam Hirsch

...
then
requests,

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


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.

...

(see below for definitions, but is a Task equivalent to a derived
ticket, and maybe a user requiest equivalent to a ticket?)


In the current system a request is the same as a trouble ticket. Send
a request get a ticket # back.


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


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.

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.



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

> I like the grouping functionality. It allows a meta ticket to be
> created while still maintaining the individuality of the sub
> tickets.

Yep. It's important.

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

It seems to me that the difference between our dependencies and such a
worktask hierarchy isn't that big anyway. Well, in a 'pure' worktask
hierarchy, you want the upper task to automaticly be resolved when all
subtasks are resolved. The behaviour with our dependencies are that the
dependent ticket (if it was stalled) gets opened each time a subrequest
gets resolved (because that means the owner of the dependent task have
to do something). Other times it makes sense that the dependent
ticket gets opened only when all all subrequests are resolved.

..again, I think the best is to have a general 'Link' action, and let all
kind of different hierarchies be taken care of either by options or
subclassing.

Ack, I'll come back to the rest of your mail. It's too much for the
moment. :)

--
Tobias Brox (alias TobiX) - +4722925871 - _urgent_ emails to
sms@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)

> Jesse>Eventually I see several distinct ticket types:
> Jesse> * User Request
> Jesse> * Trouble Ticket
> Jesse> * Bug
> Jesse> * Task
>
I'm about to go to bed..and will be on the road tomorrow, so I'm not going to actually respond
fully for now but here,s the basic breakdown:

A User Request is a user request for some sort of action. It may be a
request for help, a problem description,e tc.

A Trouble ticket is a ticket describing some open, unresolved issue
(A NOC, for example, would mainly deal in Trouble tickets)

A bug is somewhat related to a trouble ticket....but is more likely to
be targetted at a software development team. I'm really not sure how this interacts
with the rest of the system yet.

A Task is some divisible action that needs to be taken.

The rough model is that a user would create a Request. The NOC would open a trouble ticket
to tie together all user requests and track the issue. The NOC might escalate the trouble ticket
to a Senior Administrator who would create Tasks that need to be done to correct the issue
and assign those tasks to junior administrators.


Of course there's nothing stopping you from just using good old user requests
to track and resolve issues.

--
jesse reed vincent -- jrvincent@wesleyan.edu -- jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
--------------------------------------------------------------
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.

> >An administrator would open a Trouble Ticket and associate all 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".

Okay, so maybe that wasn't the best example. The general idea is
that a single user request ends up creating 2 sub tasks that are assigned
to other people.

-- Daniel R. <danielr@ccs.neu.edu> [http://www.ccs.neu.edu/home/danielr/]