I designed a workflow for server installation while at the Stanford Linear Accelerator (SLAC), which I contributed to the RT Wiki: http://wiki.bestpractical.com/view/WorkFlow. It consists of a master ticket for the tasks, child tickets assigned automatically to the responsible groups for subtasks, and updating of the parent ticket as the subtasks are completed. A saved search gave a dashboard of all outstanding tasks and where they stood in the process. Is that the sort of thing you are looking for? -Chuck -- Chuck Boeheim [::] CIT [::] Systems Services Cheap hardware isn't
On Mar 23, 2010, at 7:10 PM, Forrest Aldrich wrote: One problem I frequently run into while using RT is the issue of "workflow". There are "priority" levels, but when you have a task that has multiple people involved, it would be useful to have multiple ticket owners where when one task is completed, it's automatically punted to the next person to complete (the key being visibility). Yes, you can just re-assign the ticket - but sometimes that's not politically pleasant (office politics). A generic example: I'm asked to upgrade a server software component (product) that is used internally for which I have no other involvement; dev people are responsible for testing and Q/A of the install. I get a ticket to perform the update, I report this update as being completed, but never receive a response or approval that they found the work acceptable. So, I just close the ticket. This creates several problems, some of which are connected to the absence of a workflow process. Anyway, I wonder how others in differently-sized organizations handle this type of issue within the RT framework. We are now testing a 'kanban' system internally, to see if that will help with some of these processes. Thanks... Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
