Author: Alan Turing Owner: Alan Turing Date-Created: 1950-07-03 13:29:00 Summary: Write a chess-playing program As the rules of the game are algorithmic in nature, surely it must be possible to create a stored program capable of emulating or surpassing human play?but sooner or later, you have to write a little Boolean query engine so that you can find tickets created by Alan Turing, but owned by someone else, that aren't about "chess". If we were inventing issue tracking for the first time today, open source text search engines like Lucene might make text files under version control viable; as it is, every issue tracker I know of has a database in it somewhere (even Roundup, which breaks with tradition in many other ways). All right: what does our database need to store? Text fields for the creator and owner, another text field for the one-line summary, another for the body of the ticket... Oh, and date fields for when it was created and last updated, and---am I forgetting anything here? Oh yeah, how important it is, and whether it's a bug, a feature request, a question, um, better throw "miscellaneous" in there as well... And another date field for when it's due, and--- At this point, alarm bells ought to be ringing in your head. Jumping straight to implementation is a classic engineering mistake; instead of designing a database schema, I ought to be asking who the intended users are, and what they need to do and know. In one word, I should be thinking about workflow. I wish I could tell you we did it that way. I wish I could say we wrote out use cases, or at least user stories, and derived requirements from them. What we actually did was look at Trac, CVSTrac, Bugzilla, and a couple of other systems, then ask, "Which of the features in these systems will our students actually use?" When I have to, I justify that methodology by saying that DrProject is supposed to teach students how to use grown-up project management tools, so it makes sense for its features to imitate those of real-world systems. Still kind of wish we'd done more thinking up front, though... So: our typical user is an undergraduate student familiar with version control, IDEs, and automated builds who has never used web-based project management tools. She's working in a group of six; they have one term (12 or 13 weeks) to design, build, test, and document a moderately complicated extension to an existing piece of software. Here's a sample of what she and her team need to keep themselves on track:
- The team will create roughly a hundred tickets during the term. That's few enough that we can display one-line summaries of all of them on a single web page.
- Team members will want to see all tickets (so they can judge where the project is as a whole) and the tickets currently assigned to particular people (especially themselves). They may also want to sort by age (to find things they may have forgotten about), due date, and priority .
- They need to change ticket ownership (i.e., assign tickets to one another). We don't need to wrap permissions around this: if Jiao mistakenly or maliciously assigns all his tickets to Petra, the team will be able to sort it out.
- The whole point of integrating the ticketing system into DrProject is to hook it up to the wiki and other systems. To simplify this, ticket descriptions should support wiki syntax, and it should be as easy to link to tickets from wiki pages (and other tickets) as it is to link to wiki pages.
- free-form text fields, like the summary and body;
- those with other "obvious" types, like the creation and modification dates; and
- enumerated fields, like priority and owner.
- A configuration file: easy for the administrator to edit, but yet another thing that has to be in the right place, and formatted the right way, for the system to work. We'd also have to write yet another function to read and validate the values.
- A database table: not as easy to edit (although a command-line database prompt isn't much different from a simple editor), but we can grab the values with the same SQL queries we're using to fetch everything else we need to know about tickets.
 Trac's tickets have, among other fields, enumerations for priority, severity, component, and version. In practice, everyone seems to fold "priority" and "severity" together in their heads: issues are either urgent, important, or ignorable. "Component" is also problematic---many issues tie into many components, while others (such as questions) don't have anything to do with components at all---so we dropped it entirely. (Users can tag tickets with keywords to identify components if they want to.) Finally, student projects aren't big enough, or long-lived enough, to need version labels; once again, if a project does, it can use tags.  Saying that "dates are stored as dates" glosses over a medium-sized annoyance. As Victor Ng pointed out, Python's database interface libraries will return any of several different data types to represent a moment in time, ranging from a
datetime.datetimefrom the standard library to something as exotic as eGenix's
mxDateTime, depending on which database and database interface you're using.  The same thing applies to user IDs. Once a user is in the system, her ID can never safely be deleted, since that would result in dangling references. Instead, DrProject stores a Boolean "enabled" flag in each account record; disabled accounts cannot be logged into, mail is not forwarded to them, etc.