Strawman Proposal for a New Ticketing System

DrProject has been in use in half a dozen courses at two universities for over six months. We’re mostly pleased with it, but it’s clear that the ticketing system needs a major overhaul. Most class projects need nothing more than a shared to-do list, but some (like DrProject and OLM) need the priorities, due dates, and so on that real ticketing systems provide.

Cutting it another way, I’m mostly opposed to telling students they have to use tools—I think it’s more likely to turn students off, and if the tool doesn’t appeal, it should be redesigned. There are times, though, when the whole point of a course is to teach students to work a certain way, and in those cases, I want to have a full-blown ticketing system for them to practice with.

How can we reconcile these competing forces? Options are:

  1. Keep things the way they are, and tell students to live with it. I don't like this, because what it will teach most students is that ticketing is "just overhead".
  2. Don't even try: build a separate to-do list, and provide an easy way for users to promote items from there to the ticketing system.
  3. Make the ticketing system customizable, extensible, or both. The former means that the set of fields that could be displayed is predefined; administrators and users can select which fields they want to use and see. The latter means that people can add new fields to tickets after the system is up and running.

Here’s a proposal, which I’d like everyone out in blogland to poke holes in. It’s inspired in part by Roundup, in which each ticket is its own dynamically-growing mailing list. Every message about the ticket is appended to the “list” (just like comments on tickets are appended to tickets); every time someone is cc’d on a ticket message, they are automatically added to the list, so that it grows to be as big as it needs to be. The system as a whole lets users define aliases for groups of people (like “QA” or “Customer XYZ”), so that groups can be added as well as individuals.

This proposal is also inspired by tagging, in which the vocabulary grows as it needs to. Many tagging systems (like use typeahead to encourage people to re-use vocabulary; I think every extensible system should try to do that as well.

So, here’s a ticketing system that grows to be just as big and complex as its users need it to be:

  1. In a fresh-from-version-control DrProject installation, a ticket has just four fields. Title and description are wiki-formatted text; title is mandatory, but description is not. The ticket's author is automatically recorded, and the system gives each ticket a unique sequence number. That's it: a simple to-do list.
  2. Anyone who can modify a ticket can also add new fields to it. To add a field, the user selects the type (integer, enumeration, timestamp, text, etc.), gives the field a name, and fills in a value. For the moment, we won't worry about whether this is done with forms and POSTs, or AJAX, or telepathy.
  3. Once a field XYZ has been added to any ticket, it is available whenever any new tickets are created. For example, if I add "Due" to ticket #22, the form for creating tickets will thereafter have a "Due" field with a calendar popup. If I add "Owner", of type "UserId", subsequent tickets will have "Owner" with a pulldown to select a user. If I add, "Priority", the ticket creation and editing forms will---oh, wait I have to talk about enumerations.
  4. If a user creates an enumeration field (e.g., ticket state or priority), she must provide one or more values for that enumeration. These are just symbolic names, but she must specify the sorting order (probably just the order in which they are entered into a text box, but that's another UI question which can be deferred for now). Other users can later add more values to the enumeration. For example, if I create "Priority" with "High" and "Low", Jay could later add "Medium" in between.
  5. Admins can pre-load fields in a fresh installation, or bulk add fields without creating tickets. In a project course, for example, I'd add "Priority" and "Owner", but might not add "Due", since stuff's due at the end of term. In a regular course, I might add "Owner" and "Due", but not "Priority", since students can probably keep track of that. And in the real world, people might add "Parent" or "Predecessor" to build those inter-ticket links we've been talking about.

Open questions:

  1. Would this, in principle, solve the problem we're trying to solve? If not, none of the other questions below is worth answering...
  2. What happens to tickets that already exist when a new field is added? Are users required to specify a default for previous tickets? If so, does that default apply to future tickets? Do we have to go back and fill in existing tickets? Or is every field nullable?
  3. Can users delete fields? If so, does this really delete the field from all tickets? Or just hide it (i.e., make it invisible), so that old data in the database remains consistent?
  4. How is this stuff laid out? Are fields show in the order in which they were created? Can users specify where fields should go? Do we embed some sort of graphic design AI in DrProject? (I'm guessing not...) Or can we AJAX up a drag-around interface?
  5. What schema do we create to support this? I started doodling one last night; I'm not frightened by its multiple layers of indirection (I am, after all, a reformed C programmer), but I am bothered by the fact that ticket operations would require Python-level loops, i.e., they couldn't be written in SQL alone. (My schema puts all the string-valued fields in one table, all the date-valued fields in another, and so on. The alternative is to give each record N columns, one for each data type, and only use one of those; the code around this doesn't look any prettier...)

See also:

In the wake of posts about Shopify's support for white nationalists and DataCamp's attempts to cover up sexual harassment
I have had to disable comments on this blog. Please email me if you'd like to get in touch.