Bug & Issue Tracking

Amen brother! I’d love for the 37 signals folk to make a bug/issue tracker. I think they do really well at dead-simple web applications.

I’ve used a bunch of the open source ones (flyspray, mantis, etc) and they’re all the same, pretty much. Overly complicated, like you say.

The one that made me the happiest is the issue tracking that’s included with trac and it’s still a little heavy to me. Plus I don’t normally need all that other stuff it comes with.

Have you looked at FogBugz?

It seems like no one who has ever designed a bug tracker has stopped to think that it might end up in front of someone other than another programmer. At least until a client has to submit a bug.

I ended up hacking the Trac template for the new ticket page, taking off 90% of the content and leaving a page with three fields and the “submit” button.

Bugzilla seems okay..ish but a simple to use bug tracker that I could let my clients loose on, with multiple project capabilites and with a nice logo to boot… where do I sign up?

Not that that answers your question.

Bugzilla is annoying. I think that it has the least friendly interface of them all. Could a GTD or a beefed up todo be used as a means for bug tracking?

I had used a modified version of workbench for a while that I was pretty happy with. It doesn’t look like it’s under development any longer, but it was a dead simple and easy to use product.

There’s also something called Tasks (right, great name pfft)... thats even simpler to use, for non-technical people.

I went searching for a solution at some point this year and found nothing that wasn’t over engineered or a pain to use (or a dead project). As for 37signals, it seems that they are using Basecamp for bug tracking, which can’t be too enjoyable, so maybe something will come of that.

You could give PmWiki with PITS a shot. (Note that someone’s attached several cleaned-up versions of the PITS script in the comments area of the PITS page.)

I think the biggest issue with bug trackers, other than bloat is the way in which users contribute bugs. They tend to have to find the bug tracker, sign up/log in, and then they create a bug and write simply.

“Images show up small”

Not really the fountain of knowledge, which is why there tends to be so many fields to enter, so users can have their hands held through it all.

I have always wanted something where, when there is a bug, users (somehow by magic) get presented with a big thick pen and draw ontop of their screen, ‘this doesnt work’, or ‘this is too small’. Then I get the screen shot plus the comments (layered of course) plus a little basic info about the machine/browser…

Now if someone can tell me how to do the screen capture thing over the web, I will be happy to code the backend :)

I also have spent some time to find a bug tracking I’d put my clients in front of, but coulnd’t find anyone.

Are you going to publish a article review of the bug tracking systems you inspected?

http://www.atlassian.com/software/jira/

I haven’t tried this but it was heavily recommended by quite a few of the members on stage at “Evening at Adlers” and looks awesome from the demo http://www.atlassian.com/software/jira/try.jsp

I totally agree about the complexity of all the bug tracking software out there. Bugzilla i think has one of the highest learning curve.

However, I think most bug tracking system out there is designed to be used in a team, with lots of members working in the same product. Say, in Bugzilla, there are different people assigned to different components (library, UI, modules, plug-in, netlibrary, etc.), and different people assigned to different OS versions (Win, Mac, Linux), and there can be other non-software components as well, like technical writing and product manuals. All these makes up for a complex bug tracking system that bugzilla serve up well.

Also, most big teams have assigned customer support people to receive complaints from customers, and these complaints are communicated first with the product dev manager, and from these conversation, it will be determined if it is indeed a bug. From there, once a bug is identified, it is only then when it will be entered to Bugzilla.

For small teams, say one person, or two, or three, you’re better off using Backpack’s list and multiple lists with sharing feature. :)

I’ve tried a lot of bug tracking softwares out there, DCL, phpProject, mantis, and some i can’t even remember anymore, and after evaluating all the different options, in turns out for a small team like in our case (5 dev, 1 manager), using MS Excel proves the best and easiest to use. But after i’ve heared about Backpack, we’ve since moved everything there. One backpack page per milestone and per product (for post-release bugs). :)

I completely agree. We have to support a great number of internal applications for about 160 users. We ended up using a hacked up version of Bugs for developers and writing a dead simple frontend for our users. We even went as far as writing a mask for the severity levels to make it as friendly as possible.

Trackbacks don’t seem to be enabled so here’s my take on the Bug tracking thing.

My Recommendation: BugTracker.NET

QuickBase, because all your base is ours.

I also have this problem. Not for bugs perse but for issue tracking for a help desk. It seems like everything I find that is even remotely decent is for software bugs. I’d just like something simple that can keep track of callers, their problems and perhaps have some customizable fields. Even the helpdesk software I’ve seen is bloated and hard to use the data for statistics, etc.

I’ve seen Bugzilla customized and re-skinned to be much more usable. Basically, we just created our own stylesheets and removed all of the fields that wouldn’t be used.

Still, the language and expected user flow was very developer-friendly.

PHPCollab has an issue tracking component, but it is very simplified. I’ve been very disappointed, except for JIRA. It seems to be really nice. However, for now, it’s not as cost-effective for us. We went ahead and bought Axosoft’s OnTime. If you aren’t limited to OSS/free, it seems to be a good solution so far. VS.NET integration, an .exe and a public portal & API…and works in Safari and FF Mac.

Garrett, I completely agree with you. Which is why we’re making our own bug tracker which encompasses the values you want, simplicity, a good user interface, with enough features to do the job, but no more. You can find out more here

It’s currently nearing the release of 1.0 which should be out next month, in the meantime there are screenshots & demos. I hope you don’t mind the shameless plug but I feel it may well be what you’re looking for!

I use JIRA just about everyday. It is a good system, and it’s dead simple to get working. However, it’s not really small team friendly, because of the expense, and that it’s java based. It needs a fairly decent environment to run in and most free-to-cheap webhosts don’t meet the req’s.

I think they do some kind of open-source deal, at least with pricing, which is cool. Don’t get me wrong, I like working with it, but I need something simpler/cheaper for my own small projects.

John Evans – I’ve just emailed you directly about the remote screenshot issue (I run SiteVista, so we’ve got a whole backend setup for doing exactly that). I’d be happy to collaborate on a tool of the kind you’re suggesting.

The thing with bug trackers is that it’s suppose to identify as much of the problem as possible.

If a bug tracker only had 2 or 3 fields then your going to get a lot of back-and-forths, with the developer asking, “what browser are you using? what OS? What version? etc…”

I just wanted to drop in and say thanks to Bronwyn for pointing me towards PITS. With a few additional hacks from the pmwiki cookbook I’ve managed in about 2 hours to put together a easily extendable bug tracking solution that’s more suited to my needs than ANY commercial offering.

I’ve been looking for a solution (that i didnt have to code myself) like this for months.

Thanks a lot Bronwyn!

We are a .NET shop, so we find BugSentry to be awesome. We got in on an early beta and wouldn’t go back. It is designed for small teams and really shines on post-deploy issues. You add the library to your code, then call it from your exception handler. They host the data, so the library submits your issue encrypted with your public key. They send you a message telling you about the problem. You fire up the desktop client, it gets the issue and decrypts it. I know the team and I think they are in in late beta now.