Google Code-in/2014

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.

The Google Code-in 2014 contest runs from December 01, 2014 to January 19, 2015 (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.

Suggested reading
If you choose to work on a task that requires writing or changing code, you might want to at least skim these pages first to avoid unnecessary setbacks during the review process:
 * 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 both Google Melange and Wikimedia Gerrit for review. 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 or Wikimedia Bugzilla is an acceptable workaround.
 * Coding conventions and any subpages relevant to your task (PHP, JavaScript, Python, …)
 * Following the Commit message guidelines, especially the Example section at the bottom, will automatically add a notification about your patch to the corresponding task in Phabricator or Bugzilla. Hence there is no need anymore to add a "Please review" comment in the report.
 * Amending a change. Don't create a new Gerrit changeset to fix your previous one!
 * Getting code reviews. Find and add people as potential reviewers of your patch.

Feedback, questions and support
Each GCI task specifies a public community channel for related questions and comments that might be more efficient than Google Melange. 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. See Phabricator/Bugzilla (except for Kiwix tasks which use Sourceforge instead). In the upper right corner of a bug report you can see the product and component 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.
 * 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.
 * 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 or Bugzilla 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 soon and often
If your task has a related bug report in Phabricator or Bugzilla, comment on the report that you have started the work and request to have it assigned to you.

If your task requires the creation of wiki pages, create them to draft your text from scratch, and communicate in the Google Melange task the URL of the new page.

By communicating early you will get more attention, feedback and help, not only from your mentor(s) but perhaps from other community members as well.

Once you have started, feel free sharing your progress (or lack of it) as you accomplish little milestones or you get stuck in a problem. As long as you communicate through bug reports or discussion wiki pages you don't have to worry about spamming people: those who follow these bug reports and wiki pages are interested in your work.

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.
 * On IRC, don't ask to ask, just ask: most questions can be answered by other community members too if you ask on a channel. If you can't find your mentors NOW and nobody answers, please ask on the bug report or wiki page related to your task, don't just drop the question. Org admins might be also able to help.

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

First things first:
 * 1) Before starting creating tasks, please contribute to the common boilerplate text below under "Common instructions for tasks".
 * 2) List the tasks you want to create and mentor below under "Proposed tasks".
 * 3) Watch this page for more instructions, or ask for them.
 * 4) Be ready to learn with the rest of us along the way.  :)
 * 5) After November 12th, register as an official mentor in Google's Melange.

Become a Wikimedia GCI mentor
Create tasks below under "Proposed tasks". Register as mentor in Google Melange quickly after November 12th, and then request a connection with Wikimedia through "My Dashboard". Quim and Andre will receive a notification and will accept you. From that point you will be able to create further tasks, add yourself to tasks, add other mentors to your tasks in Melange.

Mentors can add tasks at any time, also after GCI has started. Usually this is what happens when students are finishing tasks, they have already learned about a specific area, and they want more tasks related to it.

Requirements of a task
The tasks listed on this wikipage will be imported into Google Melange well before December 01, since that is the interface that students and mentors will use. If there is common text that should be included in any of your tasks, 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.
 * "Beginner tasks" are supposed to take less than 30 minutes to an experienced contributor. They are supposed to be "less technical in nature".
 * 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 (keep in mind weekends and christmas 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.

Bugs which have been made into GCI tasks should have "gci2014" added to their Whiteboard field to make it easy to track them. You can add the URL to the task definition in a comment or URL field.
 * A list of Bugzilla tasks which were already GCI candidates in 2013: ALL whiteboard:gci2014
 * A list of potential Bugzilla tasks fitting for GCI: MediaWiki and extensions, +keyword:easy, -whiteboard:gci2014, no patches pending ("GCI candidate bugs" saved search).
 * If you are afraid that a proposed bug in Phabricator/Bugzilla will get fixed before Google Code-In starts you could consider adding a comment on the corresponding Phabricator/Bugzilla ticket like "Please avoid working on this if not urgent - this task has been proposed as a Google Code-In 2014 task".

How to propose tasks
Here we draft Google Code-In 2014 tasks before Google announces participating organizations and before we can import these tasks into Google Melange. After approx. November 12th, tasks should be directly created in Google Melange instead.

Template for tasks
When adding new task proposals below, please always provide the following information in the following order:
 * Task title (as a section title on this wikipage). You might want to mention your project name in the title.
 * Detailed task description with full URL link to a corresponding bug report and links to any information that could be helpful and to important resources. Mention skills that could be helpful or even required for students - this helps both sides to avoid misunderstandings and wrong expectations. Note that below will always be added to tasks. Please do avoid using any wiki markup in task descriptions (e.g. via   markup when needed), for an easier migration to Google Melange - use full URLs for example.
 * Hours (integer) to complete the task. Keep in mind students' real life and be generous.
 * One or two mentor(s) available for this task. The mentor(s) must have agreed on mentoring.
 * Tags: Any arbitrary keywords related to the task which can be searched for, e.g. the programming language.
 * Beginner task? Yes or No.

Proposed tasks
After approx. November 12th, these tasks should be imported in Google Melange and new tasks directly created in Google Melange instead.

Category: Code
Tasks related to writing or refactoring code. (Please always follow the "Template for tasks" above!)

i18n

 * Upgrade from long-deprecated i18n functions (recurring; post at least 5 times, up to ~15)
 * Help improve internationalisation of MediaWiki. Detailed steps:
 * Keep the internationalisation hints in mind, study the messages API manual for PHP until you fully understand the conversion table.
 * Pick 1 extensions/* directory from those mentioned; ensure it's not already being worked on.
 * Update the code which uses wfMsg* functions, as explained in the manual linked above; test and submit your patch to gerrit as explained in the general suggested reading material.
 * Remember to mention wfMsg* and bug 68750 in the commit message: that will be enough for the mentors to know of your work; this task will be accepted here when one patch is merged.
 * 3 days time
 * Mentor: Federico Leva (Nemo)
 * Tags: i18n, l10n, PHP, language

A better mobile view for editor data for dashiki (https://metrics.wmflabs.org/static/public/dash/)
Dashiki is the platform we are using to display data around edits in Wikipedia and sister projects. The platform itself requires minimal setup and if you have python installed in your computer you can get it running: https://github.com/wikimedia/analytics-dashiki This task consists of adapting the display of dashiki for mobile devices, at this time the display is not so mobile friendly and it is optimized for desktop, details on what the display needs to do in mobile are described on the bug, no new elements need to be created, rather selective hiding of current elements needs to happen. Coding will require CSS/HTML skills.
 * Bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=73030
 * Hours to complete the task will depend on student knowledge of CSS/HTML but about 2/3 days should be plenty.
 * Mentors: nuria@wikimedia.org
 * Tags: CSS, HTML, Mobile Web, Editor Data
 * Beginner task? Yes

Enhance the BounceHandler extension to differentiate between permanent and temporary bounces effectively
The BounceHandler extension (see https://www.mediawiki.org/wiki/Extension:BounceHandler) is used in MediaWIki to handle its email bounces effectively. It generates a VERP (https://www.mediawiki.org/wiki/VERP) 'Return-Path' address header corresponding to every send email from the Wiki and processes an incoming bounce email to take actions on the failing recipient. The bounce email is HTTP POSTed from the mail server to the extension API, from where the bounce is stripped of its headers and the bounce information is stored in a table. If the number of bounces for a user exceeds a defined limit (say 3 in a week), the user is email - unconfirmed.

A bounce is an incoming delivery failure notification mail, and there are many points where the delivery can fail, for example: and a lot more. Each case can result in the mailserver currently handling the transaction to originate a bounce message. Actions needs to be taken only against the permanent bounces as those are recipient specific. Incorrect actions taken on a number of temporary bounces (may be due to a network error) can get a lot of users getting un-subscribed.
 * DNS lookup failure (Permanent failure)
 * Network failure (Temporary failure)
 * Remote server could be overloaded (Temporary failure)
 * Remote server might blacklisted wikimedia.org or wiki@wikimedia.org (Temporary failure)
 * Remote server could say example@gmail.com is a bad address (Permanent failure)
 * Remote server could say example@gmail.com is over quota (Temporary failure)

Currently, we have only a check to ensure that a header  exists in https://github.com/wikimedia/mediawiki-extensions-BounceHandler/blob/master/includes/ProcessBounceWithRegex.php#L38 to confirm it to be a permanent bounce. This must be further enhanced to read the failure SMTP codes ( http://www.serversmtp.com/en/smtp-error ) from every bounce email (every bounce has one) and then effectively judge it to be temporary or permanent bounce. This is employed in various advanced bounce handlers and MediaWiki should too have one.

Skills/ Requirements required: Basic / intermediate knowledge in PHP so that you can read through the BounceHandler extension code on https://github.com/wikimedia/mediawiki-extensions-BounceHandler and get an idea how the bounce email is processed by the 'bouncehandler' API. Reading through the entire extension code is not required if you can reach to the regex expression directly and test it on a sample bounce email. Have a basic idea about email, email bounces, SMTP, mail server. What you need to do in a single line:

* Create a PHP regex expression to extract the SMTP code from the bounce email and only call the bounce processing scripts if the bounce is a hard bounce.

Hours: 70

Mentors: Tony Thomas, Jeff Green (?), Legoktm (?)

Tags: MediaWiki extension, BounceHandler

Beginner Task: No

Category: Documentation/Training
Tasks related to creating/editing documents and helping others learn more - NO translation tasks here! (Please always follow the "Template for tasks" above!)

Universal Language Selector: Write Help pages for all the input methods in Universal Language Selector (ULS)
The help pages for all the input methods made available through the Universal Language Selector extension should have relevant content that will help users, use the input methods more efficiently. The content from these help pages will be displayed to the users when they click on the help button of the input method (displayed on the input method selectors). In most cases, students will not be required to make any configuration/preference changes to view ULS input methods action.
 * List of Input Methods currently missing Help pages
 * Bug Report

Hours: 5 (on an average for each input method)

Mentors: Runa Bhattacharjee

Tags: MediaWiki Extension, Internationalization

Beginner task? Yes

Wikimedia Phabricator HowTo screencasts
http://phabricator.wikimedia.org is a new collaboration platform used by the Wikimedia Community. (Instructions to be completed, focusing on the beef now). We have Phabricator/Help, however, wouldn't it be great to just show how to do something, instead of describing it step by step with text only?

Each screencast should focus on a single task and aim to have less than 1 minute duration. No need to agree any script in advance, just look at the written instructions, play around yourself, and record the screencast. The worst thing that might happen is that we give you feedback and you have to repeat the less-than-a-minute video again.

Screencasts needed:
 * Overview of the Phabricator documentation in mediawiki.org
 * Overview of phabricator.wikimedia.org
 * Overview of phab-01.wmflabs.org
 * Create your account using your Wikimedia Single User Login.
 * Create your account using your Wikitech (LDAP) credentials.
 * Connect your SUL / LDAP identities to your account.
 * Claim your Bugzilla activity.
 * Fill your user profile.
 * Manage your notifications preferences.
 * Subscribe to a single task (and show the web / email notifications)
 * Join a project and "watch" it, explaining what's the deal.
 * Create a Herald rule for Maniphest (when it's enabled)
 * Post comments in tasks, showing the different actions available.
 * Editing a task (explaining when it is appropriate to do that)
 * Overview of the basic markup available in descriptions and comments.
 * Ways to create a task.
 * Creating a task (overview of the options available).
 * Creating a task via email.
 * Defining a URL to create tasks with certain parameters.
 * Uploading files.
 * Creating mockups.
 * Using the basic search.
 * Using Maniphest advanced search.
 * Saving and sharing search queries.
 * Requesting a new project: when do you need one, how should it be?
 * Requesting a new project: submitting a request
 * How to use phab:, and  on-wiki.
 * Introduction to Worboards (with examples of different ones)
 * Moving cards and editing tasks from dashboards.
 * What are dasboards and panels.
 * Creating a text panel.
 * Creating a query panel.
 * Creating a tab panel.
 * Creating your own dashboard.
 * More?

Category: Outreach/Research
Tasks related to community management, outreach/marketing, or studying problems and recommending solutions. (Please always follow the "Template for tasks" above!)

Category: Quality Assurance
Tasks related to testing and ensuring code is of high quality. (Please always follow the "Template for tasks" above!)

Retest five bug reports of your choice

 * Take five open bug reports in Wikimedia Phabricator which have not seen any update for two years. Go to the advanced query form on https://phabricator.wikimedia.org/maniphest/query/advanced/, search for open tasks only, and set "Updated Before" accordingly (see https://www.mediawiki.org/wiki/Phabricator/Help#Searching_for_items for help). Read those reports that have an interesting summary and try to understand them (if they are technically too complicated or if the English is too advanced you will have to choose other reports instead - this can happen quite often but will help you getting an idea of how complex software can be). If you understand what the report is about, test if you can still reproduce the reported problems (and if the steps to reproduce are clear enough). Add a comment in the bug report and explain clearly which steps you performed and the version that you tested with (e.g. for MediaWiki you can find this information on the page "Special:Version"). Free choice of tickets! Note that some bug reports might be easier to retest (for example on https://test2.wikipedia.org), some might require special permissions to access certain pages or setting up MediaWiki yourself - up to you if you want to do that. Find out more about updating and handling bug reports on https://www.mediawiki.org/wiki/Bug_management/How_to_triage
 * 60
 * Andre Klapper
 * MediaWiki,Retesting,Bugreport
 * No

Build a test case for the Pywikibot library
Improve the code coverage of the Pywikibot library test suite. Run  using instructions on Manual:Pywikibot/Test_coverage and select a set of lines of code that are not yet exercised by the test suite. Add a unit test which exercises that set of lines of code to the test suite. Create bugs for any failures encountered.
 * 10
 * User:John Vandenberg
 * Python,MediaWiki,unittest,Bugreport
 * Yes

Build a test case for a Pywikibot script not exercised by the test suite
Improve the code coverage of the Pywikibot test suite for one of its pre-packaged scripts. Select a script which is not listed at Manual:Pywikibot/Test_coverage and develop a basic test module which exercises that the code which performs the bots stated purpose. Create bugs for any failures encountered.
 * 25
 * User:John Vandenberg
 * Python,MediaWiki,unittest,Bugreport
 * No

Category: User Interface
Tasks related to user experience research or user interface design and interaction. (Please always follow the "Template for tasks" above!)

A better mobile view for editor data for dashiki (https://metrics.wmflabs.org/static/public/dash/)
This task is also included in coding tasks but it fits both code and UX well.

Dashiki is the platform we are using to display data around edits in Wikipedia and sister projects. The platform itself requires minimal setup and if you have python installed in your computer you can get it running: https://github.com/wikimedia/analytics-dashiki This task consists of adapting the display of dashiki for mobile devices, at this time the display is not so mobile friendly and it is optimized for desktop, details on what the display needs to do in mobile are described on the bug, no new elements need to be created, rather selective hiding of current elements needs to happen. Coding will require CSS/HTML skills.
 * Bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=73030
 * Hours to complete the task will depend on student knowledge of CSS/HTML but about 2/3 days should be plenty.
 * Mentors: nuria@wikimedia.org
 * Tags: CSS, HTML, Mobile Web, Editor Data
 * Beginner task? Yes

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 last sentence of each task description in Google Melange must always be: Students are required to read Wikimedia's general instructions first.

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
Kiwix is a Wikipedia offline reader. These are tasks related to the new release of its Android app - see https://play.google.com/store/apps/details?id=org.kiwix.kiwixmobile. This requires knowledge of the Java programming language. You also need a GNU/Linux distribution. Go to https://sourceforge.net/p/kiwix/kiwix/ci/master/tree/, checkout the code and follow step-by-step the instruction for Android of the "COMPILE" file.

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: 1. Create a template at https://en.wikipedia.org/wiki/Template:XXXXXXXXXXX-Lua. 2. Create a module at https://en.wikipedia.org/wiki/Module:Sandbox/XXXXXXXXXXX. 3. 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.

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 in Google Melange please do use the task in Phabricator for communication instead of Google Melange. 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: 1. Create exact SVG replicas of these bitmap files (add link here to bitmap file(s)). 2. 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) 3. 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.

Visual Editor
VisualEditor is MediaWiki's WYSIWYG editor. You can find out more about it at https://www.mediawiki.org/wiki/Extension:VisualEditor.

Workflow
When a student submits a task for review, and you find it is not complete yet, you must change the status of the task to "Needs work". 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 in Melange where your feedback is located, just in case.