Avery Pennarun: The git developers don’t track bugs. If you find a bug, you can write about it on the mailing list. You might get flamed. And then probably someone will ask you to fix it yourself and send in a patch. This is unlike almost all other open source projects.
Sometimes ideas take time to percolate. When I first saw Avery’s post, it didn’t quite sink in.
When I started playing with hg, I noticed that I was applying a different style of development than I previously had done. One that I felt more comfortable with. And I thought again about Avery’s post.
And when I came across Chad Wooley’s comment: But using your SCM as a messaging platform? Come on, that’s taking the social networking thing too far... I pray that I never see the official Twitter channel for an open source project I care about, because I ain’t going there...; I once again thought about Avery’s post.
It now occurs to me that not all projects need bug tracking systems. In fact, for some projects, not having a bug tracking system may very well be a feature. In particular, if the bug tracking system on your project is the place where feedback goes to die, you might be better served not having one. But if you do decide to go this way, you would be well served to consider one of the various DVCS systems out there, like bzr, hg, and git.
I disabled the bug tracking features of RubyForge for most of my projects. I’d rather have people use GitHub or email to provide patches and feedback. Bug tracking systems are where feedback goes to die on my projects. Especially because RubyForge is really weird about when it decides to send me an email about an issue. Many times I just don’t know that someone’s posted a bug.
How to tell when your bug reporting system is at its limits
How to tell when your bug reporting system is at its limits There reaches a certain point in the life of many projects, especially open source projects, when your bug reporting system just doesn’t work any more. By ‘doesn’t work’ I don’t mean that...
I found this blog entry by Sam Ruby titled Life After Bug Tracking Systems, interesting. Apparently other BTSs are frowned upon in some FOSS circles, Git for example, and it does make a point about the value proposition of BTSs in open source...
I think bugs shouldn’t be created by anyone. Bug should be reported via email, discussed to find out whether it’s a bug at all. And then it should be just fixed or information about the bug should be saved in bug tracker by projects developer - with all necessary details. I believe it’s the only way to make a bug tracker really work.