No, GNOME doesn’t want user feedback; how I argued in favor of voting in bugzilla, and got banned as a result

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?

The bug

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?

The ban

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").


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,, 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 [ 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

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 [ 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:

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 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).

Good riddance.


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, 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.

N9 Swipe undocumented feature; activate sane behavior

Ed Page recently blogged about his idea to improve the Swipe UI. Fortunately for him, a bunch of people and I had the same idea inside Nokia 🙂

Update: apparently this is not present in the images distributed with the Nokia N950’s, it was introduced after 25-3.

If you open ~/.config/mcompositor/mcompsitor.conf, you’ll see a bunch of swipe-action-foo configs, all of them set to “away” (by default).

You can, however, change them to something like:
swipe-action-up: switcher
swipe-action-down: close
swipe-action-left: events
swipe-action-right: launcher

And voilà! Now depending on which direction you swipe, is the action that would happen. You need to kill mcompositor for them to become active (or send SIGTERM/SIGINT, I don’t remember which one).

This was possible because I got fed up arguing about the benefits of swiping down to close applications, and decided to implement the thing by myself. While doing that, I also decided to implement an idea that was flying around, which was to do something different depending on the direction of the swipe. It took me about two days to do, including making it configurable, mostly trying to familiarize myself with the code that was split into multiple packages, and wrapping myself around C++, which I have avoided as much as possible. That was much less time than the time spent discussing before and after I implemented the patches. Fortunately, after seeing the thing in action, many people jumped into the wagon, and at least swipe down to close is available to the masses, which people seem to like. Guerrilla design 😉

However, after a lot of though, I realized the configuration I mentioned above is ideal. And this is my rationale:


The current design is inconsistent; when you swipe away, you never know in which desktop view you are going to end up, specially if you just unlocked the device. You might end up in ‘switcher’, or ‘launcher’, or ‘events’. Same action, different behaviour equals inconsistency.

There’s a simple solution; utilize the simple mental model required to navigate the desktop views.

Swipe mental model

In this way, it’s easy to know exactly what would happen when swiping on each direction, decreasing the amount of actions needed from the user. The same action always produces the same behavior.

It is unclear if this mode is ever going to be officially supported on the device, despite the fact that I think it’s obviously superior (and Ed Page seems to agree, as he came with the exact same idea by himself), maybe some people are worried about updating manuals and what not, but at least it’s trivial to activate, and anybody can create a 3rd party app for that 😉

BTW. This is yet another reason why I distrust people telling me I’m a “geek”, and “designers” know better when it comes to design. In the words of Elaine Morgan; yes, they can all be wrong, history is strung with occasions when they all got it wrong.

Enjoy 🙂

msn-pecan 0.1.3 released


This is a normal maintenance release mostly to fix reliability on
authentication, and offline messaging fixes.

Felipe Contreras (19):
      build: use makensis
      win32: update README with full instructions
      gitignore: update
      build: trivial cleanup
      build: remove redundant -ansi specifier
      pn_util: remove clang warnings
      auth: properly cleanup pending request
      Improvements from clang analyzer
      Trivial cleanups from clang analysis
      pn_util: trivial improvement in pn_html_unescape
      http: fix crash when connecting from another location
      sync: fix gression in LST command
      msn: send messages offline when invisible
      notification: properly update the status on CHG
      node: extra check for open signal handler
      auth: fix a few memory leaks
      node: fix trivial warning
      build: use GIO by default
      win32: tag 0.1.3

Download from the (usual place).

Why geeks should be your target for marketing

It’s simple; because they listen. As opposed to the masses, which are really good at ignoring you.

Do you really think Average Joe will listen when you say your Samsung Galaxy S II has a 1.2Ghz dual-core processor? No, he will ask his friend, Geek Mike, which phone he should buy.

Seth Godin, marketing guru, explains it perfectly:

He explains the TV industrial complex is gone, the golden years of the 60’s when all companies had to do is flood the TV with ads is now history. There’s too many choices, and way less time. Nowadays there’s complex networks of information, and everybody knows where and how to get recommendations of services and products, which probably will only be noticed if they are remarkable.

How do you explain that Google became such a big company without advertisement? You make a good product, and people talk about it. First the hard-core geeks, then normal geeks, there’s normal people, and eventually, even grandmas and grandpas. They started with doing one thing, but very well, and that made them remarkable. That’s why today even though Google+ as 74% males and 25% engineers (reference), they will spread the word, and eventually everybody will be there.

That is the viral effect of social networks. If you want something to spread through the network, you have to target the nodes that are more tightly connected, the ones at the center of the network. These would obviously be geek bloggers, many of which have thousands of followers, each of which will spread it to more and more people, until eventually you get to the masses. Google, Twitter, Facebook, the iPhone, they all seemed to be targeting only a small niche of technical people, but what many people didn’t consider, is that these geeks would find the value, and spread the message.

This should be obvious, but for some people it’s not. Some people say “oh, the geeks don’t like this, but it’s OK, they are not our target market” (Nokia comes to mind), which completely misses the point that if geeks don’t spread the message, you already lost.

And that is why GNOME 3, for example, already lost. They are ignoring the huge backlash from existing users telling them “we don’t care about you, you are a tiny minority”.

In this hugely interconnected world, you should not disregard the tiny minority that loves you, to seek the huge majority that doesn’t care about you, that is not only dangerous, but doomed to fail. Moreover, I would go even further and say, this tiny minority can actually tell you what you should do to reach the big majority better.

After two weeks of using GNOME 3, I officially hate it

I knew I was going to hate GNOME 3 even before trying, but Zeeshan insisted that my opinion wasn’t worth much without giving GNOME 3 a fair chance. So we made a deal, I would use GNOME 3 for a couple of weeks, and then I could say GNOME 3 sucks, at least with measure of validity.

So, after two weeks, I still hate it. But why? Continue reading

gst-av 0.5 released; now with video encoding and decoding support

gst-av is a GStreamer plug-in to provide support for libav (formerly FFmpeg), it is similar to gst-ffmpeg, but without GStreamer politics, which means all libav plugins are supported, even if there are native GStreamer alternatives; VP8, MP3, Ogg, Vorbis, AAC, etc.

In addition, it is much simpler (2654 vs 16575 LOC), has better performance, and has a bit of extra features (such as less latency), and doesn’t use deprecated API’s. In a previous post I measured exactly how much improvement compared to gst-ffmpeg there is; it’s not much, but it’s some.

IOW; it’s possible that gst-av is the only GStreamer codec plug-in you would ever need 🙂
Continue reading

Getting proxy support on GNOME; for real (libproxy-simple)

If you open gnome-network-properties and setup your proxy accordingly you would notice that most network applications don’t really work. There are several reasons for that.

Since as long as I can remember I have looked for a way to add proxy support on my applications. There has been a number of network libraries, none of which have ever fitted the bill for me. Finally, came GIO, now part of GLib, which has many advantages (although IMO not ideal; it works perfectly). Unfortunately, no proxy support.

There’s also libproxy, which one might think has proxy support, but it doesn’t; it merely provides a mechanism to find proxy configuration. This is good, but not the full picture.

But since GIO has plug-ins, it might be possible to provide proxy support transparently, with the help of libproxy… right? That’s where GLib networking comes. Great! So we have everything we need.

Not really. Continue reading