I've used Bugzilla, Mantis, JIRA, Netbeans' bug tracker, and FogBugz and found that they all basically suck. So I'm just going to give you a list of features that I'd like to see:

1.) A clean & simple UI. Reporters should just have a text field to enter the bug description and a way to attach screenshots/tracebacks/logfiles/tests/patches. All the priority/component/version/milestone/assignee stuff should be filled in afterwards, once the development team has been notified of the bug. Reporters usually have no clue what any of that means, even if they're in the same organization.

2.) It should be possible to submit bugs without a user account, with just an e-mail for further clarification. I can't tell you the number of times I've gone to submit a bug for some open-source software and then given up when I had to complete a lengthy sign-up process.

3.) E-mail notification, both for developers and for reporters.

4.) Integration with unit testing frameworks - I'd like a way to attach test cases to bugs and then automatically run all the tests with say JUnit or Nose. When a test fails, it'd be nice if I could be linked straight back to the initial bug report, to see where the regression is. Make sure you play nice with existing conventions for where tests go, eg. the tests/ subdirectory that many Java IDEs setup or the functional-testing facilities in web frameworks like Rails and Pylons.

5.) FogBugz has a nice screen-capture utility that's very handy for desktop software..if you can get your hands on a copy, you may want to check that out.

6.) A programmatic API. There're two main use-cases I want here. I want to hook the feedback form on the website itself up to the bugtracker, so that every time a user submits feedback it goes straight into the bugtracker and sends me a notification e-mail. I also want to hook existing functional-testing frameworks up to the bugtracker, so that if a test fails and is not already associated with a bug, it creates a new bug with a description of the failing test case.

7.) Check out the Subversion integration in Trac...I've never used Trac myself (keep meaning to check it out), but I've heard some very good things about it.

There's my wishlist. I'd be willing to pay FogBugz-level prices (hundred or so per seat) for a bugtracker that was actually useful. I wouldn't be willing to pay JIRA prices (couple thousand per seat).

We use Lighthouse (http://lighthouseapp.com/) and find it simple, extensible, and useful.

It covers most of your points but doesn't include bug reporting/tracking by people not on a project (e.g., users). Their API and email integration should make it easy to integrate your own "report a bug" form.

I've had great luck with Unfuddle: http://unfuddle.com/

They also offer svn hosting, but that is optional. (you can simply use them as a bug tracking system)

They've been very responsive to feature requests and have fixed several bugs/issues that we complained about, when they were still in their early days.

Thank you very much for the feedback.

fyi JIRA runs a couple thousand per server, not per seat.

JIRA covers 1(via configuration), 3, 5, 6, 7. Possibly 2 and 4 via plugins.

No affiliation with Atlassian, just a (mostly) happy customer.

We use Trac at Justin.tv. The only thing that really bothers me is that it's kind of slow - up to 2 seconds to load a page.

Other than that, it seems "good enough", but I'm sure there are advances to be made that I've never thought of.

I love the way Trac integrates with subversion. A friend of mine even wrote a nice plugin that allows you to close a bug in Trac just by doing an svn commit, by writing stuff like:

svn commit -m "Stopped electrocuting users, fixes #4959."

Cool, we use that plugin. The only thing that annoys me is that when you're merging branches with svnmerge, it includes a copy of the log messages for all the merged revisions -- which is then processed by subversion, and has the effect of re-closing or annotating any Trac tickets mentioned in those commit messages.

Trac is perfect for us. The integration of everything in the wiki and just enough database like features makes it a killer combo for small teams (5-7). Just linking to tickets and svn changesets with wiki-like syntax is great. If you use Trac be sure to visit trac-hacks.org for plugins and macros to enhance your install.

I'm going to second Trac. I'm using it primarily because of its easy integration with Subversion.

Indeed. I just started using it, and it's quite good.

Has anyone experienced a speedup by not using the built in server?

We had it running fine under FastCGI, as well as mod_python for a few quite large projects and about 30 active developers (and a few dozen moderately active users). Speed wasn't a problem in either of those modes, but I recall that when it was straight CGI or using it's own server it was close to unusable.

I have a trac 0.94 install running on a pentium 800 through Apache and its definitely fast enough. I am not using Fast CGI though, so it could potentially be faster.

Trac is sweet but is simply a royal pain to setup.

Anyone offer an outsourced, hosted version of Trac? =)

google "trac hosting".

I use assembla.com.

Thanks =) I'll check them out!

Me too. Trac is nice if you are using Subversion.

John.

I use trac which is integrated into my IDE (Eclipse) with a task management plugin called Mylyn. It's free and it does everything I need to stay organized with the other 6 developers on my team.

What problem are you solving again?

I submitted a similar idea as a last second YC application.

Basic points of differentiation were that it would be fully extensible (add/remove any input fields), and that it would have a killer API.

The API would allow you to submit issues from anywhere you please: you could write a plugin for Eclipse (or favorite IDE) or you could widgetize it into a js include file so people could submit issues directly from your web page (think beta testers).

Just wanted to chime in that Roundup and trac are extensible with regards to fields, as well as actions. Both have a pretty good API, as well.

We should be able to easily split one bug report into multiple reports (for cases where one bug has multiple causes, or the reporter incorrectly perceived multiple bugs as a single bug) while keeping history of the case. And vice versa, for when a single bug is reported multiple times. Most bug trackers just let you resolve things as duplicates, which is kinda half-assed.

Here at Xobni, we were first using Retrospectiva: http://retrospectiva.org/. Pretty UI, fast, Rails-based, simple to use and tweak. Free.

We later switched to Jira, which is expensive but powerful and a bit cluttered. Jira actually charges a flat price, not per seat as nostrademons suggests.

This came up 60 days ago:

http://news.ycombinator.com/item?id=45666

I've never used one. Much like version control, I've never felt the need for it. If you have a team of 2-4 coders, and aren't preparing the next version of Firefox, why aren't text files/emails sufficient?

A team of 4 coders, WITHOUT version control?? Oh dear...

He, I was just saying. I've always coded alone, or with only one other person. And that person was using my code as a library. I figured that working like this would scale, modular and bottom-up. Maybe not.

(besides, isn't VC a relatively new proposition? I'd be surprised if PG and co. used it for Viaweb)

Let's leave version control aside. Could someone spell out why bug tracking is so great? Thanks.

I use Trac and I really like it.

Roundup

issuesdone.com :)