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

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 :)

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

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?