I think the author is confused between "tracking bugs" and "a bug tracking system". The former is a social process, and something that all projects do on some level. The latter is a piece of software, which may or may not help the project to do the former. The author even discovered the evidence for this, but missed the meaning: git's bug work happens on the mailing list, while mono's goes on in the tracker.
Don't confuse software with problems. That's how we get bad software.
Does anybody else feel like a bug tracker has a negative impact on community and coding enjoyment? I don't think I'm on-board with this argument, or his assertion that significantly more people are using Mono than git.
I find bug trackers satisfying, generally, but then again, I make money from my software--it's almost entirely Open Source, but nonetheless, my prosperity depends on the software being great. Anyway, closing out bugs is an enjoyable part of the job, and I simply can't keep up with things that come in via email or in the forums. I think there's a volume-of-issues-to-developers mismatch between my projects (which have two or three developers, tops, plus a few occasional contributors) and something like git (which has a primary maintainer, a few regular developers, and dozens of occasional contributors).
I agree that ticket systems and bug trackers cause some headaches for developers. When you have a problem on the shelf, you're compelled not to think about other things, which may be either nicer, or more important.
But there's a lot of value in being able to track things. You don't need a task list loading up your head in the same way, and for a distributed project it's vital for communication purposes.
One suggestion might be to have two lists: the central repository for bugs, which get voted on (and the votes diminish over time, like a hacker news of bugs/issues/enhancements). And then for each person, a 'shopping list'.
The idea is you don't want to take on too many tickets, because after a while, they go 'bad', like groceries -- they just stay in our fridge and we don't finish them.
You also want to be able to judge impact versus the time you think it will take, so you optimize for that -- something like the number of votes divided by the number of hours you think it will take you will give you the priority.
Heck, this is actually starting to be a good idea. Maybe I should throw up a little HN clone for tracking, and see how it goes.
You're not alone. I was talking with someone from Google who works on the Gmail support team, and has an interest in user-to-user support, in general, the other day, and she was asking me about how hard it would be to convert the newly Open Source reddit into a ticket tracker.
I think it underestimates the importance of other aspects of a tracker--but my lack of confidence in the idea may be based on my own prejudices based on years of working with traditional issue trackers. I expect to receive an email when a new ticket is filed, so we'd need to add notifications. I'm missing emailed ticket submission (I miss it in my current tracker, and will be moving to something else because of this lack), so you'd need to add email ticket submission. Assignments are a core part of any ticket tracker--you need to be able to take ownership of an issue so that others don't spend time on it unnecessarily (though others should be able to follow it).
But, I do think several things would shake out of the model that are hard to do now:
Priority. The less someone knows the more important they believe their issue is. So, it's basically a no-op field in most trackers I've ever used. The developers might use them to good effect, and a few advanced users. But since greater than 50% of priorities are set incorrectly, it's a useless field for sorting (and my current tracker doesn't let me remove it from the form, as it is the primary sort key!). Since everyone gets a vote, priority as "hotness" would be a great improvement. But, it assumes your whole community is looking at the tracker, which is extremely unlikely.
Discussions. People rarely talk on issue trackers because the conversation tools are weak--the focus is never on making it work really well for discussions. reddit/HN have great threaded conversations, and you can vote on what's relevant and accurate. I would very much like better discussions in my tickets.
But, I think it would require something like a total conversion to this sort of forum as the entirety of your forums/mailing list/bugs system. Which might be a good idea for someone starting from scratch. If you have sub-reddit style categories, with one for tickets, that'd be a pretty effective system, I think. Though you can't currently "close" a thread on HN or reddit, and call it "fixed"...so that'd be something to add.
Anyway, I'd love to see how an implementation like this worked out in a reasonably large community. It might be something we'd want to try on our Open Source community site (our commercial site is already too set in its ways and customers hate change). But the Open Source site needs a bit of a refresh...it currently uses SourceForge for its tickets, which kinda sucks.
I didn't, at least not until I started using Atlassian Jira to track bugs in our open source projects. What a difference a nice, organized system can make!
If anyone is dissatisfied with their current bug tracking systems I highly recommend Jira - Atlassian gives out free licenses to non-profit and open source organizations; and it's a really great product.
Perhaps the reason Mono has no traffic on their mailing list is because Mono as a piece of software kind of sucks, at least in my opinion. Then again my perception might just be colored by my experience with using OpenEmbedded which I've come to dislike greatly and coincidentally also uses Mono.
I think more charitably it's because mono is in some senses a write-only project. It's a collection of people who are essentially writing software to an external spec. Except for design details at the very core (probably handled via private mail between the half dozen people involved), there really isn't any need for elaborate collaboration on development details. And futures issues (the "how do I do this?" kind of discussion) are all directed at microsoft anyway, not mono.
I guess I'd have expected it to be a little sterile. Certainly it isn't something I'm dying to work on.
It seems I've miss spoke. I was actually thinking of Monotone not Mono ( http://monotone.ca/ ) I was just confused because I assumed the author was comparing version control systems. But they were actually just comparing open source projects in general. I have no opinion on Mono but Monotone sucks.
The point is that the developers of git don't use any bug tracker. It doesn't matter how much bug tracking software is available if they refuse to use it. Honestly I'm not surprised; I don't think Linus uses any of the Linux bug trackers either.
Ah. I got the impression that people were complaining that the rest of us can't leverage existing tools.
Git's simplicity and pile-of-tools approach, along with daily use of the tool and prodigious debug output, strike me as exactly the sorts of things that minimize the need for bug tracking. If there's a bug in my own statistical code, for example, I usually know about it from the debug output. If that works for the Git developers, fucking awesome.
However, just because Linus doesn't use a bug tracker, doesn't mean that the big shops (RedHat for example) don't pick up the slack. I think Linus is a flawed example ;-)
Don't confuse software with problems. That's how we get bad software.