[rt-users] Request for comments: Configurable Status

Thu Jun 24 16:00:45 EDT 2004

The trouble as I see it with this approach, which we discussed in house, is that
a ticket can get lost fairly easily as it traverses queues.  By "lost" I mean
that something entered into one queue by the original requestor will then
get processed through to its 'pending' queue, something's done on it,
then it eventually winds up in the 'resolved' queue.  But unless you look
for the ticket by "requestor" or by a specific memory for the ticket number,
the ticket has no easy way, by date perhaps, to be located out of a crowd
several days later.

In our workflow, tickets come in from customers, potential customers, or from
other vendors or people we buy stuff from, and the ticket goes into the queue
that it fits for what type of work it is -- systems work, dev work, network work
or IT.  since a large number of our tickets can require interfacing to vendors
we created a separate queue 'vendors' for tickets that were pending waiting for
vendor callback.  But this started to be bad, cause Joe creates a ticket on
monday in Systems, and on Tuesday it gets stalled into Vendors, now its thursday
and Joe can't find his original Systems ticket.

If you see what we mean here....

Thanks, sorry for long winded...

+-------------------------
+ Dave Dennis
+ Seattle, WA
+ dmd at speakeasy.org
+ http://www.dmdennis.com
+-------------------------

On Thu, 24 Jun 2004, Kelly D. Lucas wrote:

> I was planning to use [queues] in the following way:
>
> One potential path:
> [Sales] <====> [Support]  <===> [Dev]
>
> A second:
> [Sales] <===> [ProdMgt] <===> [Dev]
>
> Basically, anything could possibly be "fixed" within any [queue] above,
> or could be passed on to a different queue for assistance or escalation.
> However, it would flow back to the originator for final closure. So
> although the owner would change hands, it would go back to the
> originator for the final approval of any ticket closure.
>
> So, as long as someone was able to track the <ticket-id>, I would think
> they would have the ability to see all of the history of any issue that
> came in or out of the queue.... Is this the way the system works or am I
> missing some critical piece of info?
>
> K.D. Lucas
> lucaskeli at fastmail.fm
>
>
>
> Brett Barnhart wrote:
>
> >Personally, I don't move tickets around queues unless it was placed
> >wrongly...
> >
> >For a given project, I have a project queue, a programming queue, and a
> >testing queue.
> >
> >I may not want the original requestor to see all the notes back and forth
> >about programming and testing. So, I use the dependencies a lot.
> >
> >A given project will have one project ticket.
> >Each project will have one or more programming ticket.
> >Each programming ticket will have a testing ticket.
> >
> >Part of the reason for this is accountability. I am the project manager, so
> >I own the project.
> >However, the programmer is the owner of the programming ticket and I am the
> >requestor.
> >The testor is the owner of the testing ticket and the programmer is the
> >requestor.
> >
> >If you move the ticket around... you loose that paper trail. Programmer 1
> >moved the ticket to queue 2... was their part done or did they give up or
> >something else happen?
> >
> >I would agree that it would be nice to have "Resolved" have permissions. We
> >do not allow our programmers to resolve a ticket. The Project manager needs
> >to do that. We are small enough that we just made the rule and ask people to
> >follow it, but it isn't enforcable.
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Les Mikesell [mailto:les at futuresource.com]
> >>Sent: Thursday, June 24, 2004 12:22 PM
> >>To: Kelly D. Lucas
> >>Cc: rt-users at lists.bestpractical.com
> >>Subject: Re: [rt-users] Request for comments: Configurable Status
> >>
> >>
> >>On Thu, 2004-06-24 at 08:31, Kelly D. Lucas wrote:
> >>
> >>
> >>
> >>>    * demo/installation [Sales Engineers]
> >>>    * system configuration [tech support]
> >>>    * enhancements or tech data [prod mgt]
> >>>    * bugs [dev/SQL]
> >>>
> >>>
> >>It seems natural to me to arrange queues according to the
> >>people that do the work and get notifications and move
> >>tickets to the appropriate queue for different stages
> >>of work.
> >>
> >>
> >>
> >>>3) So obviously there will be states like fixed, verified,
> >>>
> >>>
> >>that there
> >>
> >>
> >>>won't be for the demo/installation issues.
> >>>
> >>>
> >>Can't you move the ticket out of the queue for the people who fix
> >>or verify once it no longer needs their services?  In the appropriate
> >>queue it is either done or not.
> >>
> >>
> >>
> >>> And in product marketing,
> >>>they will have states regarding feature enhancements that
> >>>
> >>>
> >>other groups
> >>
> >>
> >>>will not have.
> >>>
> >>>
> >>What should happen if you move a ticket into a queue that doesn't
> >>include it's current status as one of the choices?  Marketing people
> >>generally aren't going to 'solve' a problem of feature enhancements.
> >>You need to push such a ticket to a queue watched by developers and
> >>let them send it back when the marketing people have something to
> >>sell.
> >>
> >>One thing I've sometimes wanted and haven't figured out an easy
> >>way to accomplish is to include the current owner or perhaps
> >>all the watchers of the current queue as a cc for notifications
> >>even though the ticket is being moved to a queue that doesn't
> >>normally include them and it may subsequently have its ownership
> >>changed too.  For a single user you could add the email as a
> >>cc but it would be nice to be able to use the same group references
> >>you create for permissions as watchers and add-on cc:'s tied
> >>to individual tickets.  Maybe what I'm really asking for in addition
> >>to letting groups be watchers is to to allow a ticket to appear
> >>in multiple queues so instead of moving it out of it's original
> >>queue for special services you could add it into the queue watched
> >>by others in some workflow step without losing track of it yourself.
> >>
> >>In case I've missed something, is there currently any way to find
> >>a ticket you've pushed to another queue if you no longer own it or
> >>if you weren't the original owner?  Say something comes in to a
> >>support queue that needs development work to fix and is pushed to
> >>an appropriate queue.  Is there any way for a different support
> >>person to know if those tickets have had any subsequent activity or if
> >>they are being ignored?  Something like 'search for tickets that were
> >>moved out of the support queue but not yet resolved'?  I'd like them
> >>to be generally out of the way while someone else has them but not
> >>completely forgotten.
> >>
> >>---
> >>  Les Mikesell
> >>    les at futuresource.com
> >>
> >>
> >>_______________________________________________
> >>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> >>
> >>RT Developer and Administrator training is coming to LA, DC
> >>and Frankfurt this spring and summer.
> >>http://bestpractical.com/services/training.html
> >>
> >>Sign up early, as class space is limited.
> >>
> >>
> >>
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
> http://bestpractical.com/services/training.html
>
> Sign up early, as class space is limited.
>