Elijah’s Blog

boogle, booGle, bOogle, Boogle, bOogLe, BoOgle, BooGLe, BOoGLe, BOOGLE!

So this
was a fun little project. Still has some bugs, looks pretty ugly, and
isn’t complete, but it’s still pretty useful already. It can already
do at least a few things that quicksearch,
quicksearchhack, and the standard query monstrosity
can’t handle, such as
patch-status:accepted-commit_after_freeze.

(Warning: if you decide to try it out now, you need to understand that
I still reserve the right to break it whenever I want and don’t make
any guarantees about how quickly I’ll unbreak it)

It was nice to see that several people enjoyed my
patch review lottery email, but I have to confess that the part
that people seemed to enjoy the most (as evidenced by the fact that
the number of my Rupert quotes doubled) was a shameless rip-off of
Gerardo’s email. The sad thing was that although I was thinking
of Gerardo’s email at the time and was trying to mimic it as being a
mimic of the Nigerian spam email, I didn’t think I was doing as good a
job as he did so I went and looked up his email and literally copied a
good chunk of the beginning… I hope that email was GPL’d. 😉

I may get flamed for this, and no I’m not agreeing with what she did,
but after reading a blog entry
that Jamin linked too I’m starting to see things in a different light.
I’ve been trying for a few days to understand why she would have done
what she did, when she’s put so much time into things like gnomefiles.org (which I think rocks,
even if there are a couple issues from the foundation perspective on
worrying about it looking like an official site) and so much time
covering and using Gnome on OSNews. Anyway, having thought about it
for a while, I think Eugenia may not be the villain many are making
her out to be. Yes, I’m also upset and I feel that she
misrepresented the mailing list thread–and did so as publicly as
possible; but I think there may be much more to the story. Here’s my
verbose guess at what may have happened:

It looks like it started with the
ClearLooks as-the-possible-new-default email that was sent out.
Eugenia
interpreted the email as meaning that it was going to be the new
default (honestly, it sounded like that to me too), and thought it was
cool news and announced it. But, it turned out that it was just a
preliminary note. Unfortunately, themes have been a topic that drove
everyone nuts on d-d-l because it resulted in hundreds of useless
messages with no useful result (well, except maybe
the email that ended it). So, I think people were testy with an
incorrect announcement that was likely to require lots of effort to
correct…meaning a lot more inevitable time spent on the topic that
many had grown to
hate.

The
patched Simple theme issue didn’t help. She had tried to help by
submitting an improvement to a theme several months back, but it got
applied to the wrong theme: the default one. Now, the default theme
is so hideously ugly that no one actually uses it so no one noticed
until several months later when taking release notes screenshots.
Naturally, changing the default theme a week before release when we’re
in hard code freeze looks bad; unfortunately, when people tracked down
the problem her name came up. Now, it wasn’t really her fault (it
wasn’t anyone’s fault), but a communication disconnect with an
important issue tends to put anyone related to the problem in a tough
spot.

So she felt bad, even if they were honest mistakes, and wanted to fix
things. So what’d she do? Well, the main things she works on is to
try to analayze applications and operating systems and how they can
improve in order to report on them. So, she thought she’d find a
bunch of improvements that could be made and
report them. She may have thought that she wanted this list to be
public to show that she was trying to be helpful (i.e. to “mend her
image”) when she sent her request and thus requested to have them
shown somewhere outside bugzilla (unfortunately, she probably didn’t
think things through and ended up looking like she wanted to do less
work, not follow the normal rules, and get special treatment).

Still wanting to try hard, she suggested a different approach (yes,
this was probably a mistake too because others would have been more
amicable had they seen her decide to follow the normal rules and put
the effort of filing her couple dozen bugs manually). This idea was
an
online poll (which she was
requiring to be official) of features people want. That would
allow her to do something she excels at and show she’s trying to help.
Unfortunately, besides being slightly misguided (we want to target
normal users, not just power users whom we already get feedback from
via mailing lists, irc, forums, etc.), her lack of filing these bugs in
bugzilla made this look like she was trying to craft a poll that would
allow her to get her pet features implemented.

I really don’t think she understood why her requests were being turned
down or the responses; I think she was somewhat emotional at this
point having tried to help and finding that things were actually only
getting worse the more she tried. Although she may have normally been
able to think things through sanely, things were just too charged at
this point. She
kept trying to press the point…and even tried to make another
suggestion on how to “improve” things–getting all Gnome users to
pay for it so that we could hire more developers to handle more
user requests (Eugenia doesn’t understand free software even if she
does use quite a bit of it, and probably further didn’t realize that
this came across as “you are doing things so wrong that we need to
change your whole development model”).

At this point the thread (er, “threads”, no thanks to Microsoft
Outlook) was preventing lots of work from getting done and several
people jumped in to say that the thread(s) had to stop and pointed to
the previous emails for why the ideas were not wanted. Coming from a
very charged situation in which she tried hard to help had left her
confused, sad, and also angry (some of the responses,
including mine, had become curt and showed a lot of annoyance with
her emails–to say the least). It was not long later when she posted
her infamous
article, which, probably more than anything else, was a knee-jerk
reaction to exhaustion from trying to find a way in which to help and
inexplicably digging herself a deeper hole. She was in quicksand and
her flailing wasn’t helping. I doubt she was thinking at this point
when she posted her article. Unfortunately, it seems to be digging an

even deeper hole.

Poor Eugenia. I may be way off in my guess above as to how events
occurred, but I suspect that something like it has transpired.
Although Eugenia has always struggled to understand the free software
and open source software way of doing things and thus has always had
problems communicating with the community, she has put a lot of work
into promoting it (even if she also promotes that other crap out there
😉 I think that, given the chance, she’d probably rejoin the
community (well, half-way, since she may be too firmly tied to XP to
fully join) and try to help. Granted, it’ll probably never happen
given the looks of it right now, and maybe others don’t want to allow
that to happen, but I for one think we ought to give her the chance if
something like what I have postulated did in fact occur.

Okay, go ahead and flame me now.

Update: Got some emails pointing out inaccurate or misleading
things in this entry. I’ve tried to change and correct them. Sorry
for any mistakes; please do point out any further problems.

So
this Gnome Journal article went over Gnome 2.10 “with a
fine-toothed comb”. It looks like they did a really good job overall,
but naturally I just had to look at the Metacity section. Being the
nitpicky guy that I am, I thought I would clarify and correct a few
things:

• There were a number of user visible changes if you’re looking
  for things as small as what they noted, not just one.
• The change they pointed out was not an option addition but
  merely a renaming of “Put on All Workspaces” (which reflected a
  slight change in behavior necessary to fix some ugly corner
  conditions).
• They were right that there were lots of additions and
  optimizations to the built-in compositing manager (which I need
  to take a look at at some point…), but those all went in on
  the spiffifity branch so it’s not in the release in Gnome
  2.10

For those curious about the user visible changes that I refer to
above, here’s some of them (I’m trying to only pick out some of the
ones that are at about the level of detail they seemed to choose):

• Focus stealing prevention (covered in the release notes; though
  this was actually an older feature that didn’t beat feature
  freeze for Gnome 2.6 and had just been disabled in Gnome
  2.8)
• Icons for minimized windows and hidden windows (think “show
  desktop” mode) are dimmed in the Alt-Tab switcher popup.

• Add a keynav mode for sloppy and mouse focus users so that they
  can actually use keyboard navigation in a fairly sane manner
  (the mode automatically switches on or off when you use the
  keyboard to switch windows or go back to using the mouse to
  switch windows; most may not even notice–especially since this
  isn’t needed in click-to-focus mode)
• Refuse to focus windows with a modal transient, and focus the
  child instead (unfortunately, some windows claim they are modal
  for a single window but are really modal for all other windows
  of the app; further, we don’t handle when an app correctly
  specifies that it’s modal for all other windows)
• New default icon when the app doesn’t specify one
• Treat splashscreens the same as other windows for stacking
  (“that @#$&^ Eclipse splashscreen kept me from working with
  other windows for 30 seconds!”)
• Allow fullscreen windows on one xinerama to stay on top when
  working on the other xinerama screen
• Don’t lose which window has focus when interacting with the
  panel (unless interacting with a text entry applet or something
  else that requires keyboard focus)
• Add a keybinding to launch a terminal
• Make “showing desktop” mode be per-workspace instead of
  global

So, Eugenia went and wrote a whole article on how
Gnome developers supposedly aren’t interested in user feedback. I’m
having a difficult time seeing how she could have misunderstood so
many comments from the email thread
that started it all. Some examples:

Havoc said:

We [are interested in user feedback], but we have better ways to find
out than web polls.

I’m interested in what your features are, because I like as much data
as possible. But I’m not going to be surprised or think it reflects
any fundamental breakage in GNOME if nobody gets around to those
features. There are only enough developers to implement maybe 1% of
what gets requested.

Federico stated:

In general, field research would be more beneficial in the long
run. Real users — random people who go to Brazilian Telecentros,
office clerks in European cities — don’t know where to report their
annoyances with free software. They don’t have time to find out about
it as they just want to get things done. You have to go to them, ask
them, and watch them use the software.

Bastien said:

I usually implement features when they are unintrusive, make the
software easier to use, and when people ask nicely for them, without
spamming or rambling on about them.

Shaun added:

The problem with all these voting systems is that they have sample
bias written all over them. The majority of users, real users, don’t
go onto bugzilla, and they don’t vote in web polls on osnews. Market
research is not the same thing as polling the enthusiast
community…

And I *did* implement a voting system for Yelp features, but nobody
voted

I even
explicitly pointed out her misunderstanding and misrepresentation
3 days before she posted the article:

Doing votes often appear as “developers must do users bidding”. You
took the response here that we avoid votes for that reason as
“developers will not listen to any requests, whatsoever” (which is
totally false; I have tried to implement several bugzilla requests
that weren’t interesting to me personally).

But she still persisted in portraying that thread as “Gnome developers
are not willing to listen to user requests”

Sorry for going on about this topic, but… eXpert Zone had an
article which on the whole I found to be well thought out. There
was an Achille’s heel in their argument, though:

As I already said, the turning point, and most fundamental line, in
the discussion was “A feature will be implemented if and only if there
is a developer who wants to implement it, regardless of the number of
votes it’s received.”. This later on in the discussion came down
to “if the developer has a need for it himself”. [emphasis added]

How exactly was that conclusion drawn? While there were some
developers who expressed this personal choice (which is perfectly fine
for volunteers to do), others expressed willingness to implement
features even that they might not use themselves and others pointed
out that those employed to work on Gnome were responding to customer
requests. The statement they quoted was correct that features are
only implemented if developers want to do so, but unfortunately they
made an inaccurate inference.

Aaron Bentley tracked me down and sent me an email about my earlier tla and baz blog
entry. He noted that (a) doing things using Crispin’s workaround
produces a non-standard archive that may make future implementations
choke (ouch!), (b) it’s much better to make the right way easy than to
convince people not to do it the wrong way (very good advice for
everyone to keep in mind), and (c) to go along with -b-, baz 1.3 will
support diff -p and the code is already in the development branch; in
fact, this is old news and I’m just a latecomer.

What’s more important than this specific information, though is that
(1) baz really is working hard to make arch usable (I should have been
more patient in giving them time to do so, as that is an enormous task
and they have only had a short time so far), and (2) baz developers
apparently really care.

They have my respect.

The easy-fix keyword
has been renamed to gnome-love. It has an ultra cool
report to go along with it to make it easy for potential
contributors to go through these. It’d be awesome if we could get all
modules to use it as much as
conglomerate (that module currently accounts for over 40% of all
bugs with that keyword!) Take a few minutes and see which bug reports
in your module could use this keyword; you’ll be helping the Gnome Love project and
potential contributors that want to get involved, and even more
importantly you’ll be attracting eager hackers to help with your
module.

Update:
Olav pointed out something I forgot to mention. The report
displays the comment made at the time the keyword was added. So it’s
helpful if you add an informative comment when adding the keyword.

So, the easy-fix keyword has long needed some help. I decided to give
it some with an easy-fix
query. You can also get modified reports, for example to
create a
product-specific lists of tasks for potential contributors. Olav
provided a modified
version that produces RSS instead of HTML (though he says there
are problems with it).

I think this fixes some of the problems with the easy-fix keyword, but
to fix the rest I think we’ll probably need to rename that keyword
(and then do some publicizing). Any suggestions for a new
name? I’d like something that won’t easily be misused and that
also matches the following definition (or something close to this
definition; it may need tweaking too):

Marking a bug with this keyword means that you’re willing to help
someone fix the bug, or that it should be fixable by a beginner
without any help. This should ONLY be set by a maintainer or people
familiar with the code base, and ONLY when it looks like a project
suitable for a new developer looking for a task.

For the curious, the problems I’ve found previously with the easy fix
keyword were:

• Misuse

  It appeared that the easy-fix keyword was being used as “This
  should be easy for you to fix. Do it.” and “Here’s a patch for
  you; that makes your job easy.” There were also a number of
  other related uses, partially due to our previous unclear
  description of the keyword and partially because many don’t read
  the real description thinking, “I know what ‘easy-fix’ means…”

• non-removal

  Once a bug was marked as easy-fix, it wouldn’t be removed if
  someone started working on it. But in that case, it really
  shouldn’t appear in a list when someone is searching for bugs to
  fix (or at least it shouldn’t appear anywhere near the top of
  the list).

• Lack of awareness

  Many people seem to be unaware of the easy-fix keyword. Despite
  easy-fix existing for years longer than the KDE equivalent,
  the KDE equivalent was better known (yes, that was just one
  email, but I think it was indicative from other experience).

• Difficult to use

  Surprisingly, many reported being unable to find any open
  easy-fix bugs in bugzilla. Maybe bugzilla is just to hard too
  use because we have always been able to show people how there
  are several dozen whenever this is pointed out to us, but still
  we shouldn’t have to show them how to do the bugzilla query.

• It really isn’t quite what we want

  We want people to be able to use the keyword for bugs that
  aren’t necessarily trivial but which would still be feasible for
  beginners to tackle. easy-fix just doesn’t seem to match.

Once again, Olav is kicking butt fixing bugzilla.gnome.org bugs. It’s
so cool. My favorite fix that he just committed recently is the handling of
needinfo bugs sucks problem.