Google Code-in/Mentors



First things first:


 * 1) Watch this page for more instructions, or ask for them.
 * 2) Be ready to learn with the rest of us along the way.  :)
 * 3) After November 7th, org admins will invite all mentors listed in the table (under Google Code-in 2016#Contacting Wikimedia mentors) via email to register on the Google Code-in site.
 * 4) After November 7th 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!
 * 5) After November 28th, 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
Wikimedia mentors need to be able to guide students. Hence mentors need to be experienced Wikimedia contributors and need to know our communities and "how things work".

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


 * Read and understand the Requirements of a task below.
 * Read and understand the Mentor responbilities
 * Add yourself to the mentors table at the bottom of Google Code-in 2016. 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 2016" 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-2016" 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 publish 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, even on 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 do 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!
 * Tasks which were proposed for or worked on in GCI 2015; Tasks that were available in GCI 2015
 * Tasks which were candidates for GCI 2014; 2014 ideas wikipage
 * Tasks which were ideas for GCI 2013
 * 2015 GCI tasks across all organizations

Proposing tasks
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-2016" 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.

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 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 must 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 claims a task. Once they finished their work, they click "Submit for review" 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" (and you can also give more time to the student). 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.

See also the tasks FAQ.

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

For most tasks simply downloading and installing Android Studio is sufficient to start developing. You can then use either a real or virtual device to test your changes.

Once you are ready to begin: More advanced tasks may first require you to prepare our full build environment. The easiest way to do this is with a Virtual Machine.
 * 1) Fork our GitHub repository https://github.com/kiwix/kiwix
 * 2) Commit and push your changes to your fork
 * 3) Create a pull request so we can review your changes https://github.com/kiwix/kiwix/pulls
 * 4) Submit the task on the GCI site and wait for your changes to be reviewed
 * 5) If everything is good then we will merge your changes and complete the task otherwise we will provide you with feedback so that you can make changes and resubmit
 * 1) Download the KiwixDev virtual machine (KiwixDev torrent)
 * 2) Import it on your preferred virtual machine (for example VirtualBox
 * 3) Launch the virtual machine
 * 4) Follow the android compilation instructions here: https://github.com/kiwix/kiwix/blob/master/android/README

Lua modules
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 in 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/sandbox.
 * 2) Create a module at https://en.wikipedia.org/wiki/Module:XXXXXXXXXXX.
 * 3) Report your progress soon and often at https://en.wikipedia.org/wiki/Wikipedia_talk:Lua 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 (see 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. See https://phabricator.wikimedia.org/diffusion/MW/ for browsing it on the web. 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 (see https://www.mediawiki.org/ ) has a web service API (see 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, and https://www.mediawiki.org/wiki/Manual:Pywikibot/PAWS for a short online interactive tutorial. 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: 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.
 * 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.

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.

Translate extension and translatewiki.net
The Translate extension for MediaWiki powers the translation of documentation and banners on mediawiki.org, meta.wikimedia.org, and some other Wikimedia sites, and the translation of the user interface strings of MediaWiki itself and of several other Free software projects on the translatewiki.net website. Even though it's a large and complex extension, it has many small issues in code and configuration that can be a good match for Google Code-In.