Google Code-in/2016

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 2016 contest runs from November 28, 2016 to January 16, 2017 (see the full timeline).

Apply as a student Become a mentor now

Instructions for GCI students
After you have registered on the Google Code-in site (after November 27), please read this section. These instructions are common to all Wikimedia 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, always clearly say so in an additional comment in Gerrit. Whenever possible, please do test your patches first!

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 task. "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 task first.
 * When asking, elaborate what you have tried and found out already, so others can help at the right level. Be specific - for example, copy and paste your commands and their output (if not too long, otherwise create a Paste and link to it) instead of paraphrasing in your own words. This avoids misunderstandings.
 * Avoid private emails or support requests in our social media channels.
 * 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 set yourself as assignee in a bug report 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 and set yourself as assignee. 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 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, 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 computers to sleep, work, study. They might be in different timezones than you. It can take your mentor(s) up to 36 hours to review the work that you have submitted. You should be 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.

Mentors' corner
If you plan to be a mentor for GCI tasks, please refer to Google Code-in 2016/Mentors.