I'm surprised GitHub is by far #1. I wonder if it's familiarity rather than preference. Github's minimal approach of using labels for everything is like Gmail's tags over folders.
I wish GitHub had a "This bug affects me" or +1 button so the comment history stays clean of "me too" responses.
I've used a ton of bugtrackers, GitHub is the only one I've been able to hand to a non-techy client so they can create bugs.
This has been a huge frustration for me when it comes to bug tracking. I have multiple clients who just aren't technical people and when they see the wall of options that bugzilla and mantis offer it causes them to give up and email me directly. I even tried vbulletin for awhile, but that had its own problems.
GitHub (once you get past the signup) is perfect in this regard. Just open a ticket and then comment on it.
I wish GitHub had more in regards to bug tracking, for example being able to create states (open, in progress, closed) as well as labels.
These days I'm sure there are comparable solutions but having the issue system through github means one less service I need to track, which is also nice (client gets code, client has issue tracking, done).
With all that said I wouldn't use github issue tracking for complex multi-stage applications where the environment is an important factor in the problem.
GitHub is the only one I've been able to hand to a non-techy client so they can create bugs.
I was using Pivotal Tracker a few years ago for a large-ish project, and really wanted the client to use it.
It didn't strike me as terribly hard for reasonably bright people, but I under-estimated habit and the degree of resentment some members on the client team had about their pet project being changed.
Assorted attempts at education (I made a really nice screencast!) failed; I was still getting e-mail with Excel or Word docs attached.
We finally came to an understanding and started using Google Docs.
BTW, Github issues is not so bad. A key feature for me for any bug tracker is a Web API, something I can talk to using a command-line tool.
I wrote such a thing for Pivotal Tracker (my Pivotal Slacker Ruby script, now abandoned) and later hacked up a program called GHissues to pull items from Github.
I also feel such a questionaire is mostly driven by experience not by preference. Not many people learn to know more then 2 or 3 trackers in their career.
I question whether people need to learn more than 2 or 3 trackers over a career. Bug tracking tools are remarkably well developed. Once you find something that works, start battering bigger fish.
Having not used that many, I like GitHub's over BitBucket's because it has tagging and milestones, which are vastly more useful than some preset priority and type fields. GitHub's is a lot closer to how my brain works.
It just seems funny to me that a company that also makes a bug tracking system has a really bad one coupled with it's version control hosting. It makes some sense, but it bugs me.
Piece of paper taped to side of monitor, with badly written reference to a page in someone else's daybook, including cryptic calculations that are actually not at all related and enough circular rings from my tea mug to create a sort of mutant Olympics logo.
I voted for Google Code because even if it's not the most full-featured tracker, it's the one with which I get non-techie users to actually report issues.
There are no complicated required fields, just name and description, and it mostly doesn't require registration or login because most people are already logged into some Google service. This means that users only need to write their problem and press a button, so they actually do it instead of being scared away by the interface, which is what happened to me with other trackers.
I'm a PM in digital advertising and normally I wouldn't work with code - I largely build one-offs with vendors so issues/bugs and deliverables - Sifter is by far the best I've used. It does one thing and it does it really really well, has a negligible learning curve, and looks pretty - oh, and it's cheap.
YouTrack (http://www.jetbrains.com/youtrack/index.jsp) is my favourite out of everything I've ever seriously used. Physical cards stuck to the wall also works well for small, co-located teams.
The important things are that someone needs to put a decent amount of time into managing the bug list, and you need to be actually willing to devote appropriate resources to fixing them (or better still, eliminating the root causes). If those aren't present you'll just end up with an unmanageable dumping ground regardless of where it lives.
Hi, I'm Joe Stump CEO/founder of Sprint.ly. Totally biased opinion here, but I'd like to add Sprint.ly to the list. We built Sprint.ly specifically to encourage/engage "the rest of the business". If you're looking for a super technical tool, we're not that, but if you need a tool to get business users engaged and on the same page we might be worth a look.
+1 for sprintly, been using it for almost a year at Moveline. business people know exactly what to do when a bug comes in, and can accept/reject, comment, screenshot, etc. when a Dev marks it as complete
Do most HN readers have the impression that polls like this are made by some some all-knowing, perfectly fair, professional editor who only puts up well researched, carefully thought out, scientific and objective options in their polls?
It might surprise you, but I'm just another HN reader just like yourself.
I woke up today and thought, "Hey, I'd like to know what other HN readers consider good bugtrackers. Why don't I put up a poll?"
I remembered the names of a few of bugtrackers off the top of my head, but just having a few would make for a pretty lame poll. So I pulled up the wikipedia article on the comparison of bug trackers. It had a million listed, so I thought that might make for too long a poll. So I chose the ones I personally heard of, and added an "Other" category for the rest.
That's fair, and you're right this is a community forum where we learn from each other. For example, just yesterday I learned about akka for the first time even though I've been writing event-driven Java and searching google for it (or something like it) for years.
One reason why I found JIRA's omission so surprising is it's widely used by companies that have different departments or roles. It typically becomes the default choice when a company gets large enough to have a PM. Github doesn't scale with roles (yet). JIRA is so common, I'm curious what part of our industry you hang out in to know what growth Atlassian still has :) You probably use tools everyday that I'm also unfamiliar with -- we simply have different experiences.
Disclaimer: Atlassian is about to go public... so I've been doing my research on whether to buy.
Makes me wonder how some polls would turn out if options had both upvote and downvote buttons. I have used every bug tracker in this poll, as well as a few more (redmine, Assembla, GNATS, OTRS, Roundup, ikiwiki, various custom internal tools), and Jira was by far the second worst (behind one of the custom one-offs).
Depends on the situation, and how it is being used.
It does take a serious amount of time to set up, but it is so flexible that if you take the time, you will never leave it.
It also integrates into everything, and has a very verbose API, so if it doesnt do what you want you can extend it.
I'm surprised. Our company evaluated several bugtrackers and jira was by far the best. We're still using it two years later and still quite happy with it.
Jira seems like the kind of system sold to managers and then inflicted on engineers. Managers love it because, like Excel, it's the kind of tool that lets you easily generate reports and enforce workflows without programming. (And in fairness, that can be a major selling point.) However, from an engineering perspective, it makes simple tasks clunky; it turns what should be 1-2 step processes into 5-step processes, and otherwise manages to be the antithesis of a lightweight tracking tool. The phrase "makes the difficult things easy and the easy things difficult" (or "painful") comes to mind. In particular, the tasks it makes difficult/painful are the ones that engineers find themselves doing 30 times a day.
And for agile/scrum, Greenhopper is absurdly bad, for the same reason.
I didn't have a very high opinion of Jira until about version 4. In recent updates, a lot of the clunkiness of older versions seems to have been cleaned up.
Until recently, my team was the only developer group in our company using an issue tracker. Management have decided that every team must now use an issue tracker and that tracker must be HP Quality Center. They're even paying a temp to manually migrate all our Jira issues into QC. We managed to win the battle for Git over IBM Rational ClearCase for a version control system but this kind of thing makes me think it's about time to find a new job.
Being one of the engineers actually using it on a daily basis, all I can say is: I don't know why you have the impression that that is the way you need to use the product in practice, but that certainly doesn't match our experience. We hardly use the workflow and reporting components and you really don't need to, to make good use of it. And we're quite happy with Greenhopper as well. It's far from perfect, but Greenhopper is useful to us, where all other project planner / issue tracker crossovers were found to be borderline useless for our use cases.
Was thinking the same exact thing except if you look at the ones listed, it looks like this is a list of free trackers. Maybe the OP should've added that important tidbit in the title.
We use redmine internally, but I find myself preferring Github for issues. The interface is much simpler and easier to use. Redmine, on the other hand has 10-15 fields for every issue. It may help with very large projects but most of it is never used for small-sized projects.
I've been using Phabricator a lot recently, and it's ace. We started using it because we wanted to start doing code review, and the task tracking came along 'for free'. It's nice & lightweight (in terms of UI), is usable from the commandline via the arcanist tool, and integrates well with the other Phabricator tools.
Downsides? The website's sense of humour is irritating if it doesn't click with you. You have to host it yourself, which can be about a morning of setup. The documentation can be a little bit sparse. But it's the first bug tracking/developer workflow tool I've used that I've actually liked. And I like it a lot.
(I say this in jest, but only a little.) Think about it...
I know so many programmers who get lazy because they have such good debugging tools (Let me just slam something out there and let the debugger catch it.) I hate this.
If we developers would slow down and think a little more about what we're building, we may find a dramatically decreased need for debugging.
Variable local or global? Right variable name? Should that be a function? How much am I repeating myself? How should the data be structured for its intended uses? What's the best way to handle recursion? Where might memory leak? Where's the best place to do this? Which is the best technology for this need? And most of all: Will the next programmer be able to read this and tell what it's doing before they break it?
"Slow down"? Please try to convince the typical manager, executive, or VC that calls the shots to slow down.
Death marches by overworked, sleep deprived, and understaffed development teams are the norm in the industry. It's a wonder that most products aren't even more bug-riddled than they already are.
I would love to live in a world where every developer was competent if not brilliant, and had all the time, training, and motivation in the world to write nothing but perfect code at his leisure.
Bug trackers are more fully featured project management tools these days. We use Fog Bugz and some of our non-coders are using it to record what they're working on/accomplishing.
Did you misread "debugger" instead of "bug tracker"? Your comment doesn't make any sense to me in the current context.
If you are really against "bug tracker". I don't really understand as they are often mainly used to report new needs, requirement and enhancement rather than crash due to poor coding practices.
Bugs often represent mistakes and miscommunication in areas that the programmer has no input in. If the goal of the project was to draw a circle there is still room for error. The PM might have wanted a red circle with a fade in render.
This is fine advice. Had the OP thought it through, they would have made this thread about "ticket tracker" or "issue tracker" and then your comments about debugging would be more obviously non sequitur.
For client projects I'm a big fan of Lighthouse (https://lighthouseapp.com/). It has a great balance of advanced features and ease of use for non-techies.
* Tickets can be created and updated via email
* Using the GitHub service hook, you can tag commit messages so that they appear as comments on a ticket as well as change the state of the ticket (For example: "Refactor widget behaviour [#123 state:resolved]")
* You can setup milestones (with or without a due date) and assign tickets to them
* Bulk editing of tickets
* Markdown in ticket description and comment fields
* You can easily create "buckets" of tickets based on search terms and filters
* Bugsnag and Airbrake can be configured to automatically create tickets for new exceptions in your app
* Probably some other great features that I've forgotten to mention
I just want to mention that Trac development has picked up steam over the last couple of years. If it has been a while since you've tried it, you might give it a fresh look sometime.
I am a big fan of TFS particularly since it allows for the feedback client to be used to get direct feedback (Video, Audio, Screenshots etc) into it from selected users in a very unintimidating way.
we use https://trello.com/
We build buckets called raw feedback, todo, and urgent. Drag issues into the appropriate bucket. When they're done, devs move to "please test" and from there they then go to done when the issue has been validated. Simple, free, screenshots, videos, upload from iOS. Tag people to issues. Works for us. No timeline or "63% done", but we don't need that.
How do you use Asana for bug-tracking? We're considering doing so too (We already use Asana for task management, etc), and would love some pointers from someone who's already done so.
They have a guide (http://asana.com/guide/videos/bug-tracking) in their help pages about it. I use it too, but not their way. I don’t have a “Bugs” project. I have a “Bug” tag that set to bugs in different projects. If you already have a projects structure that works for you and can hold issues like bugs, this might work better.
We use asana as a bug-tracker at https://circleci.com. Its pretty good, and doesn't get in your way, but we can't really integrate it into our workflow. They don't have Hipchat integration, and their API isn't full enough to set it up ourselves with Zapier.Their support also isn't very good, they replied to the problem with basically "dont care".
I wish GitHub had a "This bug affects me" or +1 button so the comment history stays clean of "me too" responses.