andré klapper's blog.

Google Code-In has been running for nearly three weeks and 57 tasks have been completed so far by highschool students. Only 27 tasks have not been completed yet. Some examples of completed tasks:

• A boost for Greek, Indonesian, Romanian and Ukrainian translations by several contributed translations.
• Boxes received some testing and libosinfo now detects more systems
• Documentation improvements for sudoku and Python tutorials.
• The preferences dialog of Cheese was redesigned and the application received some code cleanup
• Mockups for a bookmark editing dialog in Vinagre
• Several presentations and guides were created and proofread.

It’s not too late to join for mentors to add new tasks and for students to work on GNOME: Check out GNOME’s wiki for more info!

Note that the second batch of tasks will be made available to students on December 16th. The contest ends on January 16th.
Happy hacking everybody!

This Monday Google Code-In 2011 starts. Google Code-in is a contest for pre-university students (13 to 17 years old) to get involved in free and open source software. GNOME (and 17 other organizations) are proud to participate by providing a few dozens of small mentored tasks. These tasks cover eight different fields (code, documentation, translation, and more)!

Students!

If you want to join Google Code-In, check out the Contest Rules and the Frequently Asked Questions for more information. Specific information for GNOME’s tasks is available on the GNOME wiki.

Mentors!

We want more mentors and tasks!
You can add/propose new tasks at any time until December 16th. Check both GNOME’s wiki and Google’s wiki for more information for mentors!
Note that there are only two dates on which GCI tasks will be published for students: this Monday (November 21st), and December 16th. All tasks created between November 22nd and December 15th will be published on December 16th.
Or just discuss task ideas that you have with potential mentors.
Or join #gnome-love on IRC to help students if you don’t have time to be a mentor.
There’s many ways to help.

Enjoy, and just ask if you have questions or ideas.

The summit

Last weekend Marina and me represented GNOME at the Google Summer of Code Mentor Summit in sunny California.
It was my first time attending a Mentor Summit and I was surprised about the wide range of topics at this unconference and the many different participating organizations and projects.

To mention some of the sessions:

• Marina’s and Pat’s session about women in FOSS and contributor outreach (e.g. GWOP).
• Metrics Working Group: Probably the most interesting session. Several FOSS projects work on gathering statistics on their community and its health, and I also had my shot at it last year. So why not join forces? This blog post lists some existing approaches, and there is a mailing list.
• “Google Code-In: Contribution Quality” was my own session. About 20 people (among them three Googlers and last year’s grand prize winner Daniel Kang) discussed common issues, such as organizations playing favorites by cooking up tasks for specific students (hence Google changed the rules for publishing tasks this year), defining the task difficulty, or impatient students asking for reviews (put information in the task about your availability on weekends or christmas, or have a backup mentor).
• “Documentation: Organizing the Effort” was about the management of user and developer documentation – keeping user docs up-to-date/in sync, translation infrastructures, organization and structure. Was wondering if GNOME analyzes click rates and search terms for access to the online user and developer docs to find out which topics are popular (and might need a better UI, or even a “Top 5 issues” section).
• And I popped in at the end of the “Melange Feedback Session” to find out why Google Code-In tasks from the last year are not accessible anymore. I was not the first to ask. Google is working on it and soon will provide them.

Finally a big thanks to Google for sponsoring and arranging a summit with a creative, welcoming and open atmosphere.

GCI is back

Also, Google Code-In 2011 was announced – see Johannes’ post for more info how to make students contribute to your GNOME project, but hurry up as the deadline is on Monday.

Just dropping some recent activity here.

• Olav, Allan and I wrote the GNOME 3.2 release notes. They are available for translation and will soon be available to public.
• Sent two GNOME 3.2 blocker bug reports and asked for committing reviewed patches.
• If you plan to have a GNOME 3.2 release-party, add yourself to the list on the wiki!
• Next step: Prepare a release schedule for version 3.3…

At the first Desktop Summit in 2009 KDE’s aKademy and GNOME’s GUADEC conferences were just co-located. I cannot remember having had any interaction with non-GNOME folks (but I wasn’t around for the complete conference).

In 2011 it wasn’t just co-located but mixed tracks. Though I attended some KDE talks and had to realize that most were boring to me simply because I have nothing to do with that software stack I still had great and interesting conversations with some KDElers.

Mission

The Summit website states “The goal of this event was to share ideas and further collaboration between the two communities.” The section “Goals for this year” also lists “Collaborate on desktop software projects”. And everybody has different experience and opinions whether this actually happened or not.

Criticism

In both communities there are mixed feelings whether the concept of a Desktop Summit makes sense. I know that some GNOMErs expressed their opinion that Desktop Summits slow down GNOME development. You can draw two conclusions from this: Either to not repeat Desktop Summit because of that. Or to fix this for the next Desktop Summit.

While the technical stacks are mostly different, there is room for collaboration in less technical areas such as release management, bugsquads or documentation efforts – even if it’s only about exchanging experience or best practices. This also applies for some technical areas that are shared in our stacks via freedesktop.org, e.g. parts of the accessibility framework.

So?

If the fear is that planning and development in each environment slows down under the collaboration banner, and that a GUADEC-only conference is more helpful in pushing things forward in GNOME, why not have it both? Have one or two days of collaboration related sessions only and nothing GNOME or KDE (or LXDE) specific, followed by two co-located conferences that only have environment-specific sessions. Does that make sense?

Disclaimer

I left out the financial part on purpose as I have no clue about that, however I know that it has influence on the decision whether to continue Desktop Summits or not.

As Tiffany already mentioned in her blog post, Pedro and me hosted a Bugsquad BoF at Desktop Summit. There were not too many folks around (mostly the people from the previous session stayed in the room) but nevertheless it was very interesting as blauzahl was kind enough to answer lots of my questions about KDE’s bugtriaging processes.

No groundbreaking stuff to post, but it was an interesting insight.

• KDE Bugzilla has the Voting feature enabled. GNOME Bugzilla has not. I’m rather neutral about this so I was just curious.
• In KDE, bug reports of unmaintained or deprecated modules can be closed as RESOLVED UNMAINTAINED (though this is not done consequently), while GNOME Bugzilla uses RESOLVED WONTFIX combined with a “gnome[unmaintained]” Status Whiteboard entry for this. I like the idea of a separate resolution though I don’t remember if RESOLVED UNMAINTAINED is used for KDE3 apps that are dead, or KDE3 apps that have a KDE4 replacement, or both.
• Currently no community has bugdays (GNOME, KDE) which traditionally are an easy way to get new people involved (outreach) in the projects as many bug triagers move on to writing code after some time in the Bugsquad. Ubuntu has topic-oriented bugdays every week and uses them mostly to clean up the bug database of specific modules. The “Triaged” status in their bugtracker (Launchpad) helps avoiding duplication of work.
• Remaining question that was also a topic in the previous BoF in that room: Where to share patches, especially for long-term distributions (RHED, SLED, LTS) && projects that are unmaintained in upstream development (e.g. KDE3-only components or deprecated GNOME2 components), and how to improve upstreaming efforts. One idea was to use Bugzilla’s “Default CC list” option for downstream packages to get notified of patches (but bugmail options don’t have a “trigger for patches only” setting).
• Speaking about statistics in general (and as I am impressed by the MeeGo Community and Activity Metrics), efforts in KDE seem to be very similar to those in GNOME, namely Quarterly reports and a Commit digest, but nothing targetting the bigger picture either.