skwpspace yan pritzker’s home on the web

Bugtracking in the new millenium: how to build a better mouse..err..bug trap

It’s not Bugzilla’s fault that it sucks. When most of the bug tracking projects out there were started, we didn’t know rss, we didn’t understand tagging, we thought in terms of fields and hierarchies, and we thought proper usability and web design were out of our reach and not as important as getting a functional product out. Unfortunately some of the newer ones aren’t quite getting it right either. Well it’s time for a change. Someone has to build a better bug tracker, and here’s what you need to do it:

What did I miss?

Distributed. I would like to track tickets associated with my discributed SCM branch, but also on the upstream.

Of course I forgot to list SCM integration explicitly…but the automatic ticket flow system should allow plugins…so we should be able to cross-link issues with commits.

Yeah but you missed my point I think. I want the tracking system to be distributed along with the SCM. That way, the bug list is also distributed.

@zimbatm

Yeah I agree with you, that would be a good idea. Maybe a darcs-like implementation where I can record my source changes and bugs at the same time and then merge them upstream or have people look at my local repository and progress. On the other hand..bug trackers are most useful when everyone is on the same page..so if you’ve ‘taken’ a bug it should probably be marked as such in the global bug repository..not sure what you gain from having the actual bugtracking info distributed?

What are your thoughts?

Nope… I really can’t think of anything else, you’ve nailed it on the head.

These are great notes for us as we’re building http://www.smrty.com to track issues and time spent on them. several of these are in there already, but there are a couple of real gems in your outline.

the intelligent bug searching especially is a great idea, it’s really the missing link in terms of the typical bloat of the same bug being reported over and over again.

Now figure out how to combine inteligent grouping of emailed in bugs so there is some auto grouping of like bugs that helps an admin sort them?

Just thinking, people still just want to fire off an email whenever they have a problem.

I have a question?

Why don’t more apps have a “report a bug” link built into them… instead of fishing around in the contact section and being led down the garden path of their “knowledge base” (i hate that term) with no clear end in site… then you can direct the reporting style much more succinctly… so as I think about it, the only logical solution would be a hosted app that ties into your application and let’s users see common bugs reported as they are entering theirs.

Pardon my mental process here… this is really good stuff.

And by the way, my initial impressions of planyp.us are great, very well thought out application.

Riel Roussopoulos
IXLD Media Inc
http://www.ixld.com

Riel

Thanks for your comments! Good to see someone working on this problem.

Time tracking is one thing I forgot to mention. Lots of bugtrackers leave this one out and I think it really helps to know that your release is 2 weeks behind due to bugs. Not sure estimation is worthwhile cuz it’s rarely close to being correct, but after you’ve solved the bug putting down how long you spent could be useful, but it has to be super easy, like one click inline editing, not waiting for a new page to load because that’s a major deterrent.

As far as intelligent grouping, not sure if you’ll get any more intelligent than just having some dedicated support people sorting things. You could also maybe employ machine learning like bayesian or latent semantic indexing to try to sort bugs into buckets (interface problems, backend issues, etc), but in most cases the user reporting the bug has no idea where it came from and most users only see the surface manifestation in the interface anyway…

I think I know why apps don’t have report a bug: people hate dealing with support emails. So they intentionally or subconciously make it difficult for users to send feedback. They’d rather have the user waddle through an hour of documentation reading…somewhere along the line we software guys forgot that the customer always comes first.

Thanks for your comments on planypus..we are working through a big redesign right now as there are still many usability issues. We finally got a designer on board so expect some nice changes failry soon :)

I think the support mails should be sorted automatically into the bug tracking software: have a pop3 read that just sucks in anything sent to BUG@domain.com into the bug reporter, people are comfortable with email reporting, while it’s not the easiest to track and report on the receiving end, if it was integrated into the application it would be able to be uploaded to a “bucket - as you call it :)” and sorted from there (the sorting is our biggest problem right now, dealing with the duplicates.

As for the timer, we just have a one touch link that turns on / off the timer as you’re working on issues.. the link is at the top of each issue, so as you start to read it, it’s easy to click the “TIMER” - or “SWITCH” as we call it… then as you reply or update the bug report later (assuming you’ve worked on it) you simply click the link again to stop the timer… or start a new timer on a new issue which will automatically turn the first one off.

Thanks again for the mental work here Yan, I’m going to share this with my whole team.

“Riel Roussopoulos”:http://riel.roussopoulos.net