
Weird things about git, #2: no bug tracking system - dmoney
http://alumnit.ca/~apenwarr/log/?m=200806#28
======
ajross
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.

------
SwellJoe
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).

~~~
DaniFong
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.

~~~
SwellJoe
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.

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

~~~
ajross
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.

~~~
pmorici
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.

------
apathy
False. Trac has a git plugin. Ergo, Git has an excellent bug tracker available
for anyone who wants to use it.

Or there's Lighthouse.

~~~
wmf
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.

~~~
apathy
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 ;-)

