wiki:KiT×2013

A HemiKibiTicket by 2013

At the November 3, 2012 support-team meeting, Ross set us an ambitious cleanup goal for this ticketing system. Reduce the number of open (new, assigned) tickets to below 1024 (one KibiTicket) by the beginning of the upcoming calendar year. That goal was met by November 10th. That kind of success means we had to move the goalposts, and aimed for 512 open tickets instead! That goal was met on November 16th.

Our shorthand for "A HemiKibiTicket by 2013" is KiT×2013.

Status and Timeline

We started with about 1850 tickets in a new/assigned state on November 3rd. By November 11th we were at 971. We hit a HemiKibiTicket on November 16th! Now we just have to maintain this level or better through the end of the year.

/chrome/site/ticketgraph.svg (graph details)

Likely Candidates for Triage

If you want to help, here are some tickets that are likely candidates for cleanup:

Some examples of tickets that can probably be closed with a brief message are:

  • old tickets that describe urgent/acute issues which have been resolved.
  • old tickets which concern a defunct membership.

Some examples of tickets that can be placed in the "feedback" state are:

  • a ticket where a suggestion was made by that might resolve the issue, but the reporter has not responded or provided evidence that they've tried the suggestion.
  • a recent ticket that reports a problem which does not appear to be replicable.

Another helpful way to find tickets that can be closed is consolidation:

  • find a bunch of tickets that are all in reference to the same underlying issue. choose a particularly-representative one, (or write up a new ticket with a nice clear summary), and close all the rest with a reference to the representative ticket.

Use your judgment, and feel free to raise concerns on the support-team list.

Best Practices

Read the Ticket and All Comments

We're not doing automated/batch closes of tickets. Reading the full history of the report, thinking about it, and putting yourself in the shoes of the reporter go a long way toward doing triage respectfully instead of dismissively.

Look up the Member and the Relevant Service

Some tickets are about problems for a specific member, with a specific service. If you have admin access to the control panel, a quick search in the MF/PL control panel for the member's ID (the part after the https://id.mayfirst.org/) or for the domain name in question can shed some light on the status of the account, the e-mail address, the web site, or whatever. You can find their primary host server there, too.

Depending on what the problem report is, you might try connecting to the primary host server via ssh, looking up the domain name via whois, investigating their DNS with dig or host, or snooping around more in the control panel. If these lookups are fruitful, you might including a concise summary of what you found in your comment. If they're not fruitful, you might also mention what you tried so that someone looking at the ticket after you can benefit from your work.

Acknowledge and Apologize for Abandoned Tickets

It's sad, but some tickets never got a proper response at all. We should be forthright about these failures, and apologize for having left them for so long. A good rule of thumb is to think of the message you write as you triage the ticket as a brief e-mail to the person who reported it. If you got an e-mail about a problem reported 4 years ago, you'd want to see at least a brief acknowledgment that the time lag is absurd. And an apology doesn't hurt here.

Point to Canonical Documentation

If the ticket was a question or a common technical difficulty, like how to configure a specific popular mail user agent, include a link to the relevant faq entry or other page here at SMO in your comment, so that future searchers will get pointed to the right spot.

Cleanup Keywords

As you're triaging a ticket, go ahead and scan the keywords field. Try to normalize the keywords into a space-separated list of the relevant terms. Take a quick search for other similar tickets to see what their keywords look like if you're not sure what's plausible. This isn't terribly important, and your time will be better spent closing other tickets. Once you've closed a dozen or two, you'll have a pretty decent sense of what sort of keywords are reasonable.

Tag Uncertain Outcomes with needs-review

For some tickets, you may find that a resolution was likely found. However, you cannot quite tell. In these cases, simply add the keyword/tag needs-review. This way we'll have a collection of easily identifiable tickets for reviewing later.

Choose a Resolution

If you're closing a ticket or putting it in feedback state, you should pick a reasonable resolution. Where it seems plausible that the ticket has been resolved, either by a question being answered, or by some technical fixes, "fixed" is a good one. If you can't convince yourself that the ticket has been successfully resolved, but you can't find any existing problems to solve either, "worksforme" might be the right choice.

Last modified 6 years ago Last modified on Dec 1, 2012, 5:19:08 PM