As part of our series giving an insight into what goes on behind the scenes at the Archive of Our Own, Support staffer Sam has written up a day in the life of an AO3 Support staffer! Sam started out volunteering with the AO3 as a tag wrangler, and joined the Support team at the beginning of the July Ticket Blitz. He has degrees in journalism, English literature, and cognitive and discourse linguistics. He’s taught skills-based computer classes for near a decade, so Support was a natural fit. Sam tends to jump on tickets involving CSS code and the skins; downloads, especially ePUBs; and all things Tag, as he’s currently the liaison (read: troublemaker) between Support and Tag Wrangling.
By and large, Support is all about answering all the tickets that come in. To do this involves a whole lot of trying to break the Archive in new and creative ways, keeping a light eye on what the Coders are up to under the hood, and generally trying to divine what the users need and want.
There are a whole bunch of resources we use to do so (some of these resources are only accessible to staffers – we’ve linked the public ones):
- 16bugs – This is our main ticket tracker where we keep information on each ticket that comes in, and any communication with the user or other committees. This will soon (hopefully) be replaced with the Support Board.
- Campfire – The chat interface all AO3 committees use. Support has its own room where we’ll request betas and comment on tickets, life, and fic; and we’re often lurking in the Coders room, checking for surprise!bugs and fixes.
- Both the “Beta” Archive (the real one) and the Test Archive (where we test new code) – Sometimes we have to track down to see what a reported bug is doing and possibly see if it’s already been fixed on the next release.
- The wiki “Knowledge Base” – One of our Support reps has been collating the answers to commonly answered questions into a massive internal reference source. This is awesome, because it helps ensure that knowledge gets passed on and we don’t have to duplicate work.
- Google code otwarchive issues – The list of things-to-do for the Coders, to see if a bug is known or a feature planned (and occasionally provide all the information).
- Squee! – This internal squee page is where we keep all records that we’re doing something right (700+ and counting). It helps us track what’s working and also provides a nice place for people to go when they need a boost!
I pop open my email to see if anyone sent beta requests to the list or if any tickets have come in. (Most responses to users are beta-read by a second support member, for accuracy, clarity, and something resembling UK/US/CA/AU English.) I’ll also log into Campfire and check the Support room, since several staff will leave their beta requests in there.
Both 16bugs and the Support form send an email to each Support staff when a ticket comes in. I tend to not read the emails themselves, but use them as a sign to go check 16bugs and see what new tickets are there.
Certain tickets we immediately assign to another committee (Legal, Abuse, Tag Wranglers) and wait for a response from that committee before contacting the user. Some committees will contact the user directly, some don’t.
Since every ticket is different, I’m going to give examples of two recent tickets. (All confidential details are removed, but hi, users, if you recognize your questions!)
A ticket comes in from a user asking about a problem logging in with hir OpenID. I open the ticket in 16Bugs, and in the ticket set my name for “Assigned to” and “Status” to “Solving”.
I’ve heard some talk about the discontinuance of OpenID, so I poke my head into the Coders chatroom in Campfire and ask if anyone has more specific information. I luck out and one of our Coders knows of two open code tickets regarding OpenID, which saves me the time. I open the tickets in GCode and skim them, seeing the current development status for OpenID (we’re planning to phase it out).
To make sure the code is still working as intended, I use my own account as a guinea pig, setting up my own OpenID login, logging out and testing it. It all works, so I assume that the problem comes from improper configuration. I step back through the process involved and make detailed notes to set up OpenID. I add those to our Knowledge Base on the wiki so next time we have a question like this, the info is easy to find.
I then compose a reply to the user as a comment to the ticket in 16bugs. I also copy in the links to the GCode tickets into 16bugs for reference. After coming up with the response, I poke my head into Support chat in Campfire. Fortunately, one of the other Support staffers is on, so I ask hir to beta my response. Sie reads it over, we discuss and revise a few lines, and sie comments in the thread that it looks good. I copy the response from 16bugs.
In my email, already set to forward through the official email, I search and find the ticket email that came in and reply to it, using the copied text from 16bugs.
After sending the email, in 16bugs I set the status to “Solved”. If the user responds, I can find the ticket in 16Bugs and reopen it as needed. When the user responds that sie doesn’t actually have an account, I send back a betaed response on how to get an invite, either through the queue or through a friend.
Another ticket has come in regarding a tag that’s misfiled – in this case, a fictional football team that has somehow been wrangled into the “Football RPF” fandom. Since this relates to wrangling policy, I’ll mark the ticket to watch it and assign it to the “Tag Wranglers” and wait for a response from one of the Wrangling committee members before I send a response to the user. In this case, it’s an easy fix by the wranglers, and I’m able to quickly notify the user that the tag has been re-wrangled.
There. My two tickets for the day – with the new influx of staff we’ve had, and a fairly slow inflow of tickets lately, sometimes I don’t even get the option to do that many! (However, different times of year or new lots of code can produce a sudden uptick, so we take the rest while we can!)
Sometimes tickets aren’t nearly as straightforward. Sometimes it takes time to track down the bug – while I’m doing so, I’ll set the status to “Testing”. If the response requests additional information from the user, I’ll leave it as “Solving” until I can get a response from the user. If I find other bugs in 16Bugs or code issues in GCode, I’ll leave links in the comment leading to them, as well as leave links to the active ticket elsewhere. If the ticket contains a feature request, I’ll make a note on our wiki’s Feature Requests page and if it continues praise, I make a note on the Squee page.
Let it be said: us Support minions are human. There are tickets that have us staring at our monitors in awe, wondering “how did they do that?” There are tickets where we realize we’ve answered the same thing frequently, and therefore need better documentation and/or to prioritize a bug fix. There are times that we look at a ticket and mentally draw straws about who gets to tell the Coders that the recently-fixed feature isn’t so fixed.
All that said? It’s all worth it. It’s worth it, helping the users better interact with the Archive. It’s worth it, seeing the feature requests and ideas. It’s worth it, feeling like I’m contributing to the development of the Archive. It’s worth it.
I’ve now knocked out a couple tickets, updated a page on the wiki, updated a bug on GCode, and tripped over a work I want to read. Never let it be said I can’t take a sign! Off to read!
Mirrored from an original post on the Archive of Our Own.