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

Feedback 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). For feedback not tied to a specific task you can use more generic channels like IRC or mailing lists. Avoid private email or support requests in our social media channels. Please be patient when asking questions. Learn more at Communication.
 * Sometimes the channel is a bug report. See 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.

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 more information. In case you have problems with Gerrit, providing your work in the corresponding bug report in Wikimedia Bugzilla is an acceptable workaround.

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:
 * Developer access and Gerrit tutorial for information about how to download our code, test it and start submitting patches
 * 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 report in 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

 * 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 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, 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. Think that mentors are humans that eventually leave their laptops to sleep, work, study... Also they might be in different timezones than you.

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) List the tasks you want to create at the GCI site. TODO: Create table.
 * 2) Before starting creating tasks, please contribute to the common boilerplate text below under "Common instructions for tasks".
 * 3) After November 12, become an official mentor in Google's Melange.
 * 4) Watch this page for more instructions, or ask for them.
 * 5) Be ready to learn with the rest of us along the way.  :)

Become a Wikimedia GCI mentor
Register as mentor, 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 tasks, add yourself to tasks, add other mentors to your tasks...

Requirements of a task
All the tasks listed on this wikipage must be also listed in Google Melange well before December 01, since that is the interface that students will use. A basic boilerplate task description pointing to bug reports should be added below.

Please add new tasks directly in Google Melange instead of this wikipage. 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.
 * 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.
 * Tasks are self-contained. Students must be able to complete it without much knowledge of the context, or the background.
 * By default, tasks are described in a bug report with the keyword "easy" and 1-2 mentors CCed and volunteering explicitly in the comments.

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 bugs which have a corresponding GCI task already: ALL whiteboard:gci2014
 * A list of potential bugs fitting for GCI: MediaWiki and extensions, +keyword:easy, -whiteboard:gci2014, no patches pending ("GCI candidate bugs" saved search).

Org admins Quim Gil and Andre Klapper go through proposed tasks and confirm them. CC us in the bug reports.
 * Bug description. Detailed explanation with full URL link to corresponding bug report and links to any information that could be helpful. Hours that it takes to complete the task (be generous!). Arbitrary tags that can be searched for (e.g. programming language). Name of the mentor(s): ~

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 be: Students are required to read Wikimedia's general instructions first.

Kiwix for Android
Kiwix is a Wikipedia offline reader. These are tasks related to the new release of its Android app. Instructions to compile the app can be found here (Android section). 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.

User Interface: SVG Graphics
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.

Pywikibot
PyWikibot is a Python-based framework to write bots for MediaWiki. Patches can be submited through the gerrit uploader (you need a MediaWiki.org account). More documentation on gerrit can be found here. After you have successfully claimed this task in Google Melange please do use the bug report in Bugzilla 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 and the #pywikibot IRC channel.

Visual Editor
VisualEditor is MediaWiki's WYSIWYG editor. You can find out more about it here.

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