[rt-users] Seeking queue setup wisdom

[Florian Lengyel]

I've implemented queues based on where the work originates, and which group
it involves.

General (research computing administrative business)

Operations (network and server operations) for tickets originating within
the research computing system administration group

ICPSR - for duties related to the inter-university consortium for political
and social research, such as the Summer Program for Quantitative Methods in
Social Research.

Helpdesk - for tickets related to applications running on LAMP servers, or
for troubles with rsearch computing applications software; these come from
outside the  systems group. Also, trouble reports for the research computing
network that have to be referred to another group go here.

ComputerScience - for work relating to computer science doctoral program (I
may get a request to referee a paper, give a talk, etc).

I've found categorization by general areas of responsibility and the
affected group to be useful. This cuts down on the number of queues (I don't
have queues by product line, for example, though I might if RT implemented
queue collections, as opposed to individual queues) and it simplifies
configuration of the different views of the system that the various
interested parties have.


On 2/15/06, Lee Roth <bwc_lr1 at easy48.com> wrote:
>
> I've been running/using RT (V3.2.3, just upgraded to V3.4.5) for some
> months now for a small group of network/sysadmin folks and I'm not 100%
> satisfied with the RT operation that I currently have.
>
> *Background: *My initial setup of queues was based on type of gear, e.g.
> Routers, firewalls, servers, etc. All of these queues have a default
> priority range of 0 to 29 and escalation period of 7 days from min to max. I
> also have a queue for 'projects' that are long-term, back-burner kinds of
> things, so the escalation period is very long (6 months). I have a daily
> script that does the auto-escalate of priorities.
>
> The problem is that the 'one-priority-scheme-fits-mostly-all' approach
> isn't working too well... calls that are 'hot' don't escalate as fast as
> they should from their initial logging (via email interface), while others
> get worked for a while and then need to migrate to a 'back-burner' lower
> priority and escalate much more slowly than default.
>
> I like the ability to do end-of-month type reports and use the queue name
> to simply categorize the type of calls that have been worked, so I'm
> reluctant to create a plethora of queues with name based on priority +
> equipment category. Ick.
>
> I've been toying with creating a custom field that mimics my current queue
> names and then have the queues be strictly named according to priority
> (urgent, important, routine, low), but then I lose my nice end-of-month ease
> of reporting what kind of gear that was worked on. (Read: Yes, I can craft
> reports on that custom field but I guess I am trying to avoid that.)
>
> *Big Question:* For those of you that are successfully using RT to track
> technical requests and tasks, are your queues equipment/activity centric or
> priority-centric? Can you describe your RT implementation and how/why it
> works well for you?
>
> Thanks!
>
>  *Lee Roth
> *Email:  bwc_lr1 at easy48.com
>
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Be sure to check out the RT Wiki at http://wiki.bestpractical.com
>
> Download a free sample chapter of RT Essentials from O'Reilly Media at
> http://rtbook.bestpractical.com
>
> WE'RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
> San Francisco - Find out more at
> http://bestpractical.com/services/training.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20060216/7a2e82df/attachment.htm>