Yep.<br><br><div class="gmail_quote">On Tue, Oct 11, 2011 at 1:47 PM, Ruslan Zakirov <span dir="ltr"><<a href="mailto:ruz@bestpractical.com">ruz@bestpractical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Oct 10, 2011 at 8:44 PM, Kenneth Crocker <<a href="mailto:kfcrocker@lbl.gov">kfcrocker@lbl.gov</a>> wrote:<br>
> Laura,<br>
><br>
> You can also add a new Status value like 'Dev compl' or something that<br>
> indicates that the ticket is ready to go back to Customer support. Then<br>
> write a scrip that change the Queue for the ticket back to Custom Support<br>
> when the status is changed to that value. Make it part of your workflow<br>
> design.<br>
<br>
</div>I don't mind at all moving tickets around. However, ticket is a sort<br>
of channel of communication with interested parties. Yes, when you<br>
move ticket to development you either can change requestor or tune<br>
notifications, so original requestors are not notified. This works<br>
when people use email, but stops working when people get access to the<br>
web interface - they see all replies and/or comments.<br>
<br>
Moving is good when you have conveyor like processing, for example<br>
order -> warehouse -> delivery. Things start in one queue and move<br>
towards final queue, rarely return back and all parties can talk to<br>
requestor but each figures out its own details. In development it's<br>
also possible, for example "bugs" that are created by supporters and<br>
q&a teams and managed by developers, then things move into q&a, then<br>
to changes_integration queue where they tied to tickets in 'releases'.<br>
<br>
Good indication for conveyor type is often change of owner of ticket<br>
not because of absence of the current owner, but because of workflow.<br>
<div><div></div><div class="h5"><br>
> Kenn<br>
> LBNL<br>
><br>
> On Mon, Oct 10, 2011 at 9:24 AM, Laura Grella <<a href="mailto:lgrella@acquiremedia.com">lgrella@acquiremedia.com</a>><br>
> wrote:<br>
>><br>
>> Thank you so much Ruslan! This really opened my eyes to how we can change<br>
>> our<br>
>> procedures for support/developer communications. I will definitely think<br>
>> through what you have suggested and see how we can put it into use.<br>
>><br>
>><br>
>><br>
>> Ruslan Zakirov-2 wrote:<br>
>> ><br>
>> > Hello Laura,<br>
>> ><br>
>> > On Mon, Oct 10, 2011 at 6:51 PM, Laura Grella <<a href="mailto:lgrella@acquiremedia.com">lgrella@acquiremedia.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Would this scenario be possible:<br>
>> >><br>
>> >> We have customer support queue open a ticket, and then the ticket gets<br>
>> >> sent<br>
>> >> to Software Development. We don't want software development to ever<br>
>> >> resolve<br>
>> >> a ticket if it was originated in the customer support queue. We want it<br>
>> >> to<br>
>> >> always end up in customer support so the support staff can first call<br>
>> >> customer to tell them the work was done.<br>
>> >><br>
>> >> Can I remove the resolved button/option if the ticket started in<br>
>> >> customer<br>
>> >> support and is not currently in customer support and replace it with a<br>
>> >> resolved by development button/option if it is owned by development<br>
>> >> which<br>
>> >> will cause it to go to the customer support queue where they will then<br>
>> >> have<br>
>> >> to real option to resolve the ticket?<br>
>> ><br>
>> ><br>
>> > In RT 4.0 every status change can be protected with a new right and<br>
>> > that right can be assigned to groups.<br>
>> ><br>
>> > However, in such setup I would recommend two alternatives ways for<br>
>> > support to comunicate with developers.<br>
>> ><br>
>> > 1) Developer comment required. In support queue supporters add<br>
>> > developers to AdminCc or Cc of a ticket when they need feedback from<br>
>> > developers. Setup rights, so developers can only comment on tickets in<br>
>> > support queue. For developers you setup saved search so they see<br>
>> > tickets in support queue where they are watchers. Also, you may create<br>
>> > additional custom field with values: "waiting for developer", "waiting<br>
>> > for requestor", ... . This way developers never interact with<br>
>> > customers, supporters bring in developers only when required and take<br>
>> > care of their awareness.<br>
>> ><br>
>> > 2) Bug fixing and development. When real development is required,<br>
>> > supporter creates a ticket in development queue and support request is<br>
>> > linked to development ticket. This allows you to link multiple support<br>
>> > requests to one development ticket, so you don't mix customers by<br>
>> > merging tickets and still tracks one development process through one<br>
>> > ticket. Developers can access all requests and via comments ask for<br>
>> > more info. Developers can communicate to each other via development<br>
>> > ticket. They can split development ticket into if problems are<br>
>> > different and as well split linked requests accordingly. As well, such<br>
>> > development ticket can be used to comunicate with Q&A team.<br>
>> ><br>
>> > For sure it needs more time to setup such thing, but it works much<br>
>> > better than moving tickets between support and development.<br>
>> ><br>
>> >> Hope this is clear. Thanks.<br>
>> >><br>
>> >> Laura<br>
>> ><br>
>> > --<br>
>> > Best regards, Ruslan.<br>
>> > --------<br>
>> > RT Training Sessions (<a href="http://bestpractical.com/services/training.html" target="_blank">http://bestpractical.com/services/training.html</a>)<br>
>> > *  San Francisco, CA, USA  October 18 & 19, 2011<br>
>> > *  Washington DC, USA  October 31 & November 1, 2011<br>
>> > *  Barcelona, Spain  November 28 & 29, 2011<br>
>> ><br>
>> ><br>
>><br>
>> --<br>
>> View this message in context:<br>
>> <a href="http://old.nabble.com/New-state---Developer-resolved-tp32625025p32625677.html" target="_blank">http://old.nabble.com/New-state---Developer-resolved-tp32625025p32625677.html</a><br>
>> Sent from the Request Tracker - User mailing list archive at Nabble.com.<br>
>><br>
>> --------<br>
>> RT Training Sessions (<a href="http://bestpractical.com/services/training.html" target="_blank">http://bestpractical.com/services/training.html</a>)<br>
>> *  San Francisco, CA, USA  October 18 & 19, 2011<br>
>> *  Washington DC, USA  October 31 & November 1, 2011<br>
>> *  Barcelona, Spain  November 28 & 29, 2011<br>
><br>
><br>
> --------<br>
> RT Training Sessions (<a href="http://bestpractical.com/services/training.html" target="_blank">http://bestpractical.com/services/training.html</a>)<br>
> *  San Francisco, CA, USA — October 18 & 19, 2011<br>
> *  Washington DC, USA — October 31 & November 1, 2011<br>
> *  Barcelona, Spain — November 28 & 29, 2011<br>
><br>
<br>
<br>
<br>
--<br>
</div></div>Best regards, Ruslan.<br>
</blockquote></div><br>