Process for handling nontechnical issues

[duckinator]

We need a way to nicely handle issues that are of the nontechnical variety. When @juliepagano reported www.gittip.com#1683, it became painfully apparent that we didn't do very well with this. And #49 showed that we didn't really improve a heck of a lot (if at all).

The obvious first step is making the support@gittip.com email address more prominent -- but is there anything beyond that we should do?

I'm opening this issue here for the purposes of discussion, and will create an issue on the www.gittip.com repository once we decide on a final approach.

[azurelunatic]

The way that LiveJournal, Dreamwidth, and everything else using the LJ support board engine handle it is: When filing the issue, the user selects a broad category for the support request. This category is linked to the issue's visibility. Most categories (including the default) are public and available for crowdsourced answering. Some categories, like terms of service violation issues and payment, are private (and are further restricted to specialists in that support category). Emails to support@ and a few other emails go to their own private categories so all the issues are handled through the same engine. Issues submitted to public support categories can be moved to private categories at the judgment of a support admin (and can be moved out, if it was moved in error or started in a private category but there's no need to keep it there).

I'm not recommending that you actually adopt that specific engine to handle your issues. It has usability issues out the wazoo, and would probably benefit from a rebuild from the ground up. One thing in particular that makes it not ideal for gittip's model of transparency is that at least as LJ & DW use it, issues that require an answer from a specific person/role tend to get shunted to private categories (to bring it to their attention/to keep from frustrating the crowdsourcers whose answers will never be approved) even if the content of the issue could be left public.

There are two types of response possible to a ticket: screened answer (intended to be sent to the user, with a pause for review by a support admin if crowdsourced/last check before sending if from an admin) or an internal comment (never sent to user, usually used for administrivia). There was at least one instance on LiveJournal of someone leaving breathtakingly xenophobic internal comments about a user; there are policies against this sort of abuse (in part because every now and then someone joins the support team and reads through old tickets they submitted and sees what's in the internal comments). LiveJournal's old support priv system (not sure what the current status is) granted viewscreened pretty early and viewinternal much later. Dreamwidth's grants viewscreened to any interested crowdsourcer, and I think Kat is pretty liberal with the viewinternal.

The people who handle routine support (non-technical issues & user education) at Dreamwidth are typically less involved in development. People involved in private support generally report back the sorts of issues that come up to leadership: not necessarily ticket by ticket police blotter style, but an overview. One issue with that is that unless there are tools in place to make that easy, it can fall by the wayside as stuff gets busy or people burn out.

Given @pjf's comment on #49, I wanted to lay out how Dreamwidth handles some of this stuff in the hopes it's helpful to you folks. A lot of it was developed through trial and error at LJ... :)

[duckinator]

@azurelunatic thanks for the information on how LiveJournal does it! Between that and my own brainstorming, I have a pretty good idea of how I want to approach it. Writing up a proper explanation of it now so I can get feedback from other people. :)