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.
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.
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
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).
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.
[+] [-] wting|12 years ago|reply
I wish GitHub had a "This bug affects me" or +1 button so the comment history stays clean of "me too" responses.
[+] [-] columbo|12 years ago|reply
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.
[+] [-] erikb|12 years ago|reply
[+] [-] dkuntz2|12 years ago|reply
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.
[+] [-] EliRivers|12 years ago|reply
[+] [-] Al-Khwarizmi|12 years ago|reply
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.
[+] [-] pero|12 years ago|reply
https://sifterapp.com/
Not that there's a reason why it wouldn't be used with code, just a disclaimer.
[+] [-] pcowans|12 years ago|reply
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.
[+] [-] passwordless|12 years ago|reply
[+] [-] frederickcook|12 years ago|reply
[+] [-] lukeck|12 years ago|reply
[+] [-] Yhippa|12 years ago|reply
[+] [-] JoshTriplett|12 years ago|reply
[+] [-] smaili|12 years ago|reply
[+] [-] captn3m0|12 years ago|reply
[+] [-] creature|12 years ago|reply
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.
[+] [-] jevinskie|12 years ago|reply
[+] [-] edw519|12 years ago|reply
(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. Plan more. Think deeper. Debug less.
[+] [-] gnosis|12 years ago|reply
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.
If you know of a way to this world, I'm all ears.
[+] [-] nilkn|12 years ago|reply
[+] [-] Rexxar|12 years ago|reply
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.
[+] [-] serichsen|12 years ago|reply
[+] [-] clubhi|12 years ago|reply
[+] [-] quadrangle|12 years ago|reply
[+] [-] beaumartinez|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] sstarr|12 years ago|reply
* 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
[+] [-] varsketiz|12 years ago|reply
[+] [-] rch|12 years ago|reply
[+] [-] mariocesar|12 years ago|reply
I'm surprised as many others that Jira is not on the list
[+] [-] dkuntz2|12 years ago|reply
[+] [-] esalman|12 years ago|reply
[+] [-] tedsuo|12 years ago|reply
[+] [-] st3fan|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] dav-id|12 years ago|reply
[+] [-] burgreblast|12 years ago|reply