Further Thoughts on Filing Bugs
December 18, 2006 – 5:32 pmPursuant1 to last week’s post on making tickets simpler to work with in DrProject, I’m now wondering whether the real problem isn’t the number of fields, but the fact that the only way to file a ticket is through a web browser. If you’re grinding away in Eclipse (or Notepad) and want to add a note to your project, you have to:
- Click on “Favorites”
- Click on the link to your project
- Enter your user ID and password (since your previous session has almost certainly timed out)
- Click on “New Ticket”
and then jot down whatever it was you wanted to jot down. Of course, by this point you’ve lost your original train of thought…
Simplifying the interface isn’t going to solve this problem (as Alastair Cockburn says in his latest book, “Efficiency is expendable in non bottleneck activities.”), though it wouldn’t hurt. And no, Andrey, lengthening the session timeout isn’t a real cure either ;-). I applied for a grant to do a proper scientific study of impact things like the Mylar plugin for Eclipse (which provides an in-IDE interface to ticketing systems, among other things), and the Visual Studio plugin for FogBugz, would have, but IBM turned me down. If anyone is looking for a medium-sized project that’ll make ‘em rich, famous, and popular2, please give me a shout…
[1] I’ve always wanted to use that word in a blog post…
[2] I lied about the ‘rich’ bit, but small-f famous and small-p popular are not entirely impossible…
2 Responses to “Further Thoughts on Filing Bugs”
> And no, Andrey, lengthening the session timeout isn’t a real cure either
.
It could just as easily be. Get rid of the session timeout altogether, simplify the interface, and the developer could have a ticket adding Firefox window sitting side by side with her IDE. (Though it might not suit your security requirements, but that’s a different ailment.)
Personally, I believe that ticketing has been done wrong from the start (not just by DrProject). Ideally, it should be a gradual evolutionary process from a “Todo” item, to a matured “Ticket” item.
My vision of an ideal ticketing (if you can call it that) system:
1. Run into a segment of code that needs additional attention (but I’m working on something else at the moment).
2. Switch windows, jot down a one-liner note, tag it as a to-do item. Emphasis on one-liner — providing a textarea versus a one-line input box makes a huge difference in the way people use the application.
3. Carry on with what I’m doing
4. … Some time later, I’ll go back and review my todo’s for the week, tag them with further metadata (possibly delegate review for even later, maybe by someone else).
5. Eventually, items that have been tagged for ticket status consideration will be elaborated further (not necessarily by the same person — in fact, it might work better if someone else does it).
But this goes far beyond the scope of Dr Project. There’s a couple more realistic options:
- The problem lies in the ticketing interface begging the user to write a thorough and verbose explanation of the problem, while the user is busy doing something else. If it gave the option to write a simple one-liner description and come back later to explain/manage it, that might help.
- If Dr Project could fetch /// TODO: comments from the source and display them in a list somewhere (like Eclipse does) which can later be rehashed into tickets as necessary, that would be sufficient.
Disclaimer: I have little industry experience, so it’s likely that I’m wrong.
By Andrey on Dec 18, 2006