We use Jira, but it is much more than a bug tracker. With Greenhopper, it offers us complete issue management, which includes iteration planning in stories and tasks. With FishEye it integrates a view on our subversion repositories into that, allowing crosslinks and beating the pants off of any other solution.

We switched to Jira after getting annoyed at Mantis once too often. We all had experience with Bugzilla, which is like using bow and arrow in these days of guns. We investigated for a bit, looked at Trac and FogBugz amongst others, but decided in favor of Jira, primarily because of Greenhopper. Issue management without decent planning abilities is like a blunt knife: usable, but unnecessarily hard. Haven't regretted it one single bit.

We started using JIRA this year after using unfuddle and pivotal tracker. The ability to have issue and story tracking in one place has been great. Greenhopper is really nice, since we now have much more visibility across the teams; testing, product, ops, engineering.

It does take time to get setup to fit your organization but it has been worth it.

We use GitHub Issues. It's very barebones but ties in very nicely with our source control site of choice: GitHub, and there is no need to context-switch.

I use github issues too. If you prefer the shell over the browser you may want to use this - https://github.com/kashifrazzaqui/github-issues

And on the opposite end of the spectrum, you can find: http://githubissues.heroku.com/

Just looked at this, it looks super useful! Going to try it out.

YouTRACK--a keyboard-friendly fast fast FAST bug tracker from JetBrains (of IntelliJ fame).

http://www.jetbrains.com/youtrack

After I gave up the concept of tracking bugs and doing feature planning in the same app (sounds great but has never worked in practice), this tracker became my default for any projects where I have a say in the matter.

We moved from JIRA because administering a JIRA installation is practically a full-time job. Have also used Fogbugz, Redmine, Mantis, Bugzilla over the years, so that list is my main basis for comparison. I hate YouTRACK less than those.

Edit: I see they are now offering a free hosted version for the first half of 2011.

Post-It notes and 'drop everything and fix it now.' If it's not important enough to fix now, then it's alright if we forget it.

I like the Post-It note strategy.

Especially when all the notes are on a public window/wall. This way everyone can see the 'queue' of stuff and is a good reminder to re-prioritize constantly.

I work for Atlassian so I'm biased ;)

Good to see another Australian company taking on the software development market. Especially good to see that the company is partially funded by the Atlassian founders!

someone's done their homework :)

Not so sure if we fall into the software dev category so much as the web dev category as we're really only supporting tracking on websites and web apps.

For those of you who don't know, the OP founded http://bugherd.com/

toast76, can you explain what makes BugHerd unique?

Awesome leading question, thanks!

BugHerd is a tracker for web developers and designers run within the website you're working on. Part feedback tool, part bug tracker, part QA tool. It's a bug tracker that engineers, designers, clients and stakeholders can all use. Each group has a different interface meaning no one is ever in over their head. A lot of the stuff you normally have to enter manually is logged/tracked automagically, meaning more often than not a short description is enough to get all the detail you need to reproduce a problem.

I like the visual selector similar to firebug or chrome developer tools to select a div or element in the page. Though, my question is, what information are you saving per bug when you are selecting a "feature" of the webpage? It would seem that on any website that is not static that you would need to save the whole page images included for each bug so that you can show the bug at the time of inception or at least a snapshot of the page transformed into an image.

The problem with taking a snapshot is that it quickly becomes out of date, and as you mention can be different with different content. We use some fuzzy selection methods to select the underlying DOM node that is causing you a problem.

When a user goes to look at that bug, they're taken to the actual page and location where the problem occurred. This means that even as the page changes our bug tagging still points to the right place.

We also keep tabs on all sorts of user/browser information to ensure a bug can be replicated. We have some more tricks up our sleeve for replicating page state and user data (not yet released).

So I've been using "ditz" on a few projects and I quite like it. It's about the most minimal bug tracker you can get, but I like that the bugs get checked into your scm, right along with the code. I also like that I don't need to launch a browser to add or edit bugs. It fits in beautifully with distributed VCSes like darcs or git.

For musicbrainz.org we're using jira. I'm not particularly happy about that, mostly because jira is not open source/free software (and musicbrainz is). Otherwise no complaints, jira does everything we need it to do, and apart from some interaction design issues does it quite well.

We primarily use the GreenHopper plugin to interact with JIRA. This allows us to both track new development and defects in an agile friendly way, without the need to maintain all the index cards.

Emacs http://orgmode.org/ in combination with http://mercurial.selenic.com/

Me too. Org mode works very well as a personal bug/task tracker but I don't know how I'd use it for collaborative work.

yes, maybe mercurial is a way to share org files, but I'd go for a centralized database tracker for team tracking. But for personal tracking, I just love org. Fast and flexible.

I use GitHub's issue tracker

Bugzilla. I wouldn't say I love or hate it, but it works and it's what I know. The biggest downside is that I'm not a Perl hacker, so if I wanted to hack on BZ, I'd have to take the time to learn Perl. Luckily I've never felt much of a need to modify Bugzilla. It just works.

"Stop doing everything and fix it" along with basecamp to-do lists for the other, non critical bugs.

Basecamp is awesome if a lot of people involved are non-technical. They tend to get dizzy looking at Jira/Trac.

I am technical and I get dizzy looking at Jira. The product has some great capabilities, but they REALLY need to optimize the UI for particular user personas and not just puke every feature on the screen.

I use Taskpaper as a task/bug tracking file. Plain text file with GTD token support and line filtering.

Clicking at the beginning of '-' prefixed line will add @done(2011-02-22) and appear as stricken through, and even hidden or moved to the end of the file. I have one per project, and they are tracked with git. Searching for "not @done and not @cancelled" will only leave the tasks remaining to be done.

http://www.hogbaysoftware.com/products/taskpaper

I use an extended DarkMatterPlus* theme file from http://groups.google.com/group/taskpaper/files

* : @fix appear in bright orange, @cancelled behaves the same as @done etc...

Google Code -- I'm surprised it's not listed. I recently had to decide between GitHub's issue tracker (I'm already using GitHub for source code hosting) and Google Code, and almost everyone I could find that had an opinion said Google Code was much better.

I am using JIRA (their 10 bucks offer). It is a bit slow on my 256mb linode though.

I can't give much away but I'm working on an Atlassian team making some big changes to our hosted products:

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

If everything goes to plan, there'll be an announcement at Atlassian Summit (in June) that you might be interested in:

http://summit.atlassian.com/

AgileZen (http://agilezen.com)

I use http://www.codespaces.com, but I'm biased because I know the guy that founded and still runs it. It was the first app I saw that was fully written in Ext-js (this was pre 1.0) and back in 2007 or whenever it was that he wrote it it blew me away. It does all kinds of neat things, but mostly it's good because it's accessible to non-technical people -- lots of classic interface paradigms.

I also voted for Trac, because that's my go-to bug tracker for corporate projects that get checked in to a private SVN server.

We use Indefero http://www.indefero.net It is both offered as free software (GPL) and you have hosting options. A bit like WordPress.

You should add an option to differntiate 'some other tracker' from 'a tracker I wrote myself'. I'd be interested to see how many hand-rolled solutions there are out there.

Assembla. Lots of project management tools and source control all wrapped into one service. Theres a few things I'd change but it gets the job done.

For my small projects, plain-text OrgMode file most of the time is sufficient ;). At work I used Redmine, and I find it to be a really nice tool.

TrackJumper - simplest tracker I've found http://trackjumper.com/

Thanks for the mention. I'm about to release a new UI based on initial customer feedback (no new features, though - just more intuitive/prettier). Should be deployed in a week or two.

I voted lighthouse because that's what we use at Nowmov but for personal projects I use [Bugs Everywhere](http://bugseverywhere.org) It's a simple command line tool that syncs to a file in your software's repo. Simple + Portable = LOVE.

I've used Flyspray <http://flyspray.org/>; on a couple of projects with two other team members and it has worked well. It is php+mysql/postgresql, so it installs almost anywhere.

We use Bugzilla, but the non-techs in the company think it's too techy. Although it can get daunting with so many options, and I've even seen it used as a trouble ticketing system(!), it serves our purpose (bug tracking, of course).

ClearQuest along with ClearCase for version control.

NOTE: I ""SUPER-HATE"" it. But I am helpless. :(

i smell an enterprize environment :)

You smell it right matie! ;)

I've got some stats on my site wappalyzer.com, I'll look into adding the ones you mentioned and aren't listed:

http://wappalyzer.com/stats/cat/Issue%20trackers

At ProjectLocker (http://www.projectlocker.com) we use Trac for issue tracking for ourselves and as a hosted service. By extension, so do our customers :).

Lighthouse along with github's service hook has been great for me so far on a personal project.

On a related note, why can't we have public bug tracking on a private repo on github? This was the primary reason I went with Lighthouse.

Mantis. Once I minimised most of the fields it looks fine. The easy of deployment is a point in its favour as well.

What I really want is a cut down JIRA written in PHP (for ease of deployment). If might just write it one day.

While I favor Redmine at the moment, I used Roundup in a previous job and didn't hate it. It does a pretty good job of balancing simplicity and features.

The only other place I've noticed Roundup being used is for Python.

Lighthouse FTW! Its lightweight, simple, easy for non-technical team members to use to report issues, bugs, suggestions, etc. and the tag-based classification/search system is inspired. Love it!

Email -> stop development and fix -> reply to email archive and hope you don't hear about this issue again. But looking into implementing FogBugz (or whatever recommendations come up)

Gmail. Better than any bug tracker I've used aside from Pivotal.

+1 on that. I also got into Taskforce recently and am really liking it.

a plain text TODO file within the repository of each project, together with a plain text TODO file in my dropbox that gets synced everywhere. Works very well.

I really like this kind of solution for smaller projects, where a proper bug tracker is excessive overhead. Keep everything in the repo and it's much simpler to maintain.

Do you have a formal-ish system for this? Notice issue -> TODO -> write unit test -> fix issue -> cut + paste to ChangeLog?

We work in a 3 person team max, and run a project management tool/CRM next to it (apollo) so there is no need to do communication via special protocols. We tried a bunch of them and it just doesn't work for small teams. We live in GIT anyway, so a todo.txt is a really good solution.

It's mostly: email to say bugs need fixing -> bugs get fixed -> fix gets committed and the bug removed from the todo -> email back that it's fixed.

It mostly concerns visual (html/css/templating) bugs or small js bugs that don't have unit tests/

Grooveshark uses Bugzilla. There are things about it we all absolutely hate, but it does the job, which is more than I can say for anything else we've tried.

I use google spreadsheets to manage bugs, some pretty cool things can be done with color formatting and rules.

SD (Simple Defects) is more choice when I can. Distributed and works pretty well, and not too complex.

The Bug Genie: http://www.thebuggenie.com/

FogBugz with some clients depending on size, timeframe, etc. Nothing other than email with others.

We don't have bugs. Any defects are put into the current sprint and fixed within the hour.

What? No RT?

This struck me as odd as well. In our RT, we have ~ 200,000 "ad hoc" issues tracked to date by a team distributed across three continents and for thousands of customers, with no complaints.

Request Tracker by Best Practical is an amazingly flexible product, straightforward, yet easily tweaked into whatever workflow most any organization could need.

That said, we use TRAC for software project management and project-based issue tracking.

We use Flow App: http://getflow.com

http://pbworks.com (hosted wiki)

redmine users may be interested in the recent fork: http://www.chiliproject.org

the forking devs are going to be comitting some more radical changes it seems

Looking forward to that. In the meanwhile I find Redmine absolutely wonderful after I've configured it after our needs and process.

unfuddle

mtrack

a clone of trac done in php With support for multiple projects. Mercurial and Subversion

http://mtrack.wezfurlong.org/

Redmine is simply the best

IssueTrackerProduct

producteev

vi BUGS.txt

for as long as reasonable

thought that file's length should be 0 (for as long as reasonable, and even then, should only be due to bizarre/unreproduceable platform causes, not a direct flaw in your application source)

yes this system works best if 1 programmer. but 1 programmer is the ideal team size, if you can achieve it for a particular project