Wikimedia in Google Code-in 2014: The first week

Wikimedia takes part in Google Code-in (GCI) 2014. The contest has been running for one week and students have already resolved 35 Wikimedia tasks. You can help making that more (see below).

Google Code-in 2014

Some of the achievements:

  • Citoid offers export in BibTeX format (and more contributions)
  • Analytics’ Dashiki has a mobile-friendlier view
  • Echo‘s badge label text has better readability; Echo uses the standard gear icon for preferences
  • Wikidata’s Wikibase API modules use i18n for help/docs
  • Two MediaWiki extensions received patches to not use deprecated i18n functions anymore
  • MediaWiki displays an error when trying to create a self-redirect
  • The sidebar group separator in MediaWiki’s Installer looks like in Vector
  • The Wikimedia Phabricator docs have video screencasts and an updated Bug report life cycle diagram
  • Huggle‘s on-wiki docs were updated; exceptions received cleanup
  • Pywikibot‘s replicate_wiki supports global args; optparse was replaced by argparse
  • Reasons for MediaWiki sites listed as defunct on WikiApiary were researched
  • Wikimedia received logo proposals for the European Wikimedia Hackathon 2015
  • …and many more.

Sounds good? Want to help? Then please spend five minutes to go through the tasks on your to-do list and identify simple ones to help more young people contribute! Got an idea for a task? Become a mentor!

Posted in lang-en, wikimedia | 3 Comments

Wikimedia in Google Code-in 2014

At work I spent the last weeks mostly working on preparing Wikimedia’s move from Bugzilla to Phabricator which successfully happened last weekend after ~7 months of planning (worth another blog post) and preparing Wikimedia’s participation in Google Code-in (GCI) 2014 (specific steps are listed in the corresponding task in Phabricator). Eventually, Wikimedia got accepted by Google as one of the twelve Free and Open Source organizations taking part in GCI.

Google Code-in 2014

GCI is a contest for 13-17 year old students and starts on December 1st. Students are offered tasks that should take an experienced contributor (knowing the toolchain and infrastructure) up to four hours. Tasks can be about code, documentation, QA, training, outreach, user interface and research. Wikimedia has a central planning and information wikipage.

Last year Wikimedia ended up with 273 tasks, 46 students, and approximately 30 mentors in GCI. The results were above our expectations (as I was initially sceptical if Wikimedia had enough resources). Based on the common questions that students had we improved our onboarding documentation for new contributors (not only GCI students) and our instructions for GCI mentors. Hence Wikimedia is better prepared than last year: So far we have approximately 200 tasks available (not all of them will be available to students immediately) and 24 mentors. Still we need way more tasks and mentors for the next six weeks!

Become a mentor!

If you are active in the Wikimedia community, have that small task on your To-Do list that you haven’t managed to work on yet, and can imagine mentoring a student: Check out our mentor’s corner, register, and create your task!

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

Locally installing Phabricator on Fedora 20

Phabricator project logo

Uhm, no blog post for ages. Work and university kept me way busier (and less energetic to do much other things) than expected.

As announced in May 2014, Wikimedia will replace Bugzilla with Phabricator very soon for issue tracking. The Wikimedia Phabricator production instance is up and running and the migration from Bugzilla and RT is the next step on our migration timeline. A comparison between Bugzilla and Phabricator and documentation are available.

Time to publish my quick notes about installing Phabricator locally on a Fedora 20 machine. Maybe it’s useful for somebody, maybe not.

Phabricator’s official installation guide is pretty wonderful so I’ll only cover what I, being a simple user avoiding to think on his own and just blindly following guidelines, still had to do (which might be very obvious to tech-savvy users). I expect you to know that systemctl restart httpd.service, systemctl restart mysql.service and more /var/log/httpd/error_log are your friends.

  • First of all, I got the raw content of a php file displayed in my browser. Obviously I had to install the php package first. Heh.
  • Phabricator complained about the undefined function mysql_real_escape_string – the package php-mysqlnd was not installed.
  • The next and last problem not covered by documentation was Request parameter ‘__path__’ is set, but empty. Your rewrite rules are not configured correctly. The ‘__path__’ should always begin with a ‘/’. This required changing the corresponding RewriteRule in /etc/httpd/conf/httpd.conf to have a slash in front of $1.
  • Going to in your browser should now allow you to set up your admin account.
  • To get greeted with less “unresolved setup issues”: sudo yum install php-mbstring php-gd php-pecl-apcu.

In the end, my httpd.conf file looked like this:

<VirtualHost *>
  DocumentRoot /var/www/html/phab/phabricator/webroot
<Directory "/var/www/html/phab/phabricator/webroot">
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
  RewriteEngine on
  RewriteRule ^/rsrc/(.*)    -                       [L,QSA]
  RewriteRule ^/favicon.ico  -                       [L,QSA] 
  RewriteRule ^/(.*)$       /index.php?__path__=/$1  [B,L,QSA]
  ErrorLog /var/log/httpd/error_log
Posted in lang-en, phabricator | Comments Off on Locally installing Phabricator on Fedora 20

Business as usual.

No surprises:


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

Posted in computer, gnome, lang-en | Comments Off on Business as usual.


Tea, Cake, Research and Hardcore.

Tea, Cake, Research. Hardcore invisible.

Posted in lang-en, non-technical | Comments Off on Weekends.

GNOME.Asia Summit 2014


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.

Posted in computer, gnome, lang-en | 1 Comment

RE: Outreach Program for Women

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.


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)?


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 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.

Posted in computer, gnome, lang-en, politics | Comments Off on RE: Outreach Program for Women

GNOME.Asia Summit 2014: Docs & Bugs


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.

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

Wikimedia to migrate its Product Management Tools to Phabricator

Slightly more correct title might be “Wikimedia to migrate its software development product/project code review issue tracking management planning tools to Phabricator”. Or something like that.

The problem

The Wikimedia technical community has used plenty of different tools for tracking bugs / product management / project management / todo lists. Bugzilla, RT, Gerrit, Mingle, Trello, Scrumbugs, Google Docs, to mention most of them.
From my personal point of view, Wikimedia Foundation is pretty bottom-up: Each team can experiment and use those tools they prefer and suit them. That also means teams might have moved from Bugzilla to Trello to Mingle to Google Docs while other teams prefer(ed) other tools. Bugzilla is our public issue tracker but misses a lot of functionality when it comes to agile development workflows, design review work, or activity feeds.

We also have some connectivity between these tools. Bingle/Bugello to sync some parts between Bugzilla and Mingle/Trello, or its-bugzilla (previously “bugzilla-hooks”) to have Gerrit post comments in Bugzilla tickets about related patches (if the bug number was correctly refered in the commit message). But things are brittle – for example, just this Friday the Gerrit→Bugzilla notifications broke.
All in all, the multitude of tools and channels is not helpful for cross-team collaboration, keeping track of what’s happening, and transparency of discussions and decisions in general as things are discussed in several places.

The idea

In late 2013, the idea was to start a discussion about a possible agreement on a recommendation for a smaller set of tools that teams could agree upon. My colleague Guillaume and I had the pleasure to facilitate the discussion and to ensure it doesn’t remain an idea only. References were a previous evaluation attempt in 2009/2010 and the Gerrit evaluation in 2012.

The steps

The first step was asking interested teams and individuals to describe their needs and workflows on a wiki discussion page.
Its content was then consolidated by Guillaume and cleaned up a little bit more by me. (I felt reminded of GNOME’s decision process to migrate from Subversion to Git but that was a survey among GNOME foundation members and hence a very different approach.)

After having those (sometimes contractive) needs and workflows collected, we tried to decrease the items in the list of candidate tools to consider, plus investigate and encourage discussing them on the related discussion page. For candidate tools not having an online test instance offered on the project’s homepage we wondered whether to set up test instances on Wikimedia Labs to make testing easier, but we left it to anybody strongly favoring a tool to set up that tool. Wikimedia Deutschland already had Scrumbugs instance in production (Scrum on top of Bugzilla) we could point to, and for Phabricator somebody had set up a test instance in Wikimedia Labs already.

To gather the broader community opinion and broader support for investigating more potential (wo)manpower, we started to prepare a Request for comments (RFC). While we listed several options at the beginning (Keep the status quo; status quo+Fulcrum; status quo+Scrumbugs; move completely to Phabricator; move partially to Phabricator; move to GitLab) the feedback quickly turned this into one question to ask the community: Move to Phabricator?
We ran this RFC for three weeks until May 6th and announced it widely on mailing lists and via banners on top of Bugzilla and

Parallel to running the RFC, we were working on sorting out the blockers for a potential migration from Bugzilla and documenting things. My colleague Quim created a comparison page between Phabricator and Bugzilla.

The decision

Phabricator project logo

The result of the RFC is that there seems to be general support for moving from our infrastructure tools to Phabricator. This won’t all happen at the same time though – we will start investigating replacing Bugzilla, RT, Trello, Mingle.
For the code review functionality (currently done via Gerrit), more work in Phabricator is needed to fit the needs defined by our community, for example when it comes to Continuous Integration. We do not plan to switch off Gerrit on the day we start using Phabricator in production and we got more items to sort out (see the list of code review related items).

For managing the project to move to Phabricator we use the Phabricator test instance itself (dogfooding for the win), by tracking missing features compared to our existing tools, and tasks that need to be solved for the migration. Also, we asked users of existing tools what they would specifically miss in Phabricator by creating (sub)tasks in our Phabricator test instance.

We have not created a Phabricator production instance yet to which we would potentially migrate to, because in the past Wikimedia ended up with a lot of tools by not enforcing migration.

Spreading the word and resource allocation

For the last months we also ran IRC office hours every two or three weeks in order to discuss and answer questions related to the project.

Last weekend the Wikimedia Hackathon took place in Zürich. There were several Phabricator related sessions (videos available for the sake of transparency; the first two videos are more like discussions though):

  1. A general quick introduction to Phabricator by my colleague Shahyar
  2. A discussion among ~10 people of what needs to be sorted out and done for Day 1 of Phabricator in production (being tracked in this Phabricator project board), plus related stakeholders and who’s going to work on what.
  3. A session by Shahyar specifically explaining the code review concept and tool in Phabricator (remember: we do not plan to switch from Gerrit to Phabricator for code review on the first day)

Current status and next steps

  • General and central information page about Wikimedia’s Phabricator instance.
  • Planning board for Wikimedia Phabricator Day 1 in Production (You see several columns here: ‘Need discussion’ needs more thoughts first until we know how to solve those tasks; ‘Ready to Go’ are tasks for which the way forward is clearly defined and somebody could start working on them; ‘Waiting for upstream’ are tickets that we have reported to upstream; ‘Doing’ is what is currently actively being worked on.)
  • The team working on Wikimedia Phabricator and the stakeholders are defined. We have tasks such as investigating migrating Bugzilla and RT data to Phabricator, plus implementing missing functionality like restricting access to certain projects by default (like for Bugzilla’s “Security” product or RT’s procurement queue) via namespaces. The WMF Technical Operations team will set up low-level infrastructure and puppetize our Phabricator instance. We have stakeholders defined to keep in contact with the team of Product Managers and the Platform and Release Engineering/QA team, we have more interested stakeholders which will provide input to help making decisions and driving things forward, and I am happy to also see volunteers being interested to get involved by diving into the code.
  • To track the tasks that Wikimedia is interested in in Phabricator’s upstream task tracker, we have a “Wikimedia” project in upstream Phabricator and the corresponding planning board.

The usual disclaimer: Plans might be subject to change and there is intentionally no timeline yet.

How you can help

Check out the Get involved section on the central project page and the planning board for Wikimedia Phabricator Day 1 in Production if there are tasks that interest you!


I would like to thank everybody in the community who has provided input, help and support. Upstream Phabricator developers have been extremely responsive and interested in discussing our needs and fixing issues – it’s a great pleasure to work with them.
Furthermore, getting to this point would have been impossible without my wonderful colleagues in the Wikimedia Engineering Community Team who have helped so much with communication, prioritization, planning, support.

Posted in bugzilla, computer, lang-en, wikimedia | Comments Off on Wikimedia to migrate its Product Management Tools to Phabricator

Wikimedia’s Road to Bugzilla 4.4

(How we puppetized, upgraded and moved Bugzilla to another server)

Though we currently also evaluate Wikimedia’s project management tools, we will have to stick with our current infrastructure for a while. Among many other tasks, I spent the last months preparing the upgrade of Wikimedia’s Bugzilla instance from 4.2 to 4.4. Some reasons for upgrading can be found in this Bugzilla comment.

In late November 2013 I started by cleaning up Wikimedia Bugzilla’s custom CSS which was copied about five years ago and not kept in sync. It turned out that 16 of 22 files could be removed as there was no sufficient difference to upstream’s default CSS code (Bugzilla falls back to loading the default CSS file from /skins/default if no custom CSS file is found in /skins/custom). Less noise and less diffing required for future upgrades. In theory.

After testing these CSS changes on a Wikimedia Labs instance and merging them into our 4.2 production instance, I created numerous patches and put them into Gerrit (Wikimedia’s code review tool) by diffing upstream 4.2 code, upstream 4.4 code, and our custom code.

At the same time, Wikimedia’s Technical Operations team wanted to move the Bugzilla server from the kaulen server in our old Tampa datacenter to the zirconium server in our new Ashburn (Eqiad) datacenter. While you’d normally prefer to do only one thing at a time, Daniel Zahn (of Technical Operations) and I decided to create a fresh Bugzilla 4.4 instance from scratch on the new server to see into which problems we would run. During this process Daniel Zahn turned the old setup on kaulen, which was largely manual and had organically grown over the years, into a proper Puppet module. For every “missing module” error we ran into we avoided installing anything from Perl’s CPAN in Bugzilla’s /lib folder and ensured we just rely on distribution packages, for a much cleaner install. Daniel Zahn installed the needed packages by adding them to puppet code. While doing this we also removed Bugzilla’s Sitemap extension as it created sporadic Search::Sitemap errors when running Bugzilla’s (plus it’s unmaintained anyway). Furthermore I ran into another runtime error to fix.

After fixing all issues and having Bugzilla accessible via a web browser, only Bugzilla’s upstream CSS was displayed instead of our custom CSS. Neither was Wikimedia’s custom CSS offered as an option in the browser, nor could I log into the new Bugzilla (to check which theme is set as default in the admin settings) as the database dump we used for testing predated the creation of my user account.

After Sean Pringle of Technical Operations deployed a more recent Bugzilla database dump I expected further problems due to upstream changes to CSS loading. I was happy to see that I had been wrong: No problems with our custom CSS theming anymore. Instead, I ran into problems with our custom “See Also” field changes: Adding and removing such URLs triggered errors, and URLs themselves were not displayed (but their corresponding “Remove” checkbox). Thanks to upstream help in #bugzilla on Mozilla IRC I finally found out that Perl’s use base instead of use parent was the culprit.

After creating symlinks to /extensions/WeeklyReport/ to avoid 404 errors for the “Weekly Bug Summary” link in the sidebar (our setup is slightly busted) and after fixing two problems with our cronjobs for whining and data collection we agreed on a date to copy the database, do some maintenance work, and switch the DNS entry. This was announced one week in advance by adding a banner to Bugzilla via its announcehtml parameter.

A few hours before the switch on February 12th 2014, Daniel lowered the Time-to-live (TTL) values of the DNS entry of our Bugzilla. When the migration started, I set Bugzilla’s shutdown parameter to make the web UI inaccessible and also the WebService API return a 503 error for the Bingle script that syncs Bugzilla with Wikimedia’s Mingle instance. This was important to make sure that nobody can write anymore to the old database. We updated the IRC channel topic in #wikimedia-tech to tell that Bugzilla is under scheduled maintenance and logged the action in #wikimedia-operations so it got added to Wikimedia’s Server admin log. All in all we had only forgotten two minor things: Our Gerrit integration (a bot adding Gerrit notifications about related patches as comments in Bugzilla) bot was not able to write and got a 503 error back – Chad quickly disabled it. And our Nimsoft watchmouse sent an “ALERT! Bugzilla: Service Temporarily Unavailable” message to the Operations mailing list.

Sean Pringle migrated the old database from db9 in Tampa, to a new database on db1001 in Eqiad. After this was done, Daniel Zahn ran to apply the scheme upgrades needed for 4.4.

After 30 minutes of testing to make sure everything works as expected we deployed two more custom patches: Showing common queries on the frontpage and making saved reports work. While having the downtime I also switched off bugmail to do some mass-changes without spamming everybody: I merged some version numbers in the “MediaWiki” product to have a shorter Version dropdown, removed the wikibugs-l watcher account from some bug reports as it is unneeded (set as a global watcher in Bugzilla anyway, hence a potential issue if a ticket was moved to a restricted product like “Security” still triggering public bugmail).

A few minutes before the end of the announced downtime of three hours, Daniel switched DNS so the new Bugzilla on the new server became available to the public. A few hours later, to work around isses for clients not supporting SNI, Daniel changed the order in which Apache loads virtual hosts. This ensures that older clients like Internet Explorer on Microsoft Windows XP will always get to see Bugzilla instead of other miscellaneous web services sharing the same hardware. I had also overlooked a small UI issue that I fixed two days later.

Now that all is done, the result can now be seen on All steps to upgrade Wikimedia Bugzilla from 4.2 to 4.4 were documented on a wiki page. You can find all of our custom modifications here.

Posted in bugzilla, computer, lang-en, wikimedia | Comments Off on Wikimedia’s Road to Bugzilla 4.4