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.<p>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.<p>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.<p>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.<p>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 (<a href="http://ditz.rubyforge.org/" rel="nofollow">http://ditz.rubyforge.org/</a>).<p>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 <i>before</i> bug tracking systems:<p>XML Parsing Error: not well-formed
Location: <a href="http://www.intertwingly.net/blog/2008/07/18/Life-after-Bug-Tracking-Systems" rel="nofollow">http://www.intertwingly.net/blog/2008/07/18/Life-after-Bug-T...</a>
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);}}
----------------------------------------------------------------------------------------------------^<p>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.