andré klapper's blog.

Marina, Daniel, Muslim and I represented GNOME at the Google Summer of Code Mentor Summit.
As a nice coincidence, my colleagues Sumana and Rob also went their representing the Wikimedia Foundation.

After attending a session about project management I realized that there might be further interest to discuss bug management / issue tracking so I set up a session for Sunday that about 15 people attended in order to discuss problems and practices. For those with an account, the log is available.
I also attended sessions on Continuous Integration, Community Metrics and other topics.

Big thanks to Google for sponsoring and arranging a welcoming conference with a wide range and variety of topics.

While I organized and ran Google Code-In for GNOME for the last years (a contest for 13-17 year old students) I won’t have enough spare time this year. So the question is if GNOME wants to take part in it (mentors, anyone?), and if somebody volunteers to organize it. The deadline for applying to take part is November 5th (in two weeks).
Organizing means: Setting up our wikipage (last year’s version, see the ChangeLog how to start), doing the paperwork (registration, documented on our wiki), nagging developers and community members to become mentors and provide tasks, and while the contest is running making sure that mentors respond quickly.

So if you feel like getting fresh young people into GNOME and open source: Be bold!
I will of course be around for questions and to support you, and help out.

“If I had asked people what they wanted, they would have said ‘a faster horse'” — Henry Ford

Continuing to write about this year’s GUADEC conference that ended a few days ago. It should be obvious that opinions in this blogpost are my own.

The state of GNOME

Many people discussed the concerns expressed by Benjamin in a recent blog post. I know that Benjamin deeply cares about GNOME but I am not sure with some of the conclusions – some feel unproven. Dropping some thoughts here to comment some of the statements.

• For the (non-)variety of people working on GTK+ anybody can get his/her own impression by taking a look at the GTK+ commit log (though that is just the master branch). Same for any other project. If you want to get numbers, git clone a module repository and run git log –after=2010-08-01 –author=” –pretty=format:”%ae” | sort -u | wc -l to see how many different authors got code changes committed in the last two years. We can all still differ in interpreting those numbers of course. ;)
• With regard to the statement that “[m]ost important desktop applications have not made the switch to GNOME 3”, I am not sure which extend “GNOME 3” is meant to imply.
  Picking one of the core parts by taking a look at GTK+3 acceptance, you can follow the ongoing efforts of Mozilla porting to GTK+3 in this bug report, see on page 19 of Michael’s slides that there is “an improving prototype” of gtk+3 for LibreOffice, enable Inkscape’s experimental GTK+3 build when compiling, or try out GIMP’s branch for the GTK+3 port.
  Work is clearly in progress and I traditionally don’t consider big complex projects as early adapters.
• Not sure how to interpret “losing mindshare” either, so I can only state that GNOME received about 41000 changes (only counting the master branches in the GNOME Git repository, work can also happen in other branches plus some teams also use external infrastructure) by approximately 1275 people for version 3.4, and about 38500 changes by approximately 1270 people for 3.2. I know this does not tell anything in the long term. Unfortunately I do not have numbers from before 3.0 handy (I gathered the aforementioned data for writing the last release notes), but iterating over all GNOME Git repositories (list available here) and using git log –after=yyyy-mm-dd –before=yyyy-mm-dd –pretty=oneline | wc -l syntax should be doable for anybody interested. Note though that the list linked above does not include modules that were archived in Git (see the Git web interface) so this would require a bit more work to also include them.
  Apart from sheer numbers, GNOME provides and takes part in several outreach programs (Google Summer of Code, GNOME Women Outreach Program, Google Code-In) with a high number of contributors staying in our community after programs have ended (I don’t remember exact numbers but Marina mentioned this in her talk about the Women Outreach Program). You don’t need to wait for a program though to get involved – GnomeLove and its large number of mentors let your start your journey at any time!
• Dominance of one company: Page 16 of Dave Neary’s GNOME Census from two years ago lists 16.3% commits by Red Hat employees. Judging is up to each individual, but it would require updated data to really judge the situation in 2012.
  Still, likely everybody agrees that GNOME would benefit from more companies involved. Every project out there probably would. We have seen companies cutting involvement in the past (IBM, Sun, Nokia) so that is nothing new. Companies need compelling reasons why to invest in the GNOME platform, the community, and GNOME’s future. If current reasons and future plans are not well-defined and convincing this is something to discuss and improve, on several levels (mostly advisory board, foundation board, release-team, but also all the other hard-working teams that make GNOME the awesome project that it is).
  Picking up two examples: Do we advertise enough our awesome translator community with its high quality translations for dozens of languages? Is our developer story convincing enough? Surely there is always room for improvement: The translation community plans to improve outreach and make it easier to start translating by helping with setting priorities. New tutorials for developers are in the making for 3.6 (and any developer is welcome to help by providing short code snippets). And when I take a look at the new features coming in the next release it clearly feels like the most active development cycle in the GNOME 3 era so far (Allan named some already in his post).
• In order to respond to expectations expressed by some community members towards the release team (mostly in regard to leadership in case of potential conflicts or confusion about direction), the GNOME release team asked the community: “Which role do you expect the release team to have?” (slides are available). Frédéric’s blogpost covered this topic already.
  As written in the slides, the release team serves our community but it’s up to our community to decide to which extent. Its current self-understanding is to “try to not get into the way“. The release team did not express its position in order to initiate an open discussion.
  If the community thinks that there are ways in which the release team can help the GNOME project to perform even better, then the release team will be happy to do so. The direct feedback at the conference seemed to be very positive and expressed lots of trust in the release team’s work, but more feedback (especially by those not attending GUADEC) is needed before proposing potential changes.
  (Disclaimer: I am a member of the GNOME release team.)
• With regard to criticism which sometimes comes up on the transparency of decisions: It is a fact that many discussions happen in real time on IRC (or via other channels, like Google hangouts), in the timezone of the developers, and not on mailing lists only.
  IRC makes it harder for interested people to follow those discussions if you live on the other side of the world or are not online all of the time. My very personal opinion is that IRC logging might help to be able to get a better understanding of the reasons why and how some decisions were taken.
  The fast pace of GNOME’s development is impressive, combined with summarizing and communicating plans early through further communication channels (mailing lists, blogs) so people can also provide feedback if they cannot follow GNOME development that closely. In this field, Allan does an awesome job with his regular blogposts on what the design team is up to so people can chime in to contribute and get involved.

Other random short bits

• Proposed with some friends Brno (CZ) to host GUADEC 2013. Strasbourg (FR) is the other option (and also a great city!). Final decision to be made by the GNOME Foundation Board in September or so.
• I was part of the papers committee, deciding which talks to have (we did not refuse many as the offer was quite convincing), and trying to schedule them. Though we clearly had absolutely no influence on it, I’ve been told by a few people that this year’s talks were of high quality, so congratulations and thanks to all speakers for interesting topics and good presentations!
• 17% of GUADEC attendees were female! I hope that number will continue to increase.
• Lots of very passionate Women Outreach Program (GWOP) and Summer of Code (GSoC) students attended the conference, with an awesome diversity. It seems that our community was perceived as very welcoming. I hope that many people will stay involved and help GNOME to evolve by participating in discussions on GNOME’s future and direction. Folks, you are the future of GNOME!

Thanks to everybody who traveled to A Coruña in order to participate, and to all our sponsors, making this the best GUADEC ever!

Today was the first of two BoF session days at this year’s GUADEC in not-too-hot Galicia. There are quite some BoFs taking place.

As planned a few weeks ago I spent this morning with GNOME’s wonderful Accessibility crew. This led to two results:

• The former “Don’t triage bug reports in the Orca screenreader!” has now become a “Please triage Orca bug reports!” with instructions in the new “Orca” section of the Bugsquad’s product specific guidelines. If you are into bugtriaging or accessibility, please give it a try.
• Accessibility team needs better notification on accessibility bug reports. I propose to add “Accessibility” components to relevant modules/products in Bugzilla.

After sneaking in for a few minutes to the Geary session (which looked like a nice and interesting way to gather feedback of potential users on the functionality scope) I went to the Translation/Localization/Internationalization BoF session.
Among the discussed topics were a calendar to enter planned release dates of projects, better outreach, reorganizing modulesets and setting better priorities to help teams where to start translation efforts, glibc locales, handling dead git modules, handling dead translation teams, killing docbook in favor of Mallard, counting strings vs counting words, damned-lies improvements, gtranslator improvements and IRC bots for logging chats. See the wiki for a full list of topics and task assignees.

I also went to some other impromptu/informal meetings to discuss certain topics but missed the “GNOME OS” session today.
Probably should blog about a few more things in the next days.