[rt-users] Request for comments: Configurable Status

Thu Jun 24 16:53:10 EDT 2004

"Kelly D. Lucas" wrote:

> Is this the way the system works or am I
> missing some critical piece of info?

Suggestion:

Use queues to categorize tickets (e.g. Incident, Request for change, etc)
use ownership (and group membership) for responsibilities and watchers
for access control for other interested parties.
Do not use queues for responsibilities.

Does that help?

Jan

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

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org