Google Code-in/2015

Google Code-in 2015 is over. 461 Wikimedia tasks were successfully completed thanks to many students and 35 mentors. Thanks everybody! Also see Google's announcement of winners.

Google Code-in is a contest to introduce pre-university students (ages 13-17) to the many kinds of contributions that make free and open source software (FOSS) development possible. Students must complete tasks, one at a time. It is sponsored and run by Google. The Wikimedia Foundation has participated since 2013.

Check Wikimedia's list of tasks in Google Code-in. The Google Code-in 2015 contest runs from December 07, 2015 to January 27, 2016 (see the full timeline).

Instructions for GCI students

These instructions are common to all the GCI tasks. Each category of tasks has further instructions. There is also general information available by Google.

General recommendations

If you choose to work on a bug report that requires writing or changing code, you want to take a look at these pages first:

The code of MediaWiki, its extensions, and Wikimedia's server configuration is located in Git repositories. You are expected to provide your work (patches etc.) in Wikimedia Gerrit for review (and optionally on the GCI site). See Developer access and Gerrit tutorial for information about how to download our code, test it and start submitting patches. Only if you have problems with Gerrit, providing your work in the corresponding task in Wikimedia Phabricator is an acceptable workaround.
Coding conventions and any subpages relevant to your task (PHP, JavaScript, Python, …)
Follow the Commit message guidelines, especially the Example section at the bottom. It will automatically add a notification about your patch to the corresponding report in Phabricator. Hence there is no need anymore to add a "Please review" comment in the Phabricator task.
Check your code against the pre-commit checklist. Don't skip this step; you'll be happy you didn't.
Getting code reviews. Find and add people as potential reviewers of your patch.
Amending a change. Don't create a new Gerrit changeset to fix your previous one!
We recommend you use MediaWiki-Vagrant, the standard development environment for MediaWiki - a virtual machine that has the basic wiki software and various common extensions preconfigured.
If you did not test your patch before you submitted it for review in Gerrit, clearly state so in an additional comment in Gerrit. Whenever possible, please do test your patches first.
Git for dummies is a collection of tips and basic tutorial for Git and Gerrit.

Feedback, questions and support

You are expected to do some basic research yourself first: Look at the code, try to get some understanding what it is supposed to do, and try to find the probable place(s) where you need to make changes in order to fix the bug.
Each GCI task specifies a public community channel for related questions and comments that might be more efficient than the Google Code-in site. Identifying yourself as a GCI student may help you getting more/faster help from other contributors in addition to your mentor(s).
- Sometimes the channel is a bug report (also called "task"). See Phabricator (except for Kiwix tasks which use Sourceforge instead). In the upper part of a bug report you can see the project that the problem is located in. This provides you a hint about the Git repository that the code is located in, and about the development team which you could contact if you want to discuss it in a "broader" way (as comments in bug reports should refer to the specific problem described in the report only).
- Sometimes the channel is a wiki discussion page. See Help:Talk pages.
If you have general questions about infrastructure, the software architecture or workflows which are not tied to the specific bug that you want to work on, use generic channels like IRC, mailing lists, or wiki discussion pages. For example, if you have a problem with Gerrit, the Gerrit discussion page could be a good place to ask.
If you have a specific question about the bug itself, comment in the corresponding Phabricator report. "What do I have to do to fix this bug?" is not a good question to start with: The more specific your questions are, the more likely somebody can answer them quickly. If you have no idea at all how to fix the bug, maybe that bug is not (yet) for you - please consider finding an easier one first.
When asking, elaborate what you have tried and found out already, so others can help at the right level. Try to be specific - for example, copy and paste your commands and their output (if not too long) instead of paraphrasing in your own words. This avoids misunderstandings.
Avoid private email or support requests in our social media channels.
Please be patient when seeking input and comments. On IRC, don't ask to ask, just ask: most questions can be answered by other community members too if you ask on an IRC channel. If nobody answers, please ask on the bug report or wiki page related to the problem; don't just drop the question.
Learn more at Communication.

Communicate that you work on a bug

You do not need to be set as the assignee in a bug report in Phabricator or announce your plans before you start working on a bug, but it is welcome. At the latest when you are close to creating a patch for the bug, it is good to announce in a comment that you are working on it. Your announcement also helps others to not work on the bug at the same time and duplicate work. Also note that if a bug report in Phabricator already has a recent link to a patch in Gerrit and has the project "Patch-For-Review" associated, you should choose a different bug to work on instead—avoid duplicating work.

If you stop working on a task you should remove yourself as the assignee of a bug report and reset the assignee to the default assignee, so others know that they can work on the bug report and don't expect you to still work on it.

By communicating early you will get more attention, feedback and help from community members.

Contacting Wikimedia mentors

Please be patient when seeking actions from mentors. Mentors are humans who eventually leave their laptops to sleep, work, study... Also they might be in different timezones than you. It could take your mentor(s) up to 36 hours to receive a review of the work that you have submitted. You should be reasonably patient and should not ask for a review of your work after only a few hours of waiting. Google Code-In is about the quality of your contributions and learning how FOSS development works, not about the number of tasks that you have worked on.

Name	IRC nick	IRC channel	Timezone	Areas of interest
Andre Klapper (org admin)	andre__	#wikimedia-dev ^connect	UTC+1	User documentation, Phabricator
Petr Bena (org admin)	petan	#huggle ^connect #mediawiki ^connect	UTC+1	Huggle, wm-bot, C/C++/C#/Java/PHP or Python tasks
Nemo (org admin)	Nemo_bis	#mediawiki-i18n ^connect, #mediawiki ^connect	UTC+1	i18n
Bartosz Dziewoński (Matma Rex)	matmarex	#wikimedia-dev ^connect	UTC+1	Multimedia, MediaWiki core
Legoktm	legoktm	#wikimedia-dev ^connect	UTC-8	MediaWiki, Pywikibot
Ankita Shukla	ankita_	#wikimedia-dev ^connect	UTC+5:30	MediaWiki, PHP, documentation, Spelling Dictionary - Extension Page and Phabricator Project
Jdlrobson	jdlrobson	#wikimedia-mobile ^connect	UTC-7
Rachel Farrand	dynosaur / rfarrand	#wikimedia-devrel ^connect	UTC-7	documentation, community, event design
Bmansurov (Baha)	Bmansurov	#wikimedia-mobile ^connect	UTC+5	anything mobile
Tina Johnson	tinajohnson	#wikimedia-dev ^connect	UTC+5:30	UI, MediaWiki, Database
Kelson (talk)	Kelson	#kiwix ^connect	UTC+1	Kiwix for Android
Rashiq	ahmad96	#kiwix ^connect	UTC+2	Kiwix for Android
Nuria Ruiz	nuria	#wikimedia-analytics ^connect	UTC+9	UI, analytics
Addshore	addshore	#wikimedia-dev ^connect	UTC+1	MediaWiki, Wikidata, Wikibase, CI
Tony Thomas	tonythomas	#wikimedia-dev ^connect	UTC+5:30	Mediawiki, PHP, Emails, Newsletter Extension
Moriel Schottlender	mooeypoo	#wikimedia-collaboration ^connect	UTC-8	TemplateData, UI, i18n GENDER and PLURAL fixes
Jarek T.	Contact me @ c:User talk:Jarekt		UTC-5	Templates, LUA, bots, Commons
John Vandenberg	jayvdb	#pywikibot ^connect	UTC+10	Pywikibot, bots, Commons, Wikidata, Templates, LUA
Niharika Kohli	Niharika	#wikimedia-dev ^connect	UTC+5:30	MediaWiki JS, Python, PHP, Database
Alangi Derick	xSavitar	#wikimedia-dev ^connect	UTC+1	Echo, MobileFrontend, Gather, Newsletter, OOJs/UI, Thanks, Documentations and Wikimediacore
Frances Hocutt	fhocutt	#wikimedia-dev ^connect, #wikimedia-commtech ^connect	UTC-8	Bots, Python, PHP, tools, documentation.
Marielle Volz	mvolz	#wikimedia-services ^connect, #wikimedia-visualeditor ^connect	UTC	Citoid, JavaScript, Node.js, Template Data
Platonides	Platonides	#wikimedia-dev ^connect, #wikimedia-es ^connect	UTC+1
This, that and the other	tto	#wikimedia-dev ^connect	UTC+11	MediaWiki core; scripts and gadgets
Nikerabbit	Nikerabbit	#mediawiki-i18n ^connect, #mediawiki-core ^connect	UTC+2	i18n, Wikimedia Language engineering
Jonesey95	Jonesey95	en:User Talk:Jonesey95	UTC-8	en.WP templates
Strainu	Strainu	ro:Wikipedia:Cafenea	UTC+2	Romanian templates, gadgets etc. Also Pywikibot if needed.
Polybuildr	polybuildr	#wikimedia-dev ^connect	UTC+3 in December, UTC+5:30 otherwise	Extension:SmiteSpam: phabricator project
Sumit Asthana	codezee	#wikimedia-dev ^connect	UTC+5:30	Extension:WikidataPageBanner( phabricator project) and MediaWiki core,Mobile Frontend
S Page	spagewmf	#wikimedia-dev ^connect, #wikimedia-tech ^connect	UTC-8	documentation generated with #Doxygen, API doc on wiki, sample code like Extension:BoilerPlate
Anchit Bansal	anchit_	#wikimedia-dev ^connect	UTC+5:30	C++, Documentations, Database
Gergő Tisza	tgr	#wikimedia-dev ^connect	UTC-8	MediaViewer, MediaWiki core, gadgets
Zhuyifei1999	zhuyifei1999_	#wikimedia-commons ^connect	UTC+8	Commons, pywikibot, labs
Subbu Sastry	subbu	#mediawiki-parsoid ^connect	UTC-6	Parsoid
TheDJ	thedj	#wikimedia-dev ^connect	UTC+1	Frontend JS, CSS, ResourceLoader, documentation
Matt Flaschen	matt_flaschen	#wikimedia-collaboration ^connect	UTC-5	PHP, frontend JS, LESS, Puppet, MediaWiki-Vagrant, databases, documentation, Flow, Echo
Florian Schmidt	FlorianSW	#wikimedia-dev ^connect	UTC+1	MobileFrontend, MediaWiki core, OOJs-UI
Prateek Saxena	prtksxna	#wikimedia-dev ^connect	UTC+5:30	Frontend JS, CSS, OOJs-UI, UI
Glaisher	Glaisher	#wikimedia-dev ^connect	UTC+5	MediaWiki special pages, Extension:Newsletter
Reedy	Reedy	#wikimedia-dev ^connect	UTC	MediaWiki
Rohit Dua	rohit-dua	#wikimedia-dev ^connect	UTC+5:30	Bots, tools, Python, security, documentation.
James Hare	harej	#pywikibot ^connect	UTC-4	Python

Mentors' corner

The following section is only interesting for mentors of GCI tasks.

First things first:

Watch this page for more instructions, or ask for them.
Be ready to learn with the rest of us along the way. :)
After November 13th, org admins will invite all mentors listed in the table above (under Contacting Wikimedia mentors) via email to register on the Google Code-in site.
After November 13th and after having registered as a mentor, create your tasks directly on the Google Code-in site (but preferably add general information to the Phabricator task so any helpful information will also be available to contributors outside of Google Code-in in case your task will not be worked on). Org admins are happy to help!
After December 7th, be ready to mentor students, answer their questions, review their work (if you need more than 36 hours, let us know to help you).

Become a Wikimedia GCI mentor

Thank you for your interest in mentoring and helping young people to get into free and open source software!

Read the Requirements of a task below.
Add yourself to the mentors table under Contacting Wikimedia mentors above. You can become a mentor at any time.
Org admins will invite mentors. You will receive an email "You have been invited to be a mentor for Wikimedia for Google Code-in 2015" with a link to complete the registration process.
After registering you will be able to create tasks directly on the Google Code-in site (see "Requirements of a task" below). If you create a task on the Google Code-in site which has a corresponding task in Wikimedia Phabricator, add the "Google-Code-in-2015" in the "Projects" field in Wikimedia Phabricator, paste the link to the task on the GCI site in a comment in the Phabricator task, and drag the Phabricator task into the "Imported into GCI site" column on the workboard.
Mentors can create tasks on the Google Code-in site at any time, also after GCI has started. Tasks will not get immediately published, an org admin needs to publsih them. Either add a "[READY]" prefix to the task summary to let org admins know, or contact them explicitly.

Requirements of a task

If there is common text that should be included in any of your tasks on the Google Code-in site, add it to the basic boilerplate section "Common instructions for tasks" below!

Tasks are supposed to take 2-3 hours to an experienced contributor. It is fine if the first task takes even 2-3 days to a student because they must understand many concepts and setup their environment first. And it is also ok if students specialize in a type of task, so every new task takes less time to complete until they are also able to complete them in a couple of hours. A student can work on one task at a time.
Tasks are self-contained. Students must be able to complete it without much knowledge of the context, or the background.
Tasks should preferably have two mentors. Mentors are supposed to reply and review student contributions within 36 hours, so be careful with accepting tasks before weekends and season holidays. Org admins are happy to help out but if you know that you will not be available in a certain timeframe, please reach out to co-workers if they could help review.
You can also create "Beginner tasks". They are supposed to take less than 30 minutes to an experienced contributor.
To save time, "generic" tasks (e.g. "Fix 5 template data issues from the list shown in this link") are also very welcome which can easily be "cloned": When creating a generic task on the Google Code-in site, set the "Instance Count" field to >1 so several instances of the task will be created and be all available to students. A "View Task Instances" link will be displayed in the task edit view. You can also add additional instances to a task even after the task instances get down to 0.
- Note that students can only claim a single instance of the same cloned task. Hence create completely separate tasks to allow students to perform the same work again.

Some ideas for tasks:

Full list of "easy" tasks which could fit for GCI; list of "easy" tasks per area. Edit the task description and provide pointers to help the contributor!
A list of tasks which were already GCI candidates in 2014; 2014 ideas wikipage
A list of tasks which were already GCI ideas in 2013
Example tasks from previous years across organizations

Template for tasks

Tasks on the Google Code-in site need to include the following information:

Task title. You might want to mention your project name in the title.
Detailed task description. This should contain full URL link to a corresponding Phabricator task and links (please use full URLs) to any information that could be helpful and to important resources. You should also add the #Common_instructions_for_tasks below for your area. Avoid misunderstandings and wrong expectations: Mention skills that could be helpful or are required for students so they can judge themselves. If you expect a patch in Gerrit from the student, say so. If you expect the main communication to happen in the Phabricator task or expect students to discuss a first iteration with you on IRC, say so by telling your IRC nickname(s) and channel.
Note: You could add most of this information to the Phabricator task description instead (via "Edit Task"), so it will not get lost for future contributors if your GCI task does not get solved as part of GCI. This also allows circumventing the 1500 characters limit on the Google Code-in site.
Instance count: Set this to higher than 1 if your task is "generic" (e.g. "Pick one item to solve from this link: ...") and should be available more than once.
Days to complete the task. Keep in mind students' real life. Be generous.
Beginner task? Yes/No. Beginner tasks are simple tasks that help completely new students onboard and learn how "things work". - Such introductory tasks should take an inexperienced student less than 3 hours to complete and are less technical in nature. Examples: Getting on IRC, making first wiki edits; setting up the development environment and providing a screenshot of it, or triaging three bug reports. Each student can only work on a maximum of two beginner tasks.
At least one category:
- Code: Tasks related to writing or refactoring code.
- Documentation/Training: Tasks related to creating/editing documents and helping others learn more. No translation tasks allowed.
- Outreach/Research: Tasks related to community management, outreach/marketing, or studying problems and recommending solutions.
- Quality Assurance: Tasks related to testing and ensuring code is of high quality.
- User Interface: Tasks related to visuals, design or workflows in applications.
Tags: Maximum 5 arbitrary keywords related to the task which can be searched for, e.g. the programming language.
Mentors: One or two mentor(s) available for this task. The mentor(s) must have agreed on mentoring and be registered on the Google Code-in site. (Note that mentors can only add themselves to a task if they are creating it. Otherwise, org admins need to manage mentors.)

Workflow

A student has to click "Submit Task" to request a review of their work on the Google Code-in site. If you find the task is complete, click "Approve task". If you find it is not complete yet, you must click "More work needed". Then you can get back to the student with details to finish the task at Gerrit / Phabricator / wherever you have agreed. The first time you do this in the task you should also comment on the Google Code-in site where your feedback is located, just in case.

Common instructions for tasks

We want to use common texts in tasks wherever it makes sense to simplify the process of creating good task descriptions. Let's draft different levels of common texts: generic for all, specific to a category, specific to a type of task. When creating a task, use the levels that make sense. Let's link to on-wiki instructions and background as much as possible. This gives us freedom to improve content without having to edit multiple tasks.

For all tasks

The following sentence (set in WMF's profile) is appended to each task description on the GCI site:

Students must read Wikimedia's general instructions at https://www.mediawiki.org/wiki/Google_Code-in_2015#Instructions_for_GCI_students first.

Citoid

citoid is a Node.js application (written in JavaScript) that retrieves information about a webpage, book, journal article, etc. given a URL to the webpage or some other identifier, like DOI (digital_object_identifier). It uses another open source project, Zotero's translation-server, also written in JavaScript, to do a lot of the work. Doing this work may involve reading both citoid and translation-server code. In order to get citoid working on your computer, you'll need to download both Node version 10.0 (for citoid) and xpcshell version 29.0 (for Zotero) to get both of them working. There are installation instructions and more information available at https://www.mediawiki.org/wiki/Citoid

Doxygen

Screenshot of MediaWiki documentation in Doxygen

Doxygen is the tool that generates MediaWiki PHP documentation. When developers approve changes to core MediaWiki in Gerrit, this triggers a Jenkins job 'mediawiki-core-doxygen-publish' that updates https://doc.wikimedia.org/mediawiki-core/master/php/ , For example, gerrit:251440's run of mediawiki-core-doxygen-publish produced this console log (eventually job runs are purged, look at https://integration.wikimedia.org/ci/job/mediawiki-core-doxygen-publish/ for recent runs). You must install the same version of Doxygen that Jenkins uses; from the doc.wikimedia.org footer you can see that as of November 2015 it is version 1.8.6.

When you submit patches that fix Doxygen issues, you should only change PHP comments, and in your commit say "Comment-only change" and link to the page(s) you've changed. Ideally you should publish the output of running Doxygen on a public web site where reviewers can see the revised documentation with your fix, saving them the time to run maintenance/mwdocgen.php themselves. If you don't have a public web site, you could set up a project on Tool Labs for this.

Huggle

Screenshot of huggle (kde)

Huggle is a fast diff browser application intended for dealing with vandalism on Wikimedia projects, written in C++ (C++11 with Qt framework). More information: https://meta.wikimedia.org/wiki/Huggle and https://en.wikipedia.org/wiki/Wikipedia:Huggle.

Source code is available at https://github.com/huggle/huggle3-qt-lx and can be compiled on Linux, Windows and MacOS.

JavaScript gadgets

Wikipedia and other Wikimedia projects use gadgets written in JavaScript. See https://www.mediawiki.org/wiki/Gadget_kitchen for more information and potential task ideas.

Kiwix for Android

On a boat, in the middle of nowhere or in Jail, Kiwix gives you access to the whole human knowledge, offline, on your mobile device!

A screenshot of Kiwix for Android

Kiwix is a Wikipedia offline reader which runs on Windows, GNU/Linux, OSX, iOS and Android. The Google Code-in tasks are related to the Android app, they require knowledge of the Java programming language and you also need a GNU/Linux distribution and basic knowledges about git.

To step in with a virtual machine, follow these instructions:

Download the KiwixDev virtual machine (KiwixDev torrent)
Import it on your prefered virtual machine (for example VirtualBox
Launch the virtual machine

To step in without a virtual machine, follow these instructions:

Install a GNU/Linux distribution, ideally Ubuntu (in a virtual machine like Virtualbox)
Install development tools like git, autoconf, etc.
Go to Sourceforge and create an account
Click on the "Fork" button available here (you need to be logged)
Clone your project using git clone on your local machine

Then:

... follow the compilation instructions for Android

One time you think your code works and is good enough to be reviewed, do like following:

Create a fork on Sourcefoge
Commit and push your code from the command line using git
Make merge request for your commit (using Sourceforge UI)

Lua templates

MediaWiki templates are wiki pages to be included in other pages. Templates can take arguments, allowing editors to create special types of content like infoboxes, banners, and more. Originally, templates were written wikitext with parser functions, mimicking the functionality of a very basic programming language (but requiring advanced skills to get smart results out of them).

This problem has been solved allowing templates to rely in modules written with Lua, a proper programming language: https://www.mediawiki.org/wiki/Lua. Now we have many wikitext templates waiting to be rewritten in Lua. Take one and rewrite it! See also: https://en.wikipedia.org/wiki/Wikipedia:Lua/Help and https://en.wikipedia.org/wiki/Help:Lua_for_beginners .

Steps:

Create a template at https://en.wikipedia.org/wiki/Template:XXXXXXXXXXX/sandbox.
Create a module at https://en.wikipedia.org/wiki/Module:Sandbox/XXXXXXXXXXX.
Report your progress soon and often at https://en.wikipedia.org/wiki/Wikipedia:Lua/To_do where not only GCI mentors but also other community contributors can follow the progress and help.

MediaWiki core

Start of task description: The popular wiki platform, [MediaWiki](https://www.mediawiki.org), powers a wide range of collaborative editing projects, such as Wikipedia and Wikivoyage, as well as many internal corporate wikis and other sites.

End of task description: Early on in the contest, students will have trouble finding where the code is located, so it helps to put one of the following at the end of the task description. The second one is meant for cases where the logic flow is obscure and it might be hard for a novice to find the right place to modify the code.

MediaWiki code can be found in the [`mediawiki/core` Git repository](http://git.wikimedia.org/summary/?r=mediawiki/core.git). Read https://www.mediawiki.org/wiki/Gerrit for more details on submitting your code and the review process.
The code can be found in the file `includes/BlaBla.php` in the `mediawiki/core` Git repository. Read https://www.mediawiki.org/wiki/Gerrit for more details on submitting your code and the review process.

MediaWiki API

The popular wiki platform, [MediaWiki](https://www.mediawiki.org), has a web service [API](https://www.mediawiki.org/wiki/API:Main_page) which is used by various software tools, including automated "bots", to interact with a wiki programmatically.

Parsoid

You should install Parsoid for development. Following instructions in Parsoid/Developer Setup.
Basic familiarity with JavaScript is going to be very very useful -- you don't need advanced JS skills.
Basic familiarity with wikitext is useful since you are going to be adding unit tests for different wikitext snippets.
We are around in the #mediawiki-parsoid IRC channel.

Pywikibot

Pywikibot is a Python-based framework to write bots for MediaWiki. See https://www.mediawiki.org/wiki/Manual:Pywikibot for more information. Patches can be submitted via Gerrit (you need a MediaWiki.org account). More documentation on Gerrit can be found at https://www.mediawiki.org/wiki/Manual:Pywikibot/Gerrit. After you have successfully claimed this task on this site please do use the task in Phabricator for communication instead of this site. This allows more PWB developers to be reached! General development questions can be asked on the Pywikibot mailing list at https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l and the #pywikibot IRC channel (see https://www.mediawiki.org/wiki/MediaWiki_on_IRC).

User Interface: SVG Graphics

Using bitmap images creates two problems: They have a bad quality in high resolution displays and they are difficult to edit. Join the community goal of converting all logos to SVG! Your task is:

Create exact SVG replicas of these bitmap files (add link here to bitmap file(s)).
Upload the logos to https://commons.wikimedia.org, using this name fomat: (add here).svg. After publishing each image, edit the description following this example: (add example)
Notify the completion of your task: In addition to marking the task ready for review here in Google Melange, you must notify it also in the bug report (link?) tracking the progress of this community project. Just add a comment there with the links to your SVG file(s) in Commons.

This task requires existing graphics skills working with a Vector graphics application (e.g. Inkscape). Links to SVG file(s) that you have created are welcome. Basic knowledge of CSS might also be helpful for integration.

VisualEditor

VisualEditor is MediaWiki's rich-text editor (see https://en.wikipedia.org/wiki/Online_rich-text_editor for general information). You can find out more about it at https://www.mediawiki.org/wiki/Extension:VisualEditor.

Wrap-up blog posts

At the end of GCI 2015, numerous student contributors summarized their experience with Wikimedia: