I’ve noted that a common source of disagreement and even exit within open source communities is the handling of software bugs. In my experiences in the open standards communities the ways in which issues are represented with respect to their standing of consensus or dissension is affected by the processes, culture, and media of discourse (e.g. bugzilla, IRC, e-mail, Wiki, etc.).
Consequently, I’m interested in the extent to which communications media, issue tracking and bug tracking software reflect cultural values of how a community should come to agreement, or even to productively disagree. For example, culturally, can a developer close a bug report simply because he does not think it is of a priority? Technically, does the software permit the developer to specify an appropriate status for an issue, or reassign it to a more appropriate owner?
Can you point me to examples of disputes arising over the categorization or responsibility of bugs? The implementation of new tools, categories, or processes that are hoped to mitigate such problems? If so, please let me know!
Joseph Reagle on 2004-04-19
Thanks Sean. I looked at roundup a while ago and think I liked it because it also offered an email list interface – if I remember correctly. A draft of the paper on bug tracking is at:
Sean Reifschneider on 2004-04-18
I’ve recently been doing some work on trying to get a tool for helping us at tummy.com, ltd. track tasks that we’re working on. We’ve tried several systems in the past, and had pretty bad luck with them. Things like DCL were tried, but just didn’t work well for us.
Recently, I’ve been testing out Roundup. I’ve been using it extensively for about a week now, and have been pretty happy with it.
Note that we’re basically wanting kind of a “smarter todo” list.
The thing about roundup is that it’s kind of a framework oriented towards building issue tracking systems. It looks like it’s flexible enough that it could be used to build many different kinds of web-based systems, though.
The first time I looked at Roundup, I saw that there was “some assembly required”, and backed away. This time I realized that it’s actually kind of what I want. If it doesn’t work as I’d like, it should be relatively easy to change, in theory. Since it’s written in Python, it should also be something I’d be very comfortable modifying.
Anyway, I’ve done extensive modifications to how it works, trying to fit it more closely into how I think our task tracking/todo system needs to work. It’s still got a list of a half dozen things I want to add or change, but in general it’s working extremely well for me.
I’ve modified it so that it’s very light weight, an issue can be created by filling in just a single field. It also has some ideas of task parents/children and also of dependencies. If one task depends on another task, you won’t see the other task on your list until the first one is completed. Once you close a task, any tasks it was blocking get activated so you see them.
I don’t know that this message is going to help you, but I thought it might at least have some interest for you.
I plan to write up more on Roundup on my journal, listed above, over the next week. You may want to try there for more information about my experiences.