Sam Ruby: Life after Bug Tracking Systems

Having a bugtracker or not is a tough decision. You have to keep your ways of communicating limited to a few channels. You _will_ need to address the social aspect of your project in one way or another. It's probably either a mailinglist or a bugtracker. Having both means one of them is probably heavily underused.

What you see a lot with projects is that everything happens through a bugzilla. New features, feature requests, bugs are posted there, some invalid because the user doesn't understand a program. The 'bugtracker' aspect forces you to put your message in a certain style.

With mailinglists like git@vger you get a mixture of posts. Some are from newbies that don't understand the system, some are comments on the current system and most of them are patches or status updates. Having a mailinglist allows a user more freedom in the form in which he wants to communicate, which lowers the barrier. You also get a nice mixture of users and developers on the same channel, by which you get better feedback.

The flipside of that is that you don't have any overview. You'll have to manage bugs yourself. If you want something fixed, you'll either have to make a patch yourself, get somebody else interested or just keep bringing the bug to attention.

Now compare this to a bugtracker. You post a bug there and nobody will look at it until you make a patch yourself, get somebody else interested or keep bringing the bug to attention. See the difference? Exactly.

As I read this I immediately thought of Ditz (http://ditz.rubyforge.org/).

The idea behind Ditz is that, if your project has no centralized "truth", then a bug tracker that represents centralized "truth" doesn't make much sense. Instead, Ditz keeps track of your bugs right there in your Git repo, so when you check out that 3 month old experimental branch, all of the bugs that still existed on it are right there for you to read about.

I think this represents life before bug tracking systems:

XML Parsing Error: not well-formed Location: http://www.intertwingly.net/blog/2008/07/18/Life-after-Bug-T... Line Number 42, Column 101:String.fromCharCode(0xdc00+n%0x400);}else{return '&#'+ncr+';'}});for(var i=body.length-1;i>0;i--){if(cp1252[body.charCodeAt(i)]){body=body.substr(0,i)+'&#'+cp1252[body.charCodeAt(i)]+';'+body.substr(i+1);}} ----------------------------------------------------------------------------------------------------^

But seriously, I'm curious what he has to say. In lots of companies the bug tracking overhead overwhelms the actual work done.

Bugtracking doesn't matter if you aren't working for a profit-seeking enterprise or other enterprises that pay people to write software for them. For these situations, telling the users to fix the bug themselves and send in a patch will never ever fly.