Public Bug Tracking and Open-Source Policy 118
Observer writes "Bugs in software are nothing new, but when they're discussed in the open, how do open source projects adapt policy? A major regression in the Gnome project's session manager has seen some major distributions choose to refuse to follow the update rather than drop a major feature. Between Gnome's public bug tracker and similar trackers from distributions which released (and still distribute) the buggy version, months of debate provide an interesting case-study in the way front-line users and developers interact for better or for worse. What lessons can be learned here for release planning, bug triage, and marketing for a major open source project?"
Re:Common developer problem (Score:3, Interesting)
> User: "So stuff that I use now stops working?"
Yep, that is very much my experience with KDE 4.1. So many things stopped working that it is barely usable. Which is fine, expect that version 4.0 was supposed to be the shiny new framework, and 4.1 was promised to be ready for the end user. By sticking labels on it, the developers create expectations in the user base, and the stick is justified if the expectations are not achieved.
Re:Common developer problem (Score:5, Interesting)
Hear, hear. At work I maintain a internal fork of an open source library we use. Not because I enjoy forking: because the guy with write access to the library's repository started a major refactor 18 months ago in trunk and still hasn't finished it; the subset he uses works, but we use some of the more advanced stuff which he hasn't fixed yet. I can't just take a snapshot before the refactor because then I miss loads of bugfixes.
Re:+1 Transparency (Score:5, Interesting)
Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.
Huh? If they're public and open, the end use can see them. What are you talking about?
My emphasis.
It is a problem... we need tracker moderation (Score:3, Interesting)
When you run an open to post bug tracker you are inundated with idiots who think a bug tracker is a discussion forum as well outright spambots. Some of the "me too" and "I think this is a major bug" posts could be addressed with a "me too" button and counter in the tracker. But..
I have a modest proposal for what we really need:
1/ cold hard cash
2/ nothing appears in the publicly visible tracker until approved by a moderator
The way this would work is when you file a ticket your credit card should have $50 deducted and the ticket hidden from view until it has been approved, if approved you should get $40 back. So if you report a crash without the backtrace or even a description what you were doing when it happened you are out $50. After paying the CC fees any 'profit' could be burned in trashcans to provide heat for the homeless, just so the moderator can not be accused of being unfair for the cash. Similar fees could be applied to ticket comments, say starting at $10 per inane comment and escalating to $100 for repeat offenders. None of these comments would ever have to make it out to the publicly visible face of the tracker, but there are plenty of people who would still keep posting at $100 a pop just to annoy the devs. Burning thousands of dollars in small bills could warm the hands of many a homeless man, and scaled up to a large number of OSS apps would help keep inflation under control.
To the humor impaired: Ok, this is tongue in cheek. My point is that once a project grows past its first few thousand users a public issue tracker becomes a liability. Real bug reports get lost in the constant barrage of junk tickets, but you can't even close those junk tickets because then you have to deal with some luser with a bee in their bonnet.
Adapt Policy in the Open (Score:3, Interesting)
"Bugs in software are nothing new, but when they're discussed in the open, how do open source projects adapt policy?
Policy adaptation is a care-requiring activity, especially if discussion in the open is involved. Closed projects may get away with customer defenestration, but open source projects are more susceptible to their developer community and enthusiastic users. How a project would adapt policy should be given a great deal of thought and dialog to ensure no one is left out of the loop.
Re:It is a problem... we need tracker moderation (Score:3, Interesting)
The nice thing about a public bug tracker is that many problems have been raised and solved often without changing a single line of code. As a simple example my ethernet card was showing up as eth8 and not eth0 by use of google and finding a bug report i found the reason was due to a udev rule and a particular file which i then edited to get eth0 back. There was no need to go any further.
I found another feature/bug in open office writer today I wanted a block of text in title case and found open office gives the option of lowercase or uppercase and applying a character effect to the selected text all good apart from i just wanted to get title case and paste the text into kompozer however as the title case is just an effect applied to the underlying text so the title case effect is stripped away when you paste as plain text into another application (incidently gedit has a plugin which does title case properly).
komposer in ubuntu intrepid crashes when submenu's are accessed, but there is a repository recently set up with a working version of kompozer that works with hardy intrepid or jaunty (why do I know because of the bug tracker).
3 reasonably simple examples which show that bug tracker does work quite well in the eyes of the public. For devs I can imagine how much it sucks to get the same old questions and incomplete bug reports that are useless. However dev's shouldn't be looking at unconfirmed bugs and there should be an intermediate layer of experienced users and interested parties who can confirm deny and hopefully reproduce the bug on demand and then they can raise the problem with the people coding the project once its shown to be valid.
Re:Common developer problem (Score:4, Interesting)
It's for just that reason that I question this mostly unstated assumption that anywhere there is a gap between developers and users, that it is somehow entirely and automatically the job of the developers to bridge that gap. When you are talking about Open Source software that is both free as in speech and free as in beer, there is certainly no moral expectation that this should be the case.
The average users in this scenario are non-contributing beneficiaries. Non-contributing beneficiaries who are demanding instead of helpful are beggars who are trying to be choosers. Here, I'm not talking so much about what is said and done so much as the way it is said and done and the intent behind it. It's one thing to politely ask for a feature or a change because you think it would be great. It's quite another to make judgments about someone's character or their ability to figure something out because their free contribution was not to your liking.
By and large, these users are unwilling to acquire the skills necessary to implement the changes that they demand from the developers and yet some of them are willing to pontificate about how a developer should think. When the GP said "Sadly, many developers never figure this part out", that is a manipulative way of saying "they seem to disagree with me about what should be important." I say that because some things genuinely are "sad" while others are merely differences of opinion and it is intellectually dishonest to conflate the two. The only reason for doing it is to give an undue appearance of superiority to your own viewpoint but if your viewpoint were truly superior, no such tactics would be needed.
Furthermore, this is a difference of opinion not between two equal viewpoints but between a contributor and a non-contributor. Beware the tendency to automatically consider all viewpoints to be equal. It has a certain allure because it can sound noble but there are many times when it just isn't the case.
When you unnecessarily phrase something in a manipulative fashion, subtle though that may be, it has some interesting effects. Most people are not aware enough to understand why or to see this process as it occurs, but what happens is that they instinctively sense that there is a "wrong feeling" to it. Unfortunately many people, even those who can see this happening, lack the strength to just calmly point it out and show by their example that there is another way. They don't know how to experience it without being affected by it because they are externally motivated and it is external ("externally motivated" = "responds to pressure"). So when they sense this "wrong" feeling there is a tendency to either appease it or to fight it, depending on the character of the person. Both are wrong because both are harmful.
Appeasing it is a mistake because it validates the tactic and sends the message that it's acceptable and will obtain the desired results. It also robs the appeaser of much of the joy that could have been found in the creative process by replacing noble service with demeaning servitude, a process that tends to breed resentment. Fighting it results in senseless pissing contests and personal arguments which reinforce the "us against them" mentality, in this case "the interests of developers vs. the interests of users". It also makes sure that your position is no better than that of the other person and so it destroys your ability to lead by example even if you were initially correct. There a
Re:The real lesson (Score:4, Interesting)
Actually, I rather think that you are placing the blame on the wrong set of individuals here.
I work for a closed-source software company, which has some extremely large customers using our product. We were implementing minor/major releases and we incorporated functionality changes to minor releases. This was a problem almost every time, because at least one of our customers was using that feature and relying on it to work the way it worked in the previous patch.
Consequently we stopped adding new functionality into the minor releases.
You'll notice, however, that it's not the developers that caused this issue. No. It was the project and product managers for either a. allowing the functionality change, or b. allowing the functionality change but not realising the sheer impact it would have on the client-base and thus not planning accordingly.
That said, the difference between the company I work for and the Gnome project (after reviewing the ) was that when a regression occured for us we scrambled for a fix within a week, while the Gnome guys say things like "The bug is fixed when it's closed as FIXED.", "Paolo, Manu: Whining does not really help in getting things fixed. [gnome.org]
"What's the hold up?" Write the code for it and attach it here." and "Yeah. And the codebase for 2.24 has changed a lot, so the 2.22 code has to be
adapted/changed a bit. Just do it, the code is available. *shrug*"
The last comment was the most infuriating to a lot of people I think. The best response [gnome.org] I read in relation to Andre Klepper's "*shrug*" comment was:
As a fan of open-source for a LONG time, I'm beginning to wonder if it will ever cut it in the business world. I suspect with attitudes like the ones highlighted above that the answer is "no". And that makes me feel very, very sad.