Archive for the ‘gnome’ Category

Business as usual.

Monday, July 21st, 2014

No surprises:

GUADEC 2014

Looking forward to part-time holidays, beautiful Strasbourg, and the usual bunch of great people.

GNOME.Asia Summit 2014

Monday, June 2nd, 2014

GNOME Asia

Being back home and having covered the first two days already, a short overall summary:
GNOME.Asia 2014 conference in Beijing was very well organized – fast and stable WiFi, free water, venue, hotel and sport facilities all within 5 minutes of walking.

While GNOME’s European GUADEC conference is more like meeting lots of old friends (and great new community members) for an old fart like me, GNOME.Asia is about meeting those community members who often cannot make it to the European GUADEC conference (prices of plane tickets), plus spreading the word.
For ignorant Europeans like me, it’s a lot more about listening and learning about the diversity of our community, problems and differences in other areas, cultures, societies. (Plus in this case getting out of that Western internet services bubble of Facebook/Twitter/Youtube/etc. which feel ubiquitous, to see a different bubble yet to explore and understand further.)

Sponsored by GNOME Foundation

Check out the many great photos and the two amazing videos of day 1 and day 2. I’m convinced we won’t have to spend months waiting for the recordings of talks and presentations given either. Now can we import this awesome photo and video team for GUADEC please?

I really hope to see many people at GNOME.Asia 2015 again, and I also hope I’ll find some random reason to go back to Beijing and China soon.

RE: Outreach Program for Women

Friday, May 30th, 2014

Started writing this posting four weeks ago. Time to publish, seeing the latest blogposts by Philip and Marina on Planet GNOME about the Outreach Program for Women (OPW).

First things first (so you can stop reading if you disagree here):

  • If you question Outreach Programs in general: I consider diversity an important goal in distributed software development communities.
  • If you dislike that the Outreach Program for Women only targets people who do not define themselves as male and that it does not target different or other minority groups in a community: I don’t see why you have to try to cover all possible aspects when you start tackling a problem. I will not stop anybody from setting up an Outreach program for <insert language/region><insert ethnicity><insert economical class><insert sexual orientation or gender self-understanding><insert disability><insert religion><insert what I’ve forgotten> folks. That might be some work though and not just talking and criticizing from the sidelines. ;)

Outreach programs need to scale and be sustainable to be a long-term success. Is that the case? I’m not sure myself; depends on the criteria you come up with.

Scale

As Jim wrote, “the program grew to a size that overwhelmed our administrative staff person” (to simplify it).
Outreach Programs need to run without putting the GNOME Foundation or any other involved entity into financial or legal problems. I don’t follow closely enough, so I wonder if GNOME Foundation and organizations taking part in OPW have considered creating a separate legal entity with a dedicated mission to facilitate more diversity in free and open source software projects (as OPW has grown and is bigger than what GNOME is about)?

Sustainability

Do OPW participants (and GSoC participants) keep participating in our community after OPW is over, and do some become mentors themselves? (And if participants had sufficient time and financial resources, would they also participate if no money was offered?)
I consider the GNOME Documentation project to be a rather successful project keeping OPW’ers involved: Of those 14 OPW participants who worked on GNOME documentation, 6 pretty much vanished after OPW. 2 have mentored, 2 will likely mentor soon, and the rest is still around or around a bit. I don’t have numbers to compare and interpret (Marina posted some) but other GNOME teams feel less successful to me.
I’ve been wondering why. I’m sure others see other criteria and practices and I have not investigated other organizations who take part in OPW – feel free to add your impressions to the comments.

What to consider best practices?

  • Responsibility: GNOME includes dozens of software applications. The user documentation area provides identifiable smaller chunks (“the help files for application XY”). If you can well-define what your “area” is and others can recognize your area, you might get the feeling that others in the project rely on you and your work. You will be rewarded with responsibility (if such intrinsic motivation works for you) as you progress and prove that you are capable. An encouraging tone (“your patch is nearly ready, there are just a few smaller issues to fix”) and getting patch reviews from numerous persons instead of a single point of failure makes you realize that many people are interested in and follow your contributions.
  • Peer group size: The GNOME docs team has its IRC channel (#docs on GIMPnet IRC) with an overviewable peer group size. It might be less intimidating and overwhelming to ask your question into the void on such an IRC channel than on a channel with hundreds of people. It’s also easier to create friendship and trust than in larger channels. But when there are some non-doc related questions coming up, you are asked to interact and become involved with other members and teams of the larger community, in public. If you see that the rest of the community is also friendly and welcoming, you form further ties and friendships that make it attractive to stay.
  • Visibility: After you got accepted in an outreach program you get added to Planet GNOME (a website that aggregates blogs of GNOME community members) and are expected to write regular blogposts. (I hope there is some backpatting via blog comments that your work is appreciated but I’m sure this is an area where every community can improve.)
    GNOME wants you as an outreach program participant to attend GNOME’s annual GUADEC conference so you are provided partial sponsorship for travel costs (partial to avoid freeriding mentality and as GNOME isn’t rich). You will have to give a short presentation about your work. Latest GUADECs had a dedicated session for it with no other talks running in parallel – no excuses for missing it.
  • Learning curve: Learning to manage tools efficiently and understanding workflows of teams takes time. If you handed it in a late application for the program you might get rejected as the learning curve for you would still be too steep. You will be encouraged to continue contributing, learning more, and to apply again for the next round. And to avoid that, better start early. :)
  • Spreading the word, multiplicating the message, encouraging others to also get involved: I don’t know if GNOME asks applicants whether they actively engage with their local User Group or Hacklab, whether they can imagine giving talks about the FOSS organization and their experience working in FOSS at that User Group, their university, or a conference, and whether applicants get “warned” early to think about becoming a mentor themselves in the next round to help making the community grow and become a more diverse and welcoming place.

Statistics: Wikimedia has some statistics (beta) on community contributors joining and leaving. Which does not tell you why people join or leave of course. Could organizations be better to find out the “why”?
For example, I kept in contact with my OPW participant after OPW was over, but she got busy with her new job and moving to a new location (socializing). And I don’t want to be too be pushy and expectant towards volunteer contributions. Could I have done something better or differently? I don’t know. We all have our own lives and make our own decisions what to invest our time on.

Thanks

Thanks to my team (Sumana, Quim, Guillaume) for discussing diversity in general and thanks to Kat for discussing best practices and numbers about OPW in GNOME Documentation.
And obviously everything written here is my personal opinion. As usual.

GNOME.Asia Summit 2014: Docs & Bugs

Saturday, May 24th, 2014

GNOME Asia

GNOME.Asia Summit 2014 is taking place this weekend in Beijing (China) together with FUDCon APAC.

Yesterday (Friday) before the conference started, Kat, Dave and I held a hands-on session about making your first contribution to GNOME documentation (also see Kat’s blogpost). As a result, a number of tickets in Bugzilla have received comments and patches.
Apart from the pleasure to walk around in the room, take a look over the shoulders of people and helping out on non-obvious things, it was extremely eye-opening to realize again how many obstacles you need to pass in order to finally make a contribution – running a recent GNOME version, finding the documentation that is supposed to explain the following steps, having a GNOME Bugzilla account, finding a task (bug report) that sounds interesting, finding the corresponding code repository, locating the documentation file to patch in that code repository (in some subfolder called “C” instead of “en”), using git (formatting the patch, providing a commit message), uploading the patch somewhere for review.

Today I gave a presentation about managing bug reports in GNOME. About 15 to 20 people attended it and I’m very happy how it turned out – we ran out of time to triage a few tickets at the end, but the audience was interested and asked really good questions (e.g. the upstream-downstream relation)! I’m looking forward to the video recording of it.

Sponsored by GNOME Foundation

I would like to thank the organizers (especially Emily for her endless patience helping me to sort out visa issues), the sponsors, and the GNOME Foundation for paying part of my travel costs.

Lack of Maintainership & Finding a Project to Contribute to

Thursday, January 30th, 2014

One of the things I liked about the GNOME Documentation Hackfest (apart from the hospitality of Kat, Dave and the University of East Anglia) was the opportunity of teachers and students popping in and discussing open source project management related aspects with us.

One obvious topic is contributor involvement.
The Number Two question of people interested in contributing to GNOME (right after “How do I get started?”) is “I know programming language XYZ. Which projects would be good?”. Which leads to the question:
What are obstacles for contributors to find projects in language XYZ themselves?

And as volunteer based projects allow project maintainers or translation team leaders to disappear without a warning, new contributors might not realize or know where to escalate in order to become a new maintainer, especially if the single contact point of failure is a private email address of the previous maintainer who will never reply. New contributors do not know how to find out how “maintained” a project is – they would have to find the “log” page of the project on GNOME Git plus understand that translation updates are not a sign of development activity.
How to help contributors avoid writing a patch for an unmaintained dead rotten project where nobody will ever notice and appreciate their contribution?

This problem actually affects a larger group: Translators, documentators and bug reporters all waste time working on projects that will never see a release again. One year ago, one third of the non-archived modules in GNOME Git had not seen any code activity for more than two years. Obviously, these dead projects are not a good idea to contribute to if you have no experience in software project management yet but just want to contribute a small patch that scratches your own itch.

And as we discussed this I pointed to a university paper I wrote a year ago, comparing Apache and GNOME.
Realizing how often I refer to it it’s probably useful to link the PDF file:

Indicators for Missing Maintainership in Collaborative Open Source Projects (PDF)

Very quickly after that discussion, Frédéric created a “GNOME Project Health” webpage based on metrics in that paper.
Frédéric’s page allows to see which listed GNOME maintainers are active, how active the project is (the higher the score, the less activity exists), and in which programming language(s) the project is written. It’s a great start and I owe Frédéric a beer for it.

If you are a GNOME project maintainer you can help improving it:
If your project is mostly written in the programming languages X and Y, add the lines

<programming-language>X</programming-language>
<programming-language>Y</programming-language>

to the .doap file in the top level folder in Git, and check if the maintainers listed in the DOAP file do not collide with the reality out there.

GNOME Documentation Hackfest, Day 0

Sunday, January 26th, 2014

Reporting live from GNOME Docs Hackfest at Norridge, East Anglia.

Fréd arrived after bypassing some tree falling on his way. But he was very late. Shaun is still in a snowstorm. Ryan has escaped that already. But fearless leader Kat, Dave, Julita, Phil, Michael, and Baptiste made it. Petr plans to arrive in the middle of the night. If his plane does not decide to make even more problems.

Julita plans to refresh the structure of the Evolution user docs to make it more compact plus might take a peek at GNOME Developer Platform Demos.

Phil “arrived on a train, that was pretty good, and I’ve actually resolved a third of the licensing issues of GNOME system monitor.”

Michael and Baptiste visited the Protestant cathedral. Michael worked on system monitor and taking screenshots. Baptiste also kept contact to Fréd so he does not feel too alone and lost. And Sindhu joined remotely.

I went through numerous documentation related bug reports and updated them (plus as a side effect created statistics about all those many unmaintained modules in GNOME Git).
For a short moment I also wondered: Why does GNOME push for using AppData files if we have extensible DOAP files already in each repository? Hmm.

Interested documentation fans in the backyard.

Documentation fans in the backyard of the venue (photo by Michael Hill)

2014: Plans.

Monday, January 6th, 2014

Studying bug management

To my disappointment my university seems to have no expertise available to mentor a diploma thesis about best practices and common problems in open source bug management. After ten years of working in this field there are quite some open questions I’d like to see answered and after reading lots of scientific papers and books I yet have to find one covering the many aspects and personas involved, so why not write it?
I plan to do some case study research across FLOSS projects (and I’m thankful to Mr Riehle of the University of Erlangen-Nuernberg who pointed out a good resource explaining how to properly do this).

If you are by any chance a teacher at a German university and could imagine to mentor such a thesis, please feel free to contact me.

Wikimedia Bugzilla

This is worth a separate blog post soon, so for the time being I just point to my task list and status updates for the latest achievements. I also plan to attend FOSDEM which has a dedicated wiki track this year!

GNOME

There is a documentation hackfest at the end of this month and I hope to work on the Evolution user docs which I maintain, followed by attending FOSDEM in Brussels and DevConf in Brno.

Chennai

I plan to spend quite some time in Chennai this year by visiting several times. Drop me a line if you live there and would like to discuss Wikimedia, GNOME, or bug management!

Shades of Blue

Wednesday, October 2nd, 2013

I’m not entirely sure what’s special about my machine (T61 Thinkpad) that makes it lock up and reboot at least once per day without a warning (but sometimes after showing things in blue), but I’ve decided to blame something down the Xorg/Nouveau stack.
Interestingly, SSH’ing onto the sick machine isn’t much help either – when it freezes, cat /proc/kmsg, tail -f /var/log/Xorg.0.log and /var/log/messages, or gdb attached to /usr/bin/Xorg and gnome-shell don’t react anymore and don’t show any “additional” output either. Maybe it’s time to try Wayland? Can’t get much worse. :P

gnome-shell, now with more blue!

Colors!

Monday, August 19th, 2013

Save the money for LSD when you can have gnome-shell with a KMS kernel bug!

GNOME Shell with interesting colors

Fedora 19.

Wednesday, July 24th, 2013

Two weeks ago I erased the harddisk on my Fedora machine and installed Fedora 19 from scratch. I was tempted to give Mageia a try instead, but as it’s my main machine which I also use for work I tried to minimize disruption by not trying out new stuff.

My work (bug management) can be described as constant switching between browser (Firefox) with some custom Greasemonkey scripts for triaging bug reports, email application (Evolution) with many filters sorting mail into folders and tagging it, IRC (xchat), text files (gedit) and some gnome-terminal windows. Hence that’s my main focus of interest.

All in all GNOME 3.8 is really fast (considering this laptop is more than five years old) and looks great even in its details. Compared to the “classic” GNOME2/Windows95 user interface and workflow I don’t face any big differences that would require much relearning (but I’ve ran gnome-shell on my other machines before).
With gnome-panel I had application launchers in the top panel that I clicked with a mouse, now I have them in the dock in gnome-shell and start them once at the beginning of the session. For the rest I prefer using the keyboard: For applications that I don’t have running all of the time it’s faster now to start them, by pressing the Super key to get to the overview, typing the first letters, and pressing the Enter key (in gnome-panel this required cumbersome pressing of Alt+F2 plus additional pressing of Tab for autocompletion). I like gedit’s “Quick Open” a lot which allows typing a filename to open that file, without the need to know its location.

The rest of this blogpost only lists those small problems I encountered.

Evolution‘s connection to GMail is way more stable than it was in 3.2, and local filtering works more reliably and does not accidentially sometimes reset mail status to read anymore. Unfortunately importing my large Evolution backup file repeatedly ignored my account settings so I had to set them up manually.
Evolution’s constant freezing when filtering mail triggering gnome-shell’s “not responsive” dialog was quickly worked around by the developers for upcoming version 3.8.4, together with an ical invitation rendering crash fixed. However, even after setting physical folders for Junk and Trash for my GMail account (and filing a ticket to cover this recommendation in the Evolution user documentation), the IMAP+ account implementation sometimes manages to completely reindex a mail folder from scratch which can take a few minutes when you have 85000 messages in that folder. It also seems like I have lost the ability to close Evolution’s error messages by keyboard. WebKit now renders mail instead of ancient GtkHtml which makes everything feel way faster.

gnome-shell freezing and some graphical artefacts (which implies that it’s not gnome-shell itself to blame) have gone after cleaning my fan, now this only happens after a few days due to high memory usage which means I should identify which gnome-shell extension(s) to blame, and uninstall them.

Still no idea how to stop the computer from suspending when the lid is closed nowadays – user documentation needs an update and probably requires some logind magic.

The idea to have modal password dialogs feels pretty stupid when you might have that password saved in some textfile that you now cannot access (terminals to the rescue!) but some developers disagree. Same for missing IRC notifications in the message tray as nothing is blinking anywhere anymore – I’m forced to press Super+M from time to time to realize that colleagues wanted to chat with me a while ago, on the other hand I get less distracted which is very nice when you actually want to get work done.

Furthermore, something in latexmk seems to be broken so I fall back to compiling bibtex and latex documents a few times by hand to link against each other. And Rhythmbox seems to not play my manually added streams for some reason, but it does not crash anymore when starting it for the first time like in Fedora 16.

All in all pretty happy with GNOME 3.8. From past experience of installing a Linux distribution I expected bigger problems – I guess I need to accept how good and nearly flawless everything has become through all those years.

Same procedure as lastevery year, this time even in the center of Europe:

GUADEC

See you there?