Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

Posts by Guillaume Paumier

Wikimedia engineering report, June 2014

Major news in June include:

Note: We’re also providing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.

Wikimedia engineering report, May 2014

Major news in May include:

Note: We’re also providing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.

On our way to Phabricator

Later this year, we’ll say good-bye to Bugzilla, our bug tracking platform, and migrate its content to another software called Phabricator. This will be an opportunity to centralize our various project and product management tools into a single platform, making it easier to follow technical discussions you’re interested in. This is the result of a six-month community review and discussion that identified requirements, evaluated options and decided on Phabricator.

What does this mean for me?

Bug reports and feature requests are listed as “tasks”, in an attractive interface not too different from Bugzilla’s.

If you’re a casual reader of Wikipedia and its sister sites, nothing will change (except maybe the rate at which you see improvements to the site, if our productivity increases).

If you’re an editor on a Wikimedia wiki, we expect this change to make your life easier, if you sometimes report bugs, request new features or participate in other technical discussions:

  • You’ll be able to use your SUL username to log into Phabricator;
  • No more having to go through half a dozen different tools to follow what’s happening on a specific bug or feature you’re watching: eventually, everything will be in one place.
  • Existing bug reports will be migrated to the new tool, and most links will continue to work; they will redirect to the bugs’ new location.
  • You’ll need a little time to adjust to this new tool, but hopefully Phabricator’s modern interface will make it easier for you to report bugs and participate in technical discussions.

If you’re more involved in the Wikimedia technical community, you’ve probably already participated in the discussions that have led to this decision. If you have other questions, you can ask them on the help page.

Why are we moving?

Since we started to use Bugzilla, the size of our technical community has dramatically increased. There are now dozens of developers, engineers, designers, tools maintainers, bot owners, project and product managers, etc. (not yet counting the hundreds of users regularly reporting bugs and participating in technical discussions).

It’s easy to see how a single tool with a limited scope (bug tracking) may not be able to meet the needs of all members of our technical community. Therefore, over the years, we’ve started to use other tools to complement Bugzilla in the areas of code review, project and product management, and quality assurance.

This had led however to a proliferation of scattered tools that barely talked to each other; engineers wrote scripts to keep some of them synchronized, but this wasn’t an ideal solution. Discussions about a single technical issue could be split across Bugzilla, Gerrit, Trello, Mingle and/or Scrumbugz. It was difficult for developers, and even more so for casual users.

Phabricator solves this problem by offering all those features under a single unified umbrella; eventually, everything will be in one place, tightly integrated and neatly organized. Initially, we’ll focus on bug tracking and project management, but we’re planning to also use it for code review once the features we need have been added.

How was this decided?

Phabricator notably includes a project management feature, allowing users to organize tasks in “boards” familiar to developers using the Agile methodology.

In late 2013, the Wikimedia Foundation started to facilitate a community review of all the project management tools then in use in the Wikimedia technical community. Developers, engineers and anyone who identified as a stakeholder in this discussion was invited to provide input and share their use cases, needs and usual processes. After this consultation period, this input was summarized into consolidated requirements.

A list of options was proposed, and discussed by the community to only keep those that were true contenders, based on our requirements.

Phabricator emerged as the only real challenger to the status quo. After a three-week request for comment, the technical community had weighed in the costs and benefits, and expressed an interest in moving to Phabricator. There were still a few issues and missing features to iron out, as well as a carefully-prepared migration plan to put in place, but overall the feeling was that once those had been resolved, there wouldn’t be any social blockers.

The Wikimedia Foundation is now preparing for the migration, and your help is much welcome. You can get involved directly in our test instance of Phabricator, that was originally set up just for testing, but that later became home to the migration project itself in order to become more familiar with the software.

When will this happen?

The migration plan gives an overview of the current timeline. There’s still work to be done, and Wikimedia engineers are working closely with the Phabricator development team, who’s been very responsive and open to collaboration. Together, they’re making sure that the features we need are present, and that we can adapt the software to our various workflows.

The current plan is to deploy a bare bones Phabricator instance with only Wikimedia SUL enabled, and make a first community call to test only the login process. The next step will be to deploy the Trusted User Tool required by the Legal and Community Advocacy team to keep track of agreements signed by community members. These steps will help guaranteeing a successful Day 1, when Phabricator will become the new driver of our development infrastructure.

On the Wikimedia side, Andre Klapper is leading the migration project, Mukunda Modell is lending his Phabricator expertise and Chase Pettet is handling the Operations side. You can read Andre’s retrospective on the review process and the road ahead. You’re also encouraged to follow the progress of the migration (dubbed “Wikimedia Phabricator Day 1″) on the dedicated page, the tracking item and its associated board in our test instance.

Guillaume Paumier, Technical communications manager

Wikimedia engineering report, April 2014

Major news in April include:

Note: We’re also providing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.


Tech wizards behind Wikipedia meet in Zürich for hackathon

The Zürich hackathon is an opportunity for developers to collaborate more closely, and also to socialize with comrades whom they otherwise mostly interact with online.

More than 150 developers, engineers, sysadmins, and technology enthusiasts have gathered in Zürich this week-end for the annual European Wikimedia hackathon, organized by Wikimedia CH, the local Wikimedia chapter.

Coming from more than 30 countries, their goal is to fix software bugs, share knowledge about new and existing technologies, add new features, and generally to improve the technical infrastructure and tools on which Wikipedia and its sister sites rely.

The Wikimedia technical community is largely disseminated across the globe; Events like the Zürich hackathon are opportunities for developers to collaborate more closely, and also to socialize with comrades whom they otherwise mostly interact with online.

One of the main topics of interest during this event is MediaWiki-Vagrant, a portable MediaWiki development environment that makes it easy to learn about, modify, and improve MediaWiki’s code. In Zürich, developers are teaching each other how to use this tool, as well as automating it further.

Participants are discussing and coding on a variety of topics ranging from maps to development environments, to Wikidata, and many more.

Another topic of interest is Flow, the new discussion system poised to replace the antiquated “talk pages” where editors discuss how to improve Wikipedia articles and other pages. Flow brings a more modern and user-friendly experience, as well as many features that users have now come to expect of online discussion tools.

Maps are also attracting a lot of participants, who want to join forces and combine efforts to offer a unified user experience across various tools that display maps. Examples include maps embedded in Wikipedia articles, Wikivoyage travel guides, and mobile apps that combine maps with text to show location-aware content.

These are just a few of the pieces of technology that participants are excitedly discussing and coding on, along with Wikidata, improvements to the development toolchain, VisualEditor, automated code testing, and many more.

The hackathon is now in its second day and will continue until tomorrow. You can follow some of the sessions remotely by watching them live or recorded. You can also interact with participants on the #wmhack channel on Freenode IRC, or on Twitter using the #wmhack hashtag.

Guillaume Paumier, Technical communications manager

Wikimedia engineering report, March 2014

Major news in March include:

  • an overview of webfonts, and the advantages and challenges of using them on Wikimedia sites;
  • a series of essays written by Google Code-in students who shared their impressions, frustrations and surprises as they discovered the Wikimedia and MediaWiki technical community;
  • Hovercards now available as a Beta feature on all Wikimedia wikis, allowing readers to see a short summary of an article just by hovering a link;
  • a subtle typography change across Wikimedia sites for better readability, consistency and accessibility;
  • a recap of the upgrade and migration of our bug tracking software.

Note: We’re also providing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.


A young developer’s story of discovery, perseverance and gratitude

This post is a discovery report written by Jared Flores and slightly edited for publication. It’s part of a series of candid essays written by Google Code-in students, outlining their first steps as members of the Wikimedia technical community. You can write your own.

When I initially heard of the Google Code-In (GCI) challenge, I wasn’t exactly jumping out of my seat. I was a little apprehensive, since the GCI sample tasks used languages such as Java, C++, and Ruby. While I’ve had my share of experience with the languages, I felt my abilities were too limited to compete. Yet, I’ve always had a fiery passion for computer science, and this challenge presented another mountain to conquer. Thus, after having filtered through the hundreds of tasks, I took the first step as a Google Code-In student.

The first task I took on was to design a share button for the Kiwix Android app, an offline Wikipedia reader. Though Kiwix itself wasn’t a sponsoring organization for GCI, it still provided a branch of tasks under the Wikimedia umbrella. With five days on the clock, I researched vigorously and studied the documentation for Android’s share API.

After a few hours of coding, the task seemed to be complete. Reading through the compiler’s documentation, I downloaded all of the listed prerequisites, then launched the Kiwix autogen bash file. But even with all of the required libraries installed, Kiwix still refused to compile. Analyzing the error logs, I encountered permission errors, illegal characters, missing files, and mismatched dependencies. My frustration growing, I even booted Linux from an old installation DVD, and tried compiling there. I continued this crazy cycle of debugging until 2 am. I would have continued longer had my parents not demanded that I sleep. The next morning, I whipped up a quick breakfast, and then rushed directly to my PC. With my mind refreshed, I tried a variety of new approaches, finally reaching a point when Kiwix compiled.

With a newly-found confidence, I decided to continue pursuing more GCI tasks. Since I had thoroughly enjoyed the challenge presented by Kiwix, I initially wanted to hunt down more of their tasks. However, finding that there weren’t many left, I gained interest in Kiwix’s supporting organization: Wikimedia. I navigated to Wikimedia’s GCI information page and began familiarizing myself with the organization’s mission.

“We believe that knowledge should be free for every human being. We prioritize efforts that empower disadvantaged and underrepresented communities, and that help overcome barriers to participation. We believe in mass collaboration, diversity and consensus building to achieve our goals. Wikipedia has become the fifth most-visited site in the world, used by more than 400 million people every month in more than 270 languages.” – About Us: Wikimedia (GCI 2013)

Reading through the last sentence once more, I realized the amazing opportunities that were ahead of me. Whenever I needed to touch up on any given topic, Wikipedia was always one of the top results. Moreover, Wikipedia had become a source of entertainment for me and my friends. We always enjoyed hitting up a random article, then using the given links to find our way to Pokémon, Jesus, or maybe even Abraham Lincoln: Vampire Hunter.

Eager to begin, I chose video editing as my second task for Wikimedia. I began the long endeavor of watching, reviewing, and editing the two forty-five minute clips. Despite the lengthy videos, I was quite amused in seeing the technical difficulties that the Wikimedia team encountered during their Google Hangout. It was also comforting to put human faces behind the Wikimedia mentors of Google Code-In.

As with my first task, the work itself sped by quickly. But also similar to Kiwix, I encountered some difficulties with the “trivial” part of the task. I had never worked with the wiki interface before, so the wiki structure was somewhat foreign. I only had a vague idea of how to create a page. I also didn’t know where to upload files, nor did I know how to create subcategories. Nonetheless, after observing the instructions in Wikipedia’s documentation, I finally managed to upload the videos. Marking the task as complete, I scouted for my third GCI task.

Unbeknownst to me, my third task for Wikimedia would also prove to be the most challenging so far. Since this task required me to modify the code, I requested developer access. With the help of Wikimedia’s instructions, I registered myself as a developer, generated a private key to use with their servers, and proceeded to download the source code.

Though my experience with Git was quite basic, MediaWiki provided an easy to follow documentation, which aided greatly in my efforts to download their repository. As I waited for the download to complete, I quickly set up an Apache server for a testing environment. Configuring the MediaWiki files for my server, I began the installation. Fortunately, MediaWiki’s interface was quite intuitive; the installer performed flawlessly with minimal user input.

“Off to a good start,” I chuckled quietly to myself, a grin spreading across my face. And with that statement I tempted fate and my troubles had begun. Upon opening the code, I realized I couldn’t easily comprehend a single line. I had worked with PHP but the code was more advanced than what I had written before.

Running my fingers through my hair, I sighed in exasperation. I spent the next few hours analyzing the code, trying my best to decipher the functions. Suddenly, patterns began appearing and I began to recognize numerous amounts of functions. I started to tinker with different modules until the code slowly unraveled.

Finally formulating a solution, my fingers moved swiftly across the keyboard, implementing the code with ease. Confident that I had tested my code well, I followed the instructions written in the GCI’s task description, and uploaded my very first patch to Gerrit.

I was surprised at how simple the upload was. But what especially surprised me was the immediate feedback from the mentors. Within a few minutes of the upload, MediaWiki developers were already reviewing the patch, making suggestions for improvement.

Thankful for their helpful input, I worked to implement the changes they suggested. Adding the finishing touches, I was ready to upload another patch. However, I was unsure if I should upload to a new Gerrit, or if I should push to the same patch as before. Unclear about the step I should take, I made the rookie error of uploading to a new Gerrit commit.

My mistake quickly received a corrective response from Aude via the Gerrit comment system. While I initially felt embarrassed, I was also relieved that I didn’t have to work alone. In fact, I was thankful that the MediaWiki collaborators taught me how to do it right.

Checking out the link Aude had given me, I learned to squash the two commits together. However, when I tried to follow Aude’s instructions, I somehow managed to mix someone else’s code with my own. What’s even worse was I already pushed the changes to Gerrit, exposing my blunder publicly.

Had it been any normal day, I would’ve just been calm and tried my best to fix it. But it just so happened to be the Thanksgiving holiday (in the United States). I had to leave in a few minutes for a family dinner and I couldn’t bear the thought of leaving my patch in a broken state.

I felt about ready to scream. I abandoned my Gerrit patch, and navigated to the task page, ready to give up. But just as I was about to revoke my claim on the task, I remembered something Quim Gil had told another GCI student:

“They are not mistakes! Only versions that can be improved. Students learn in GCI, and all of us learn every day.”

Remembering this advice, I cleared my mind, ready to do whatever it would take, and learn while I was at it. And like an answer to my prayers, Hoo Man, another developer, posted a comment in Gerrit. He guided me through how I could return to my original patch and send my new improvements through. And more importantly, he motivated me to persevere.

I came into GCI as a passionate, yet undisciplined student. I’m thrilled that in joining this competition, the Wikimedia open source community has already helped me plant the seeds of discipline, perseverance, and collaboration. It’s no coincidence that my hardest task thus far was staged on Thanksgiving. Every year I express gratitude towards friends and family. But this year, Google Code-In and the Wikimedia community have made my gratitude list as well.

Jared Flores
2013 Google Code-in student

Read in this series:

Discovering and learning by asking questions

This post is a discovery report written by Vlad John and slightly edited for publication. It’s part of a series of candid essays written by Google Code-in students, outlining their first steps as members of the Wikimedia technical community. You can write your own.

In the past years, I’ve used Wikipedia as often as I’ve used Facebook. I’ve used it for homework or simply for finding something new. When I was first introduced to the Internet world, I always asking myself: how can someone make a site with so many people browsing it? This year, I found the answer at the Google Code-In contest. As I was browsing for a task that suited me, I found an organization called Wikimedia.

While browsing the tasks they offered, I found something that caught my eye. It was a task about editing the wiki. I was so happy that I had finally found a task that suited my tastes that I clicked “Claim Task” before reading what I had to do. But when I read more about specifics of the task… well, it is enough to say that I had no idea how to start. I was supposed to “clean up” the “Raw projects” section of the Possible projects page. I clicked the link to the wiki page I was supposed to edit, and as I started working, I encountered several problems that I will describe in a moment. But thanks to my mentor, Quim Gil, I succeeded in completing the task.

I always wanted to edit a Wiki page, but at first I was afraid. What if I did something wrong? After posting a text file on the Code-in task’s page, I received a comment that said that in the end I’d need to edit the wiki page itself, so I might as well start early. This made sense, so I dove into the unknown territory of editing.

I started by looking at the history of the page to find the things I had to add. That took a while, but in a shorter time that I first thought was necessary, I learned how to find information in earlier edits, how to edit the source code of the page and how to do minor edits on the headings and structure. But this was the easy part.

I just had to copy some names and move them to their appropriate place. However, when it came to reporting bugs, I was indeed lost. I knew from the task I had to use Bugzilla to report bugs and add comments, but I didn’t have the foggiest idea how to do it. That is when I started doing what I had to do in the first place: ask questions.

I realized that the whole point of this exercise was to teach students how to do different things, and the most important thing when learning is to ask questions everywhere: on forums, consult the FAQ or the Manual , or simply search more for the answer. So I began by reading the full Bugzilla guide, but that did not really answer my questions. At least, not until I found the “How to report a bug” guide. This gave me some important information, like what to look for and how a report should look.

But I still had one problem: the guide said a thing and the mentor said something else. So I decided to ask once more on the page of the task. In no time, I received an answer and a model. Apparently, the guide was right about one part of the task, and the mentor was right about another part. So, by combining the answers from these two sources, I managed to find the answer to my problem. Once I knew what I was looking for, and once I asked the right questions, I got the answers I needed.

From there, it was not too hard to start adding and commenting bugs on Bugzilla. The next problem appeared when I had to add the bug reports on the wiki page… I thought I was done the moment I added the bugs on Bugzilla, but again my lack of attention and knowledge got the best of me. So I told myself: If asking the right question gets me the information I need, why not ask again? After all I am here to learn.

So I went back to the task page and put another 2 paragraphs of questions. Indeed, I received the answers that helped me learn something about editing the source of the page. So I dove in once again in the unknown and started the work. After a hard time finding the bug reports again, I was finally done and I completed the task.

After finishing, I realised that a person can learn anything on his or her own, but learning is more effective if a mentor or teacher helps you. Also, a teacher that just tells you what to read and does not explain is less helpful than a teacher that knows how and what to explain, when to do it and speaks to you in a nice way, and by that helping you, like Quim Gil helped me, with explanations and examples, in completing the task.

So, to sum up, if you ever want to learn something about Wikimedia (or other things), the best way is to ask other people, be he or she a mentor like Quim Gil was for me, or a complete stranger on a forum, like StackOverflow, which is an important place for coding and scripting help. Many people say that learning has no shortcuts, but, if questions are not shortcuts, then they sure are a real help in education. Why? Because with questions come information, and with information comes knowledge.

Vlad John
2013 Google Code-in student

Read in this series:

A junior developer discovers MediaWiki

This post is a discovery report written by Coder55 and slightly edited for publication. It’s part of a series of candid essays written by Google Code-in students, outlining their first steps as members of the Wikimedia technical community. You can write your own.

I’m a 17-year-old boy from Germany interested in computer science. I write my own little programs in PHP, Python and Java and have even produced some Android apps. I completed a Python course in three days, and now I’m using Python to solve math problems. I heard about Google Code-in on a German news site for young people interested in computer science.

Account creation and language selection

The instructions for Google Code-in students were easy to understand, even for people who aren’t so good in English. After that, I created an account on The registration form looked modern; I wanted to take the user name ‘Coder55’, but it was already taken so an account creation error was displayed. The text I typed in for password and email were deleted after the error; maybe it could be saved in a session variable and written into the text fields via JavaScript.

After registering and logging in, I saw many different options in the top line. It was easy to change the language and to read my welcome message. Maybe the button with the text ‘log out’ could be replaced by a logout button with a little picture, to make the top line smaller and even easier to understand.

After that, I changed the language to German and Spanish because I wanted to see how much of the site had been translated. I was quite disappointed that only the top menu was completely translated. The left sidebar was not completely translated, even though many important links can be found there, like one to the Main Page. I was also surprised that the language of the content on the page didn’t change after I changed my language options: if I’m on the Main Page and I change the language to German, I still see the Main Page in English, although the left menu has partially changed to German. This puzzled me until I found out I had to click on ‘Hauptseite’, ‘Página principal’ etc. to see the Main Page in another language.

How to become a MediaWiki hacker

I am really interested in Developing, so the next thing I did was visiting the How to become a MediaWiki hacker page, where I found interesting tutorials that explained how to develop something on the MediaWiki platform. The page was clearly arranged and I really liked it. It clearly separated the required abilities (PHP, MySQL e.g.) and made it easy to see where I needed to learn something and where I already knew enough. The ‘Get started’ part was particularly helpful: I could start quite fast extending MediaWiki.

One thing that was missing for someone like me: example code of a really easy extension. Although all the aspects of developing are explained in detail in the Developing manual, seeing those easy extensions requires to follow several links; it would be really helpful for beginners to include and explain one or two of these examples in the manual.

I had already been programming some little programs in PHP (chat server, forum etc.) so the next thing I did was to study MediaWiki’s coding conventions; they were explained clearly and were easy to understand. The ‘C borrowings’ part was really interesting.

Around MediaWiki: API, bugzilla, git and Wikitech

Unfortunately, I didn’t find the video on the API page very helpful. The pictures were blinking and the voices hard to understand. But the rest of the API documentation was really informative and easy enough to understand.

After that, I looked at the “Development” section of the left sidebar. I visited the Bugzilla overview, and then the actual site. I really liked the idea of Bugzilla, where every developer can see where help is needed. However, if you don’t know specifically, what to look for, the search function in Bugzilla isn’t very helpful[Note 1].

I then clicked on the link called ‘browse repository’. I was positively surprised by what the site looked like. I especially liked the possibility to see which parts of MediaWiki had been just updated. I also took a look at at Wikitech; The Main Page looked really similar to Wikipedia and MediaWiki, so it seemed easy to navigate.

The Pre-Commit Checklist

On the next day, I read about how to install and configure MediaWiki. The documentation was clear and easy to read, but I didn’t understand all of it, probably because I’m more interested in developing than in hosting.

Following this, I looked into more details about developing at the Developer hub. I had already studied the coding conventions, so I started reading the Pre-Commit Checklist.

This checklist contained many questions, but for someone like me who hasn’t already uploaded code there, they are partially not understandable. The part about Testing was clearer for me because it was explained a little bit more. Maybe the questions in the checklist should be written in a little more detail, or some of the difficult words should be converted into links.

I liked having an overview over all conventions at the bottom of the page. I could easily navigate to another convention list, like the coding conventions for JavaScript. These conventions were explained in detail and with clear examples. I especially liked the part about whitespace where many rules have been written clearly and concisely.

In conclusion

MediaWiki is a very interesting platform and although some things are not perfect (e.g. translation or registering form), it is easy to join the community. The most active contributors are accessible on IRC, which makes communication easier. After discovering the technical world of MediaWiki, I’m really interested in getting involved into the community, although that will need to wait until I finish school.

2013 Google Code-in student

  1. Editor’s note: Bugzilla has since been upgraded, and its main page now features common search queries.

Read in this series:

Through the maze of newcomer developer documentation

This post is a discovery report written by David Wood and slightly edited for publication. It’s part of a series of candid essays written by Google Code-in students, outlining their first steps as members of the Wikimedia technical community. You can write your own.

This discovery essay touches on my general thoughts as I initially started to browse and look into developing for MediaWiki.

I’ve split it into three sections: Setting up, where I cover my experiences while working with pywikibot for a previous Google Code-In task; First Impressions, where I describe my thoughts as I browse the documentation geared towards newcomers; and Developer Hub, where I describe my thoughts as I venture into the actual development articles.

Setting up

Before looking to develop for MediaWiki, I had previously completed a task relating to pywikibot. I found that the mentors were very helpful and available for advice.

However, I did find issue with setting up the development environment for work on pywikibot. It seemed very complex, and at first I did not fully understand what I was required to do. For someone who hasn’t worked on large-scale projects before, such as MediaWiki, I was confused as to why it was required to have so many accounts and things set up beforehand, such as a Gerrit account.

Although I now understand, I feel that a guide explaining to newcomers, not necessarily new to collaboration with git, but to using less known tools such as Gerrit, why they are necessary, would be helpful. And although I understand that in some cases not much can be simplified as setup is complicated, perhaps a more in-depth guide would help as well (keep in mind, this is referring to the guide for installing pywikibot, and the guide for MediaWiki in general may be better).

First impressions: a guided tour for newcomers

Coming from only basic experience with a small project within MediaWiki, I was pleasantly surprised with the quality of the information and simplicity of it from the How to become a MediaWiki hacker page. There was a lot of information, for example, instead of simply telling the reader that they required knowledge in PHP, MySQL and JavaScript, the guide went on to link them to where they could gain such knowledge.

From there, I went to read A brief history and summary of MediaWiki. This was especially interesting as not only was it a engrossing read, it also helped the user understand the principles under which MediaWiki is developed, such as the fine line between performance and functionality. Such information helps a new user, such as myself, understand the goals behind MediaWiki and the mindset in which I should be working.

Another pleasant surprise was that even the more technical articles, such as Security for Developers, were written in plain English, without a lot of technical language. And even where it got technical, it was explained well. Guides that have a lot of importance, such as this one relating to Security, benefit even more from being simple for newcomers than most, as it’s more likely then that a newcomer would understand and implement what they’ve learnt.

Another note I made was that all the links that would be relevant to newcomers, such as Coding Conventions, were all easily found.

Developer Hub: What next?

My next stop was the Developer Hub, where I found that I wasn’t sure how exactly to proceed. There, unlike the last article, didn’t seem to be a clear path to follow when traversing the article, most likely due to this article not being geared directly towards newcomers to MediaWiki.

This is where I experienced most issue; from here there was no more crutch helping me along. I somewhat expected, as I had seen on other projects, there to be a simple guide for what to do next for newcomers and, unless I couldn’t see it, there wasn’t one. I was left unsure as to what to do next; Should I just start browsing code? Look at feature requests? Or for bugs? I think this is where some guidance would be helpful for newcomers; getting to this point was well documented, but after you’ve set everything up, you’re left wondering what next. Some sort of list of easy bugs, or projects for newcomers to contribute to, would give some guidance as to what type of contributions they should be looking to make next.

I also noted that some information linked from the developer hub, such as an archived roadmap, was out-of-date or marked as only available for historical purposes. While I understand the reasoning behind this, it’s still confusing as these links are still prominent on the page.

In conclusion

While I didn’t install MediaWiki personally, my experiences toward the complexity of setting up things, as detailed in the first part, where from a pywikipediabot perspective, as I come from a python background rather than a PHP background. I would consider however contributing to MediaWiki in the future, if I ever take time to learn PHP, as it not only seems a enjoyable experience, but I appreciate the ideologies behind MediaWiki, to support a community that creates and curates freely reusable knowledge on an open platform.

David Wood
2013 Google Code-in student

Read in this series: