
Sam Ruby: Life after Bug Tracking Systems - arjunb
http://www.intertwingly.net/blog/2008/07/18/Life-after-Bug-Tracking-Systems
======
pieter
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.

------
jballanc
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.

------
steve_butler
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...](http://www.intertwingly.net/blog/2008/07/18/Life-after-Bug-Tracking-
Systems) 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.

------
Kaizyn
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.

~~~
jrockway
_telling the users to fix the bug themselves and send in a patch will never
ever fly_

Did someone say it would? We are talking about open source projects here.

