Improve RT

[fydai]

https://ocf.io/rt/6869 https://ocf.io/d/56

[cg505]

In the past we changed the status to "stalled" while waiting for a response from the requestor, and had a cronjob auto-resolve tickets that had been "stalled" for 5 days. We sent out an email to the requestor when tickets were (auto)resolved. When we stopped sending these resolved messages, we also stopped using stalled, since we could just resolve the ticket immediately.

@daradib is the backing code for this still available anywhere?

[daradib]

Unfortunately I don't remember, I think @nattofriends set it up?

[daradib]

I think this was it: https://technosorcery.net/blog/2007/09/soft-resolution-of-request-tracker-tickets/

[chriskuehl]

It was here: https://github.com/ocf/puppet/blob/fc6d4242ba773cefbc9e7c1ea542f8f7de3e8785/modules/ocf_rt/manifests/init.pp#L53-L56

I eventually deleted the cronjob (after everybody had already stopped using the stalled status) because at the time we were treating "stalled" the same as "resolved" -- it was just one more status that meant "no response needed from OCF staff", except that it would continue to clutter the ticket queue.

Here's an email I sent at the time about it:

Date: Mon, 26 Jan 2015 14:56:54 -0800
Subject: Thoughts on redefining RT statuses?
From: Chris Kuehl <ckuehl@ocf.berkeley.edu>
To: "wheel@ocf.berkeley.edu" <wheel@ocf.berkeley.edu>

For reference, currently we use statuses like so:

- new/open: ticket needs OCF response, OR waiting on group response
- stalled: ticket will auto-resolves in a few days; i never use this anymore
- resolved: no longer needs OCF response, but requester can reply at
any time to reopen it

I don't use stalled anymore because it's now effectively the same as
"resolved" since we don't send "Your ticket has been resolved" emails
anymore.

I suggest to redefine like so:

- new/open: ticket needs OCF response
- stalled: waiting on group response (but ticket should NOT be closed
[1]); no longer auto-resolves
- pending: new status, for when we want to reply to the ticket after
some engineering effort [2]
- resolved: same

Then, we actually use stalled for something, and the new/open queue is
only for things we can take immediate action on (and won't be
cluttered with things we're waiting on responses for, or waiting on
engineering effort for).

Thoughts?

Chris

[1] e.g. in cases where we're waiting on them to update WordPress
[2] for example, the tickets we kept alive forever until we finished
apphost, or for the one waiting on listservs

To be honest I don't fully understand the linked tickets -- a cronjob marking tickets as resolved after a period of time with no reply from the requestor still leaves the ticket in the queue unnecessarily. I think the ideal solution is to just mark tickets as "resolved" when replying (assuming that the reply closes the ticket from our perspective) so that we immediately remove them from the support queue [1].

FWIW I still think it is useful to have a status for "waiting on user, but we don't want to close it because we really do need a response" which is what I had proposed to use "stalled" for. You can imagine using this for things like DMCA notices.

[1] I know that marking tickets as resolved is tricky when using the email interface unless you want to prepend "Status: resolved" which looks bad to the user; there was a proposal to strip email commands from the message sent to users to work around this.

[daradib]

Agreed, tickets should resolve on reply, unless marked as stalled. The question is implementation: explicitly marking tickets resolved when replying (tedious), having a frequent cronjob resolve all tickets in state open (edit: but only if staffer last replied), or changing RT behavior from new -> open to new -> resolved (ideal). From my reply to the linked ticket:

[...] When we stopped sending these resolved messages, we also stopped using stalled, since we could just resolve the ticket immediately.

Kevin wrote:

Have a scrip that marks helpdesk tickets as resolved as soon as a staffer replies to them, unless the staffer marks a different status

I like this idea. Probably possible without an external script - have RT change tickets from new to resolved instead of new to open as it does by default. Mark tickets as "stalled" (or another status) in the rare case that they should not be auto-resolved, e.g., we replied to requestor but need to do more work on our end before resolving. (Yes, this is the opposite of the behavior in the past, but it means less messing with ticket statuses.)

Otherwise, if you want to send out RT resolved messages, auto-resolve open tickets later.

[emmatyping]

We've kinda gotten sloppy with how we mark RT tickets (we rarely mark resolved and don't mark stalled) we should probably get back into that habit (I hope to fix this with an RT runbook).

I think it would be easiest for this particular issue to add code to ircbot that periodically checks RT through the API and sends a message to rebuild with all of the tickets to be done.