I have long been an advocate for listening to the users (see this old thread in in GNOME’s ml), and through the years I have discussed over and over with GNOME developers why it’s important to listen to your users, and why they are barely doing it.
However, that hasn’t prevented me to cooperate in their bugzilla, I have filed bug reports, participated in discussions, also fixed bugs, and I even maintain one component; gst-openmax. You can check yourself here, or for a few interesting ones: 629349, 640859, 640665, 650724, 655361, 480858, 623473, 630910, 598771, 535074, 534975, 548776, 340375.
Yet, because of a couple of comments in bug #629161 (Support voting in GNOME Bugzilla), and without any warning, I got banned. But of course, they deleted the evidence, so you can’t see it.
The official response
Anyway, let’s leave the ban pending, and concentrate on the real issue: why are votes not enabled? This is what you can find from GNOME’s site:
Voting would give the impression that your vote would make someone fix the bug faster. That is almost always not the case. As this gives a false impression, voting usually creates a lot of extra comments because of that (eg ‘this bug has XXX amounts of votes and still not fixed’) and just frustates users.
A better way to get a bug fixed faster is to either:
- Provide a patch, or
- Look, review and test the patches provided by other contributors. Especially the reviewing part takes a lot of time and developers will really appreciate people who say if a patch does or does not fix the bug for them. Reviewing the patch (looking for potential problems / good code style / etc) is even better.
Note: If you want to express interest in a bug, just CC yourself (and leave the comment field empty). The developer can easily see if a lot of people have cc’ed themselves, without causing the bad voting side-effects.
Voting would give the impression that your vote would make someone fix the bug faster.
No, it wouldn’t. That’s a miss-conception, there’s plenty of evidence to the contrary, as Tim Janik pointed in his blog post, both GitHub and Google Code offer voting methods, but not only that, Mozilla Firefox, KDE, Mediawiki, WineHQ do too.
Let’s take a quick look at the most voted bugs in some projects: Chromium Issue 60101: webRequest extension API (2264 stars), Wine Bug 421 – Implement a DIB engine (161 votes). Do you see anybody having the impression that the bug should be fixed fast as GNOME people suggest? No.
That’s because it’s not true, people assume that a bug with a lot of votes should have a high priority, that’s a completely different thing; speed != priority.
As this gives a false impression, voting usually creates a lot of extra comments because of that (eg ‘this bug has XXX amounts of votes and still not fixed’) and just frustates users.
Again not true, and backed up by a lot of evidence. People don’t complain if a bug is not fixed in a timely manner, they complain if it affects many people, and developers give to it no importance. But if they did their job properly, that would not happen, in my experience, just setting the right priority but explaining that it’s not that easy to implement is enough. Additionally, I set milestones based important bugs fixed, this way users know that 1.2 won’t be released until the bug they care about is fixed, so they know there’s no point in raising attention to it.
But even assuming what they said was true, the amount of annoyance the complains would generate is overcome by the value provided by knowing which bugs are really important.
If you want to express interest in a bug, just CC yourself (and leave the comment field empty)
That’s not what the CC field is for, therefore people would not use it for that, defeating the purpose. Plus, you can’t sort bugs by number of people in CC.
That’s it. It was easy to debunk wasn’t it?
Let’s go now to the bug in question; bug #629161. A bunch of GNOME developers (Tim Janik, Jürg Billeter, Sandy Armstrong, Travis Reitter, Javier Jardón, Gabriel Burt) made it clear that they would want this for their components, yet nothing happens. There’s basically only arguments in favor, nobody is arguing against.
So, now you have refuted arguments from their official position, and an enhancement request to allow voting in some components. Why wouldn’t they just allow it, if anything, just to see how things go? At the end of the day it’s the maintainers of the components that would decide if voting has been beneficial, or not. One can only speculate, but I assume the reason is political; if you enable voting for some components, people would automatically assume that the other components don’t want to hear feedback from users (which might very well be the case).
In anyway, it won’t happen–not for certain components, not as a trial, not ever. There’s no real reasons against, and it doesn’t matter how many arguments are put forward. Strange, huh?
These comments were deleted, so I’m providing them in full so you can judge by yourself, also, because there’s no public hearing or any way one can defend itself against arbitrary bans.
--- Comment 14 Felipe Contreras 2011-09-08 23:24:33 UTC (In reply to comment #5) > Google's star approach is nice because the user does not see how many other > folks starred the issue (or if they do, it's not nearly as visible as something > like "votes"). Wrong. http://code.google.com/p/chromium/issues/detail?id=60101 2273 people starred this issue and may be notified of changes. (In reply to comment #12) > The argument that users will be disappointed that bugs with high numbers of > votes are not being fixed has been raised here, and also previously on Bug > 390454. My counter-argument to this is: so what? Every other bug tracker I > use (KDE, Novell, SeaMonkey, OpenOffice.org, MediaWiki) allows users to both > make and view votes. Yes, occasionally some users complain that bugs haven't > been fixed. No, this hasn't resulted in planes falling out of the sky, all > development work ceasing, etc. Such unhelpful comments are thankfully rare, > and either get ignored, or else someone politely reminds the poster of bug > tracker and free software development etiquette. Exactly. The value of the information gathered by this outweighs tremendously against the small possible annoyances. In my experience however adding voting does not lead to annoying comments. In my own project hosted in Google code I always make it clear when a feature is extremely popular but it's difficult to implement, I just say that, and the users seem to understand, that if it's not fixed in a certain period of time, it doesn't mean that nobody cares, it just means it's not that easy. Now, if this was actually *tried* for some period of time, and *then* it turned out that there was indeed too many of these comments I would understand, but that's not the case. The decision is based on pure speculation.
I say something is not true, and I provide evidence that shows that’s the case. Then I say the decision is based on speculation, which is true, and the only way to know for sure is to give it a try. Is that too bad? According to Olav is it bad enough to warrant a ban:
--- Comment 15 Olav Vitters [bugzilla.gnome.org developer] 2011-09-10 03:46:00 UTC (In reply to comment #14) > The decision is based on pure speculation. Please just stop the way you're acting. Just because I see things differently doesn't make it ok to behave like this on Google Plus, desktop-devel-list, here, etc.
Olav says I should stop with the way I’m acting, without specifying what is that “way”. First of all, notice that there’s no threat of a ban at this point. Also, notice that I don’t know what exactly I’m supposed to stop doing. So…
--- Comment 16 Felipe Contreras 2011-09-10 12:34:24 UTC (In reply to comment #15) > (In reply to comment #14) > > The decision is based on pure speculation. > > Please just stop the way you're acting. Just because I see things differently > doesn't make it ok to behave like this on Google Plus, desktop-devel-list, > here, etc. I'm not acting in any way. Here's the definition of speculation: * to think, meditate or reflect on a subject; to deliberate or cogitate * to make an inference based on inconclusive evidence; to surmise or conjecture That is what you are doing. If you don't like how it sounds, then don't do it. The only way you can know for sure what would happen if you enable voting, is to enable voting, and see.
Right? If somebody is speculating, what’s wrong with saying “you are speculating”, if you want people to say you are speculating, then don’t speculate. Like a cheater that is complaining about people calling him cheater.
--- Comment 17 Olav Vitters [bugzilla.gnome.org developer] 2011-09-10 13:22:55 UTC To put it in other words: I don't like the way you're behaving. For example: (In reply to comment #16) > That is what you are doing. If you don't like how it sounds, then don't do it. Stating things in above way, just don't. I'm not talking about arguments you're trying to make. It is about the way you phrase them. More concretely: My objection is not about not like "speculation", it is the tone of your messages and the way you phrase those things. To more it comes acrosss as trying to "tick me off". This is the last I'll say on this matter on this bug, getting offtopic.
Oh! So it’s the tone? Well, we could debate whether there’s a nicer way to transmit the message I want to convey, but why linger on such lowly things? Olav certainly seems to have moved on and don’t want to discuss about this.
Note that at this point there’s still no warning about what would happen if I continue this behavior, that until the last comment wasn’t clarified, and in my opinion, it should never be an issue in the discussion.
--- Comment 18 Felipe Contreras 2011-09-10 14:06:06 UTC (In reply to comment #17) > This is the last I'll say on this matter on this bug, getting offtopic. Exactly, this has nothing to do with the subject. And complaining about "tone" is not precisely considered a sophisticated way to engage in a discussion: http://www.paulgraham.com/disagree.html http://upload.wikimedia.org/wikipedia/commons/7/7c/Graham%27s_Hierarchy_of_Disagreement.svg
According to Paul Graham responding to tone is “a weak form of disagreement”, so I try to make it more delicate by saying it’s “not precisely a sophisticated way to engage in a discussion”.
BANG. Without any other comment or notification, I got banned. I didn’t notice until weeks later when I couldn’t login to GNOME bugzilla with this message:
Bug 629161 -- continue behaviour after various requests to change it If you believe your account should be restored, please send email to email@example.com explaining why.
What? I go to that bug report and I don’t see anything (my comments were deleted), so I ask personally Andre Klappler to fetch the comments for me, and at the same time I contact the bugmasters.
After I got the comments and analyzed them I proceeded to build my defense (attached at the end); I actually never used a wrong tone. Olav’s problem was not with the tone, but with what I was actually saying, which was not flattering for him or GNOME, but actually true. I went into detail through those comments, and there was not nicer way of saying it.
In fact, I even proposed a compromise, I would not make any comment that criticizes GNOME, because apparently, that’s not allowed.
But, not surprisingly I got no response, except from Andre Klapper, who said he didn’t even read my defense:
On Fri, Sep 23, 2011 at 3:35 PM, Andre Klapper wrote: > On Fri, 2011-09-23 at 15:20 +0300, Felipe Contreras wrote: >> Of course not, you are only interested in patting each other in the >> back, and self-congratulate yourselves. You are not interested in a >> fair trial. > > It's exactly this style that makes me not interested in discussing > anything with you currently. > I stopped reading here, not interested in the rest.
So, no fair trial, banned with no warning, with reasons that are not true. That’s justice in GNOME’s world.
So that’s why
Perhaps it should be clear now why is it that the GNOME project doesn’t listen to it’s users, doesn’t allow voting in bugzilla, doesn’t allow a user survey (I’ll explain that in another blog post), ideastorm, or anything that gives the user masses the ability to speak.
GNOME is an autocratic oligarchy; it’s a club of like-minded people which only allows like-minded people. It a group that is both pompous and self-congratulatory; patting each other on the back is an obligation. You should not rock the boat, criticize the status quo, be confrontational, or deviate from the norm. They are never wrong, or do lowly things, and their design is dogma.
As I found out, to suggest that a GNOME member is speculating is such an extreme offense, that one should be shunned forever, never to poison GNOME’s precious ears, regardless of years of contributions (in my case since 2005).
Since not Olav, nor anybody else presented any case, I'm going to infer it from this: --- Bug 629161 -- continue behaviour after various requests to change it --- What is that behavior? Using phrasing and tone that are not in the liking of Olav. How many instances? Presumably two, comment #14, and comment #16. How many requests were done to change it? Presumably two, comment #15, and comment #17. First of all, at this point it should be clear, that in no point in time any ban warning was issued. In fact, at no point in time any repercussions where stated. Having participated in countless online discussions, I thought saying "I don't like your tone" meant only that. Many people dislike the tone of other people, but most people don't have the power, or the indecency, to block somebody's comments just because they don't like them. Now, did the accused change his tone after the second request to change it? Well, lets look at comment #18. What is the tone of this comment? How could this comment transmit the same idea, but with a tone in the liking of Olav? If you go to the page http://www.paulgraham.com/disagree.html, on the section "Responding to Tone", the description is "this is still a weak form of disagreement". So, stating that the site says so, is merely stating a fact, not engaging in any form of inflammatory rhetoric. But instead, I tried to choose more "subtle words", and changed "a weak form of disagreement" to "not precisely sophisticated". So no, there's nothing wrong with the tone of this comment. What Olav didn't seem to like, was the content of the message which diminished his position. There is no way I could have made that point in a way that Olav would have lied it. So his "request" in comment #17 doesn't apply, thus the "second warning" was never enforced. Not to mention that at this point it seems more that Olav doesn't want to discuss the merits of tone, and thus he is willing to let go of his request. A person who was willing to improve discussions would have been willing to continue the discussion about merits of tone in a private manner. Or at the very least Olav should have made it clear that regardless of the importance, it's something that is not tolerated and warrant a ban. He didn't do any of such things. But if you look closely at comment #17: This is not a second request, it's a *clarification* on the first request. And it points out to a line in comment #16: --- That is what you are doing. If you don't like how it sounds, then don't do it. --- Is this tone bad? What could be done to this message to improve the tone? The point being made is that things are what things are; speculating is speculating, and there's nothing wrong with pointing out what is happening, instead, one should focus on avoiding doing it, rather than preventing people from pointing it out. So, there's really not much that can be done to change the tone of this message without changing its meaning as well. So, again, Olav was not concerned with the tone as he claimed, but he was concerned about what was being said. And finally, the line that started everything in comment #12: --- The decision is based on pure speculation. --- We ask again, is this tone bad? How can you say the same thing in a better tone? There are not many ways. So, yet again, Olav was concerned about what was being said, not the tone. In conclusion: 1) There was no law, no warning, effectively no way in which I could know what was going to happen. 2) There were no various requests to change the behavior, only one, explained in two parts, because the first one was not clear enough. 3) The complaint about tone is unsubstantiated, the real problem is pointing out things that put GNOME in a bad light.