Make sure the bug tracker doesn’t turn into a discussion forum. Although it is important to maintain a human presence in the bug tracker, it is not fundamentally suited to real-time discussion. Think of it rather as an archiver, a way to organize facts and references to other discussions, primarily those that take place on mailing lists.
There are two reasons to make this distinction. First, the bug tracker is more cumbersome to use than the mailing lists (or than real-time chat forums, for that matter). This is not because bug trackers have bad user interface design, it’s just that their interfaces were designed for capturing and presenting discrete states, not free-flowing discussions. Second, not everyone who should be involved in discussing a given issue is necessarily watching the bug tracker. Part of good issue management is to make sure each issue is brought to the right peoples’ attention, rather than requiring every developer to monitor all issues.
— Karl Fogel, Producing Open Source Software
Hells, yes.
I’ve re-read this five times and I still think it should say “no discussions in mailing lists” rather than “no discussions in bug trackers”.
I’m going to address my impression of the points made one-by-one and I’d really appreciate if someone could explain where I’ve gone off the rails:
1. “not fundamentally suited to real-time discussion”, “more cumbersome to use”, : The only difference I see between a bug tracker and a mailing list is that mailing lists take much more effort to filter down to just the threads you care about and, because they’re centered around e-mail as their primary mode of interaction, they tend to be designed with crippled interfaces that feel more at home in the 1990s.
(Sort of like how, compared to something like Identi.ca, Twitter’s web UI has always lagged behind horribly when it comes to comfort and utility because its designers created it as a listserv for SMS and bolted on web functionality after the fact)
Sure, you can have a bug tracker which doesn’t support reply-by-email, but I find it much more likely to have a mailing list that has several subtle but extremely irritating mismatches between what you need and what your e-mail client delivers.
2. “designed for capturing and presenting discrete states, not free-flowing discussions”: I can see the difference between IRC but, again, I see no difference between a bug tracker and a mailing list of equivalent quality on this point.
3. “Second, not everyone who should be involved in discussing a given issue is necessarily watching the bug tracker.”: Keep in mind that not everyone is willing to use mailing lists either. I’d follow a bug any day, but I’m not going to follow a mailing list.
Planet Mozilla is the only firehose I follow and even with it being nearly 100% relevant (and with a clear, intuitive mechanism for subscribe/unsubscribe), rather than nearly 100% irrelevant (and with a consistent but easily forgotten mechanism for subscribe/unsubscribe), I’m still considering unsubscribing.
The only reason I can really see for doing discussion OUTSIDE the bug tracker is if the discussion is focused on things which aren’t focusing around problems or proposals and resolutions. (eg. “State of the project” meetings, “off-topic” discussion, etc.)
For me, at least, the benefit of mailing lists over bug trackers is that it _is_ opt out, rather than opt in, from the point of the initial discussion starer. There is no way I would be able to function being a global watcher on Mozilla; I can’t point to a bug report and say “I never want to see mail about this bug again”. (I can say, however, “I want to opt-in to seeing updates to this bug” once it’s filed, or “I want to see everything in this component”.) On the other hand, if I don’t watch everything, I will miss important discussion in bugs I never knew about, and things like bug 675221 – which would have mattered a lot if I were working on Songbird – would have hit me blindsided.
With mailing lists (or at least, newgroups, which is my preferred format for those, though it can probably look the same), I find it relatively trivial to ignore things – there’s this giant HARICA ssl cert inclusion thread that I’m ignoring at the moment, for example. That still enables me to see new things pop up.
(It’s been interesting to see how many of these POSS things apply so well to Mozilla, even though I suspect how I’m applying them differs from somebody who works on Mozilla all day and don’t feel as excluded.)
Stephan: as others have said, the “opt-out” nature of mailing list discussions is a key feature. If you aren’t following the Mozilla discussion forums related to your area of the project, you need to be. You can follow them either as newsgroups, mailing lists or Google Groups – whatever UI most floats your boat.
Also, threading and “mark as read” are key features not present in (at least our) bug tracking systems, but essential for discussion.
Gerv
All good points.
I suppose the important distinction to make is that, for areas where opt-out is important, a mailing list, on its own, could still be considered inferior to a bug tracker, but a mailing list with an NNTP bridge or well-configured (nowhere near default) e-mail client is far superior.
Opt-in vs. opt-out aside, my biggest issues with mailing lists generally ARE related to them not being offered via GMane’s NNTP bridge.