Monday, May 18, 2009

soap-opera bugs

Elliot wrote something interesting about dealing with contentious bugs: in this case, whether the new Canonical service UbuntuOne is a unfair and/or confusing use of the "Ubuntu" name. (The particular issue is being thrashed extensively so I'd rather talk about the meta-issue of bug trackers.)

Ubuntu and other free software projects are going to get some things that look like bugs but that are much emotionally hotter than regular bugs: typically though not always here the disagreement is higher up the stack towards a question of architecture, goals or politics than just how to fix the bug. Ubuntu Bug 1 is a similar case, though here the problems arise more from enthusiasm than disagreement. (In the case of bug 1 you can see that Launchpad currently allows for more failures than just many comments: two screens full of BugTasks asking for it to be fixed in random places.)

These things show patterns of: excessive numbers of comments, tug-of-war over the bug status, people piling on to show their support for the issue rather than to add new information, ... As Elliot says:

It's frustrating that as one of the project leaders I don't seem to be given the respect or right to close a bug on my own project. For example, I respect Bradley very much and am not remarking at all on the content of his comment (he certainly speaks from an informed perspective and it would be foolish to ignore his input), I don't think he should override my decision to close the bug. [...]

I understand that it's healthy and good for people to offer comments and criticism on the stated roadmap of the project, or disagree about whether we should take action on any bug, design decision, etc. [...]

But, I want to use the bug tracker to track ongoing/pending work in the Ubuntu One project, not as the place where debates happen over whether Canonical is doing the right thing. If people want to write commentary on big picture strategy, it would be much more appropriate in a blog, not in bug reports.

What can be done?

I think ultimately this is a social problem and technical solutions are limited. For example we could technically lock this bug, but that might just redirect people into opening new dupes.

Perhaps Elliot is doing the best that's possible in saying that he's willing to have the conversation, he just doesn't want to have it right here.

There is a bug (heh) 73122: need strategy for stopping pandemonium in individual bug reports saying perhaps there should be a way to lock down bugs. Perhaps this is good, but it has to be done in a way that redirects the user energy somewhere else, rather than trying to bring it to a dead stop. When Wikipedia locks a page, they suggest discussing the lock on the talk page or similar.

1 comment:

Matthew said...

As one of those guilty of posting a relatively long comment on one of those bugs, I have a view about this. Ironically enough, I originally prepared a version of my comment as a blog post. What prompted me to turn the post into a comment on the bug report was the fact that Mark, who is after all the project leader of Ubuntu, Launchpad and Ubuntu One, openly posted his views on that bug report. Unfortunately, I only read Elliot's post after I posted there. So what we have here is a mixed message being sent to those interested in the discussion.

I did consider whether to post to the project's open mailing list, which is what I would have done in other projects, but I saw that Mark wasn't subscribed to that mailing list, whereas he is subscribed to the bug.

Obviously one needs to make an effort to respect the views of those who run a project when posting on their bug tracker, but if there is no clear policy on it, as far as I'm concerned it's perfectly fair to use a bug as a way to discuss even philosophical issues about a project, in particular where other methods of discussion are likely to fail to reach the correct audience.

Elliot was perfectly within his rights to close the bug as "Won't Fix", and that doesn't prevent discussion continuing on the bug.