Tracking requests

W3C is a fifteen-years old organization, where plenty of people come to collaborate, with a high variation among them in terms of operating systems, computer proficiency, corporate set up, etc. A number of our users manage to be even more geek than we are in the Systems Team, while for many others, a computer is just a tool that really ought to "just work" (which they still often don't).

The result of that interesting mix is that we have set up over time a fairly large number of tools to facilitate collaboration: several hundreds of mailing lists, an IRC server with a few handy bots, a fine-grained access control system, a questionnaire system, a flexible editing system combined with a robust mirroring scheme, wikis, blogs, various bug and issues tracking system, etc.

And as all these tools are entirely bug-free and work seamlessly together and for all our users (NOT!), we have always had a need to track requests from our users to create and manage various accounts, set up new instances of these tools, correct or work around bugs, etc.

Over the years, the way we have tracked and managed all these requests has evolved, toward somewhat more formalism as the number of our users and tools grew.

When I joined the Systems Team in 2000, our tracking was entirely based on manual scanning of mails threads sent to one of our internal mailing lists: basically, each of us watched for what looked like a request, checked if anybody had responded to it, and if nobody had and the request was something you could manage, and you had some time on your hands, you would take on it.

Given how informal it was, it actually worked quite well, although over time we added some more purely conventional practices: requiring the use of a specific mailing list of a specific type of requests, adding a [closed] flag to the topic of a thread to signal that the request had been dealt with (so that others could simply delete the thread without bothering reading it).

But as the number of tools and users continued to grow, we started to get complaints that some requests had not been dealt with at all, and it became clear that we lacked overall visibility on what needed to be responded.

Back in 2002, I wrote a quick XSLT style sheet that would help us get more visibility on the state of our requests: it took the threaded view of the archive of our request mailing list, and would look for any thread that didn't contain a message starting with our now conventional [closed] flag, and would present a report showing all the requests that hadn't been closed, as well as those that hadn't had an answer at all.

And again, that fairly simple system served us well for quite a few years; some others W3C groups even started re-using it for tracking their issues, and a similar version of the tool based on more Semantic Web technologies was used by a couple of groups to track their specifications' Last Call comments.

But no matter how well that solution worked, we decided last year that we would finally move to a proper tickets tracking system, the well-known open-source RT, to get the following advantages over our existing hack:

• get a clear view of who was working on what ticket,
• be able to assign a given ticket to someone, even if that person hadn't picked it up yet
• easily find tickets that were stalled due to lack of responses from the requester (vs. because we didn't act on it)

The first few months with RT weren't quite so rosy, actually, as we had to find ways to integrate it as smoothly as possible in our current procedures and infrastructures, and with our mailing list habits.

Some of the changes we've brought to it include:

• make it track messages sent as part of a given thread (as identified by the In-Reply-To header) as belonging to the same ticket (even without the id number included) - with an an existing patch to that end;
• change the way it modified subject messages (with the Branded Queues extension);
• fix partially the way it sends messages and notices through the configuration UI;
• make it understand our [closed] convention so that we could continue using mail as our primary way to close a ticket, using a simple "Scrip" inspired from another RT user's contribution.

There are still some rough edges - RT seems to be particularly reluctant to send messages in CC when using the Web interface for some reasons, we need to integrate it better with our existing accounts system so that our users can better follow progress on their requests -, and some user interface and HTTP behaviors problems that make me cringe.

But overall, I think the tool has certainly helped us regain control over our growing number of requests, and is also hopefully steadily allowing us to offer a better experience to our community.