Oct 202008
 

Managing bug lists has become an ubiquitous task when dealing with the GNOME or Nokia bugzillas. At some point I became fed up with the involved cut and pasting, searching and sorting, so I cooked up a small command line utility to construct bug list URLs and format bug list summaries in text form. Here’s it in action:

    echo "junktext 556578 moretext 516885 " | buglist.py gnome
    http://bugzilla.gnome.org/buglist.cgi?bug_id=516885,556578
     516885 - Add RGBA support
     556578 - GIMP windows stay on top of other windows

It knows a good number of bugzillas, such as the ones from Gnome, FreeDesktop, Maemo, Nokia, OpenedHand, GCC, LibC and Mozilla. More bugzilla URLs can easily be added, and it handles HTTPS authentication that some of the corporate bugzilla installations require.

The script is available here: buglist.py (v0.4)

Have fun and send in patches. 😉

Jun 022008
 

Just like LinuxTag last year, I went to Berlin the past week to help running the Gnome booth for LinuxTag 2008.

Due to a sports accident, our booth bunny Sven Herzberg unfortunately couldn’t make it, so on Tuesday I took over booth management and merchandise from him and hurried to Berlin in an ICE instead of a car as was originally planned. In Berlin, I met up with Mathias Hasselmann who brought the European Gnome event box and together we set up the booth until late in the night.

On Wednesday morning, Michael Köchling and Christian Dywan arrived, so we had enough people to properly man the booth. Michael seems to be an early riser, since he managed to show up at 09:00 for all days, so i passed the booth keys on to him.

Around lunch time, I was dragged away for an interview about business involvement in free software and Gnome in particular by Malgorzata Ciesielska, a business school student from Copenhagen. She also interviewed other people like Lennart Poettering who also sporadically hung around our booth.

Later that day, Lennart and i went over the new libcanberra API in a lengthy discussion. Libcanberra is a new library for playback or activation of sound events in response to desktop actions that Lennart currently works on. We talked about the needs of timing information for some usage cases, possibly also dispatching forced feedback controls via the library and implementation of a Gtk+ module to hook canberra functionality up with GUI events. What turned out to be a bit tricky is to derive actual semantic information from the low level X event notification that Gtk+ signals proxy, such as dialog-confirmed, dialog-cancelled, menu-item-selected, menu-item-cancelled, combobox-popup, combobox-selected, combobox-cancelled, etc. This extraction requires significantly more logic and special casing of event notification than Lennart apparently had originally hoped for.

On Thursday I attended the Linux Kernel – Quo vadis? talk by Thomas Gleixner which was quite interesting. I managed to catch him afterwards to talk about the prospects of having a memory pressure signal in the Linux kernel. For GLib and Gtk+, this’d be quite useful to voluntarily release pixmap or GSlice caches, particularly desired on embedded platforms.

Friday I sat down with Vincent Untz for a very productive discussion about Gnome/Gtk+ release prospects, autotools, intltool features and more. Later I had a chance to chat with Alexander Neundorf about KDE’s recent CMake migration process. Overall, they seem to be pretty happy with the results. Major benefits from migrating from autotools to CMake seem to be:

  • Build process speedups due to getting rid of libtool.
  • Simplicity; the build setup is back to a manageable level again. For KDE, the previous combinatoric mess of autotools was hardly fully understood by any single person.
  • Unification/merging of build files for Unixes and Windows. (Duplication of build logic between auto* files, nmake and MS project files is currently a major annoyance for Gtk+’s Win32 maintainers.)

On Saturday the last day of the conference, I attended Anne Østergaard‘s presentation about Gnome Foundation structures and achievements, the slides of which are available here: The GNOME Foundation (PDF).

After that, I went to Jono Bacon‘s talk in which he explained how the free software community is a creative and productive community, which sets it apart from other common community types in our society (usually fan communities). He went on pointing out how this collaborative and open community as a whole (and thus every significant contribution to it) impacts and gradually changes the really big IT companies from within in an unprecedented manner. Come to think of it, this is an incredible achievement that we should rejoice in, especially because it is a morally correct change in that it strives towards openness.

All in all, it was a nice conference again. Personally, I particularly enjoy meeting up with other hackers for productive face to face sync ups. So I’d like to thank Christian and especially Michael for their great efforts in patiently answering bypasser’s Gnome questions at the booth, while I wandered off to talks or had technical discussions in its back.

Dec 142005
 

I didn’t mean to engage in the flamage about the printer dialog or usability design issues with Gtk+’s new file chooser, but i do feel that a few things should be pointed out in this context nonetheless. In particular, I’d like to respond to Dave Neary (bolsh), quote: “Linus is irrelevant”. There’s an important thing to note here: Linus opinion on GNOME is relevant!
For a single very important reason: Linus is a GNOME user.
Every GNOME user counts. Without exception. Yes, i mean it.
This is the reason we care about accessibility even though it focusses on a user group that can be regarded a minority by sheer usage figures. If you start to make decision only for an assumed “majority of users”, you are going the wrong path with a probability so high you may as well call it a guarantee.

Firstly, programmers are notoriously bad at assuming what the “majority of users” want, and often even what that “majority” is. As Linus put it: “the _vast_ majority of people are part of a specific minority when it comes to something”. As a result, it’s often very hard to tell what your users want or even who they are. The only cure from that is listening to your users, their requests and – if required – poll feedback. If you think these are exclusive programmer problems, think again. Without a specific case study at hand, guesses by usability experts usually aren’t any better. And marketing experts face the same problems, they also need to figure who their (possible) users (customers) are and what they could (possibly) want. The main difference between marketing people, usability experts and programmers is that the former two groups actually make evaluations and studies, they test or ask users and try to find out about their needs and expectations. They do the “feedback polling” just mentioned. (If your project allows for feedback polling to be carried out as a proper usability study, that is always better than just asking the user what he thinks he might need.)

Secondly, disregarding any group of users by marking them as irrelevant is a guarantee for bad perception. There is no way around this, you have – by definition – just made sure that some users are going to be dissatisfied and feel mistreated. Now think about your own reaction when you feel that way. Do you shut up? Do you engage in improving the particular project? Do you try to work out a consensus with someone attempting hard at ignoring you?

Thirdly, disregarding any user needs is not the logical thing to do from an impetus perspective. For that, think of the user request as a force towards a specific direction. Arguing against the request can be viewed as a resistance to the force. As a programmer or project leader, you’re in control of that resistor. If you’re clever, you try to direct that force to work for you, e.g. “We could integrate feature XXX if we had a patch that integrated it according to specification XXX-spec.” The force may be not big enough to be utilized, i.e. the user walks away; fine, without knowing a person really well, you couldn’t have told its strength in advance anyway. Or it might be big enough, you get your patch (maybe from the user directly or maybe by him hiring someone to do the work, etc), you work out the details and you can integrate it into the project. In the end, everyone wins that way (I’ll get to why this doesn’t need to worsen usability).

Alternatively, you can be ***not-so-clever***: You could argue that the feature will never be integrated, for whatever reason, and stand by that point. That is effectively putting the resistor antipodal to the force. Be assured, it’ll hurt both sides no matter how polite you are since this situation strives for conflict maximization.
To be fair, this is a simplification to some extend, sometimes the user simply needs to be told the proper way to achieve something or be kindly reminded of the manual. I have faith in the ambitious reader to tell this difference though 😉

As an interesting side note, let me tell you that the not-so-clever branch of the impetus view can explain forking amongst other things. Consider a force (the user(s)) significantly stronger than the resistor (the blocking developer). There are basically three possible outcomes of this:
1. Argumentation goes on until the developer gives up. Depending on the project structure, various things can happen, the developer might resign, or a patch gets past him by approval of other project developers. The user may (longer term) even become a more active contributor.
2. If the developer is in full control of the project and doesn’t give up, the user can re-aim his energy. He may provide significant contributions to a competing project (maybe a proprietary one), or he may direct his energy against the project by generating bad PR and spreading FUD. Now remember that we assumed above that this force was significant, measured in relation to the developers energy. Significant bashing, hindering the project in various ways, will be the result and can be observed for quite some project/user combination.
3. Let’s say our user who has a significant urge to see his problem XXX solved is technically skilled. He might start his own program/project which solves XXX. However if the project is large enough, a fork will often provide the only viable alternative. So if you ignore enough users especially over topics they deem important enough (they don’t need to appear important to you), you increase likeliness of a project fork, or maintenance of a customization patch set for your project or similar variants thereof.

Now i do realize that not everyone in the GNOME camp wants to ignore and upset the majority of users or user minorities (be warned that “user minorities” may still represent a strong force 😉
So let me plead that we attempt to reduce this where it comes up nevertheless. As things stand, we have too many dissatisfied users currently and can observe the various outcomes described above. To address this, we simply need to strive for fulfilling more user requests, e.g. by accepting more patches that have been rejected as “featurism”, and by re-enabling or exposing existing features (gconf-editor gives you a hint on what could be done already if we allowed more configurability).
And let me side-line with Linus on trading features for usability. Basically, this can’t be done, because usability can only be a second grade concern. If you don’t have features or leave them out, you’ve ruined your usability right away, not improved it. If you have usability problems because of many features, yes that is a serious concern but still second grade. There are various ways at dealing with this, for instance by improving the structure of your preferences or by introducing user levels (e.g. early versions of Nautilus did this) or “Advanced” features (take the mozilla tab extension preferences as an example) or a number of other measurements. The reason there is not “The Definitive Answer” to this currently, is that usability in various aspects is still a very active research topic (let’s talk about this again 100 or 200 years from now). Taking features out is not amongst the set of these usability measurements, because it’s essentially a first grade decision about the program scope and solution space constituted by user desires, so it will definitely get you into the problem chain presented under “Thirdly,” above.

In essence:
In order to avoid various kinds of problems for your users and project, NEVER REJECT A FEATURE but either implement what’s requested or ask for an implementation (nothing simpler than just saying: “We accept patches.”)

Up
date:
PBor replied in his blog and suggested a title change for this post to “Never reject a feature request!“, which I much agree with in retrospect.