Google Code-in 2015 has started!

(Google Code-in and the Google Code-in logo are trademarks of Google Inc.)

Another round of Google Code-in started yesterday. Together with Nemo and Petr I am one of the organization administrators for the Wikimedia community.

In this year’s edition of Google Code-in, students can choose from tasks provided by the following organizations / projects: Apertium, Copyleft Games, Drupal, FOSSASIA, Haiku, KDE, MetaBrainz, OpenMRS, RTEMS, SCoRe, Sugar Labs, Systers, Ubuntu, and Wikimedia.

If you are a 13-17 year old pre-university student interested in getting involved into free and open source software development, check out Google Code-in.
It is a great opportunity to learn about distributed software projects, to find out which areas of software development you are interested in, to gather some on-hands experience, to contribute to “real” projects out there used by millions of people, and to make new friends all over the world.

Posted in computer, gnome, lang-en, wikimedia | Comments Off on Google Code-in 2015 has started!

Prioritizing volunteer contributions in free software development

Wikimedia is an organization which has both volunteers and paid folks working together in software development, with many software projects and different stakeholders involved.
In Wikimedia, there is currently some discussion how to improve the code review process. One aspect is reducing our code review queues and waiting times, with a focus on contributions provided by volunteers.
There are numerous successful free and open source software projects with a similar setup of companies and volunteers involved (Mozilla, Openstack, …) so I’m curious if your project has also investigated similar questions and if there is some knowledge and experience to share.

  • In your project, do maintainers commit to review contributed patches in a certain timeframe, like “all patches receive a first review comment within four days”? How is this process implemented? Do you think it is successful?
  • With an existing backlog of patches that did not manage to attract a review, what do you with ancient and rotting patches? Do you just abandon them after a certain timeframe in your code review tool to get a “cleaner slate”? Or do you leave them open to (theoretically) allow someone to find them and them pick up?
  • Do you have any specific workflow in place that provides feedback to patch authors who contribute a patch to a rather unmaintained repositories that noone feels responsible for (anymore)? Do you signal the lack of maintainers and encourage contributors to step up as maintainers? How?
  • Do you have a workflow in place to specifically prioritize the review of patches contributed by volunteers? How efficient is it?

I’d be very interested in hearing how your project handles these issues. Needless to say, links to documents are welcome. Thanks!

Posted in computer, lang-en, metrics, wikimedia | 1 Comment

Wikimedia: Phabricator, Tech Community Metrics

Trying to quickly summarize what’s been either on my plate or what’s been generally cooking in Wikimedia, before I postpone writing that again…


Tech Community Metrics

Recently also spent more time with Tech Community Metrics. Wikimedia has some metrics about code repository activity (Git), code review activity (Gerrit, in the long run to be replaced by Phabricator Differential), mailing lists and IRC. It’s available at backed by MetricsGrimoire and supported by Bitergia. When we migrated from Bugzilla to Phabricator Maniphest we initially lost any statistics on bug tracker activity but now there is an initial Phabricator Maniphest backend in MetricsGrimoire available.
Again, all this is work in progress and needs way more fine-tuning (see our project workboard).
Posted in computer, lang-en, metrics, phabricator, wikimedia | 1 Comment

GNOME.Asia Summit 2015 (part 2).

Continuing with the first day: Shobha Tyagi elaborated on the acceptance problems when moving users from Microsoft Windows to Linux based systems at her university. That talk resulted in interesting follow-up discussions on regional differences.

Shobha's talk

Shobha’s talk

Later on, lightning talks took place.

Olav banging the lightning talk gong

Olav banging the lightning talk gong

On the second day, Alexandre Franke explained the GNOME release cycle.

Kukuh Syafaat showed how he uses his guitar, keyboard and computer running Ardour, Guitarix, LMMS and the JACK audio connection kit to make music with GNOME.

Kukuh's talk

Kukuh’s talk

And Yantisa Akhadi presented OpenStreetMap’s impressive improvements in covering Asia, often leaving commercial map services like Bing or Google far behind.

Yantisa's talk

Yantisa’s talk

The second day ended with a thunderstorm. It created a refreshing breeze in the main hall and made the frogs speak up outside the hall.

Again, kudos to the organization team (great work!) and thanks to the sponsors!


This was the fourth GNOME.Asia summit I attended. Compared to GUADEC (the annual European conference), GNOME.Asia seems to have more fluctuation among attendees (as travelling can be more expensive in Asia due to its size and flight costs in comparison to costs of living?). There also seem to be more attendees that show up being curious what that international conference at the university is about, so it feels good to have some “how you can get involved” talks covering coding, documentation, translation, QA / bug triaging, engagement / marketing, …

GNOME.Asia summits also offer more talks with a regional focus. Would have loved to attend the “Open Source Software in the shoes industry” or “My experience as a farmer, trader and principle of village affairs in contributing to BlankOn” talks – unfortunately they were at the same time as my own talk.
Still it was a gift to speak with many community members while walking around, grabbing coffee or food, or just standing outside enjoying the sun.

Terima kasih.

Posted in computer, gnome, lang-en | 3 Comments

GNOME.Asia Summit 2015.

It’s that time of the year again: GNOME.Asia Summit at Universitas Indonesia in Depok (Indonesia)! On Thursday some workshops took place how to contribute to GNOME translation and documentation and how to start coding.
Today (Friday) is Day 1 of the conference.

Entrance to the main hall

Entrance to the main hall

The main hall (before opening)

The main hall (before opening)

There were welcoming speeches by the local organization team, Kat Gerasimova of GNOME, Mirna Adriani, PhD (Dean of the computer science faculty) and Aidil Chendramata (from the Ministry of Communication and Informatics).

Later today I am going to give an introduction to handling (“triaging”) bug reports in GNOME’s issue tracking system.

A big thanks to the local organization team and the many sponsors of this conference for making this possible!

Posted in computer, gnome, lang-en | Comments Off on GNOME.Asia Summit 2015.

GNOME Bugzilla: Your Bugs and your Product Overview.

Bugzilla logo by Dave Shea

  • The UNCONFIRMED bug status (which can be disabled per product) will be removed as it is mostly not used and confuses reporters. Tickets with UNCONFIRMED status will be merged into NEW status as announced on desktop-devel-list and at the top of every GNOME Bugzilla page.
    If you are a GNOME project maintainer and want to keep the UNCONFIRMED status for your GNOME Bugzilla product you can opt out until the end of February.
  • I encourage you to give the product pages and your user page a try!
    They have become more useful:
    Browse Product

    Browse Product

    • Target Milestones (if existing), Priorities (if actually used and not just kept as the “normal” default) and Severities are now listed first, to get a quick overview for those projects who might use Bugzilla to do some project planning (so far I have not seen that much though). Static information like components or versions now comes after.
    • Versions now sorts by newest versions first. You should be more interested in bugs reported in recent versions.
    • The previously shown needless NEEDINFO queries by date were moved to the side bar and merged into one query. The query results are sorted by last change.
    • In the side bar, “Bugs without a response” is a link again (though it is not exactly what it says, it’s rather a query for reports with only a single comment, hence also a mismatch between the displayed number and the search result number when you click it)
    • Moved “New Patches” into its own new “Patches” section under “New and unreviewed”. All patch related information for a project is now in a single place. Click it and review a patch!
    • The “GNOME-love bugs” query shows reports that have been recently changed first – more likely that recently changed ones are not outdated and something new contributors could work on.
    • The “activity” link next to “Git repository” could give contributors a quick idea how maintained the project is (only works if the project is hosted in GNOME Git).
    Describe User

    Describe User

    • Your patches are now listed right after “What bugs are assigned to me” and “On which bugs do I need to provide input” and above the long list of “Open issues” that you once upon a time filed. Patches now also display the summary of the corresponding bug report. (Still have to remove the useless patch ID.)
  • With above changes I’d like to make the “Browse Product” and “Describe User” pages give answers to “What is important?” and “What should I work on / review?”. I’d appreciate feedback if that’s considered helpful. For itself this works pretty well, as you can see on its product page.
  • Not yet available: I want the frontpage to look like this (thanks to jimmac for the custom icons; ignore the wrong color of the top bar):
    Potential future frontpage

    Potential future frontpage

    This was already live for a few minutes but I reverted this change as the server started cycling through cached older versions (no idea what happened), plus I have the feeling that the skin handling is still problematic (my fearless guinea pig Shaun still had Bugzilla’s “Dust” skin enabled in his user settings so things looked pretty broken). Need to make sure that everybody uses the GNOME skin before doing further custom skin changes.
  • 18 months ago I blogged a series of Bugzilla related posts. Though this focused on Wikimedia Bugzilla, there might be some helpful information or tweaks you are not aware of:
Posted in bugzilla, computer, gnome, lang-en | 10 Comments

Wikimedia’s migration to Phabricator: FOSDEM talk.

Earlier this month, Quim Gil and I gave a talk at FOSDEM:

Wikimedia adopts Phabricator, deprecates seven infrastructure tools:
First hand experiences from a big free software project on a complex migration

The talk description and the presentation slides are available. At some point there will likely also be a video (probably under 2015 and H1308).

The talk tried to cover three aspects: The decision driving process in a large distributed project, the technical and planning aspects of such a complex migration that nobody has tried before, and describing some of the functionality of the new tool (Phabricator) itself.

Posted in computer, lang-en, phabricator, wikimedia | Comments Off on Wikimedia’s migration to Phabricator: FOSDEM talk.

On product design.

…and while I was playing with GNOME’s new Bugzilla instance trying to get rid of some upstream feature bloat, I looked at upstream’s Bugzilla front page and spend the next hours wondering where to add eight more Search buttons/links/forms so it’ll become a full dozen.

Upstream Bugzilla front page with four search options

Upstream Bugzilla front page with four search options

I mean, seriously?

Posted in bugzilla, computer, gnome, lang-en | 11 Comments

GNOME Bugzilla upgraded to 4.4.

Bugzilla logo by Dave Shea

Dear GNOME community, you all owe Krzesimir Nowak, Andrea Veri, and Olav Vitters some icecream and drinks: The Bugzilla software running on has been upgraded to the latest stable version available.

So much for the general information that I am aware of.

And some smaller stuff that I was into

I was confused that some people saw me as a point of contact for the Bugzilla upgrade, as I did nothing apart from testing, some smaller tweaks, and providing grumpy input and feedback. Though I admit that lately I have performed some smaller taxonomy changes unrelated to the actual migration though:

…and some smaller testing and simple tweaks in Bugzilla itself on its way to 4.4:

  • Common links on the frontpage: “Reported by and assigned to me”, “Created in last 5 days”, “Changed in last 5 days”. Maybe more to come, let’s see (the frontpage still has too much unhelpful stuff).
  • The Patch Report shows the author and size of patches now (bug 675822). Maybe you are more motivated to review a patch if it’s a small chunk and if it’s an unknown contributor, or one that you trust?
  • The list of your patches on your user page now displays the summary of the bug report.
  • Improved and added some stock answers for triagers.
  • Gerrit IDs in comments now automatically link to the commit (thanks to a hacking session with Olav; bug 559537). Requirement: Your Git repository name needs to match your Bugzilla product name.

Vague personal future ideas for GNOME Bugzilla

  • Best development practices:
    As I don’t see someone driving a discussion process to move GNOME to different (better?) infrastructure tools soon, I would like to make the custom “Browse product” and “Describe user” pages more useful for users to get an overview what’s there to work on and what is relevant (high priorities, new patches, target milestones) in a project. Many projects don’t really use Target Milestones or Priorities so far though I’m convinced it can be helpful if the tool properly supports you.
    Regarding practices, I’d also discourage setting a default human assignee instead of a virtual assignee for components so the list of assigned bugs per user is actually what you yourself really plan to work on.
    Furthermore, you probably do not want to set a default target milestone for the next version. It is just unrealistic and does not allow you to plan properly.
    All such stuff, you know.
  • Maintainers can be encouraged to disable old versions and target milestones: Dropdown lists become shorter. (Though not too short because users might still want to report issues in older versions. You do not help reporters if you disable the version they use – they might still report their bug but just not set the Version correctly.)
  • Remove the “URL”, “Tags”, “Hardware” fields in bug reports. Feature creep.
  • Another area that welcomes improvement is avoiding cookie-licking. Your user page lists the tasks which are assigned to you. Do you realistically plan (means: rough timeframe and actionable steps identified, and not just some “would be good” feeling) to work on those tickets assigned to you? Also, your patches are listed there.
    Bugzilla also offers an overview list of open tasks per assignee (might load slowly) to see the full situation.
  • A cronjob to dump taxomony changes into an email sent to Bugzilla maintainers as I am interested in consistency.
  • Split the “docs” components of products into “User documentation” and “Developer documentation” components so it is easier for doc contributors to find tasks to work on. To discuss on d-d-l.
  • Disable the “reviewed” patch status. It means nothing. Either a patch needs more work, or it is ready to go. To discuss on d-d-l.
  • As the section heading says: Those are just ideas. They require discussion and time but you are very welcome to steal these ideas from me.

But what ever the future brings (or not):
You all owe Krzesimir Nowak, Andrea Veri, and Olav Vitters some icecream and drinks.

Posted in bugzilla, computer, gnome, lang-en | 4 Comments

Wikimedia in Google Code-in 2014

Google Code-in 2014

Google Code-in 2014

Google Code-in is an annual contest for 13 and 17 year old students. They get introduced to contributions which make free and open source software (FOSS) development happen.
For the second time in December 2014 and January 2015, Wikimedia was proud to be one of the 12 mentoring organizations which provided tasks that students could choose to work on. Students who complete tasks receive a certificate and t-shirt from Google.

In those seven weeks, 48 students successfully completed 226 Wikimedia tasks, supported by 30 mentors from the community. Tasks are not only about dealing with code but also about documentation, research and testing. The variety of achievements is huge:

Task statistics per week

Task statistics per week

It’s been satisfying (and a little addictive too) to see your changes merged into a project used by millions, as Unicodesnowman, one of the participating students, writes.

Check out how you can contribute to Wikimedia and the list of easy software bugs to start with.

Thank you and congratulations to all the students who became part of Wikimedia and joined and supported its mission to freely share knowledge. You have done awesome work! Special congratulations to Wikimedia’s two Grand Prize Winners Danny Wu and Mateusz Maćkowski and to our finalists Evan McIntire, Geoffrey Mon and Pranav Kumar!

Thank you to all our mentors and their commitment, coming up with task ideas and spending time on weekends to work together with students and quickly review their contributions.

And last but not least, thank you to Google for organizing and running this contest, creating awareness of and interest in Free and Open Software projects. The full list of winners and finalist across organizations has been published.

Posted in computer, lang-en, wikimedia | Tagged | Comments Off on Wikimedia in Google Code-in 2014