I was having lunch with JL awhile ago, and we were talking about some recent Verilab email threads.

Participation in email threads is fairly high at Verilab: If you ask a question, you’re pretty likely to get an answer. Or three.

But even though participation is the norm, there is no guarantee that you’ll get an answer. There’s no guarantee that the person with the most useful knowledge will chime in. Well, these aren’t novel concerns, and there are tools to address them: Bug trackers. I’m rather a fan of bug trackers, and I think they could be used far more widely than is typical. And foolishly, I promised JL I’d write a blog on the subject.

So I started to organize my thoughts: My central themes would be the interface and the data model. I would argue that the bug tracker data model is far superior, but the interface is often far too cumbersome.

A bug tracker keeps state (and state history) and responsibility metadata. A bug tracker manages a to-do list, and if it weren’t a useful data model, then to-do lists would have gone extinct; and that ain’t happening.

Any communication that desires a response is actually an addition to someone’s to-do list: “Please respond”. And the vast majority of communications do desire responses: “Please book me on a flight to Aruba”; “What’s the Emacs keystroke for …?”; “I’m going to see the new movie on Friday at 8, wanna come?”.

Why not use a bug tracker for all of them?

It seemed so obvious that email does not support this data model as to be hardly worth mentioning. So why is email so popular for a function that it’s not actually best suited? Or perhaps, why are bug trackers so unpopular for the very task they’re designed?

Consider: The actual message, the to-do item, is the same either way; so if it’s not the message, then it’s the medium. And the medium consists of the interface and the data model.

What’s the difference between the interface of a bug tracker and an email composer?

What do you see when you click “Create a New Bug”? Usually, a bazillion required fields you have to fill in. How many of them are actually relevant to the to-do item you want to create? Remember, I’m proposing to use a bug tracker for all your to-do communications, for work, home, and play. Probably less than half a dozen fields are actually useful for all: Title, Detail, Who’s responsible. Sure, other fields might be useful sometimes, but not every time. Now, what do you see when you click “Compose a New Message”? Subject, Body, Address list. Hmm. Not bad. Not bad at all…

And what’s the difference between the data model of a bug tracker and an email client?

I’ve already mentioned state, history, and responsibility, and I’ll come back to them again shortly. But there’s one other aspect that I think is actually the most important of all: Email uses a decentralized data model. All the bug trackers I’m familiar with operate on a centralized database, and centralized resources just don’t scale indefinitely.

Now back to the metadata: I hinted above that Responsible maps pretty well to Address list. And History maps pretty well to Thread. What about State?

And it just dawned on me that many email clients do support State annotation (”label” in gmail, “tag” in Thunderbird). I’ve never actually used it, because I never before recognized a compelling value for it. But now I want to experiment. Do you mark mail ToDo? Does it work for you?

Obvious question: How do I maintain consistent State across a distributed database? And it struck me: In a decentralized system, self-organized consistency naturally emerges among cooperating peers. If the people I communicate with cooperate, consistency just happens. And if they don’t, then the only state that matters to me is the state I assign in my database; consistency with an uncooperative correspondent’s database is completely worthless and completely irrelevant.

So while writing, I’ve argued myself clear around to the opposite of my original opinion: It seems entirely possible that email might be a quite effective bug tracking tool, if used properly. It just requires disciplined adherence to a usage model.

And now I have to ask instead, “Does a bug tracking tool have any benefit over email?”. I happen to still believe the answer is “Yes”, but it no longer seems such a self-evident Truth. For one thing, I still think it’s self-defeating to setup an input form with too many required fields. Could bug entry ever really be as easy as email composition? Think of a bug input form that you thought had too many required fields: How many of those fields could be replaced by a single “Keywords” field? What if the interface were sensitive to your login name, and you could configure a set of favorite keyword check boxes? What if the tool automatically presented check boxes for the keywords you use most often?

In a corporate environment, I think a centralized database is the primary benefit. The value of a decentralized database is “one database per identity”: It’s your communication, and your database. But a corporation is in many senses a group identity, so the paradigm shift is our database for our communication. State consistency is guaranteed, anybody can query it; even if group members join or leave; people can subscribe to keywords even if they weren’t in the address list; maybe you wouldn’t even need to supply an address list, people would just claim bugs that they knew how to deal with. Is this starting to sound like a mailing list? Wouldn’t you like to just compose an email to “us” and not care whether the back end is a list server or a bug tracker? Could the bug input form just be an email “template”? I’ve never used email templates, I don’t know what they can and cannot do, but now I want to experiment.

Someday (not today) I may write about marrying bug tracker with revision control. And another someday (also not today) I may write about marrying email with revision control.

This entry was posted by Kevin Johnston on Saturday, December 15, 2007 at 8:46 pm and is filed under News, Software. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.