Jump to content

Google Code-in/Admins

From mediawiki.org

Participating in Google Code-in requires the Wikimedia organization administrators to perform certain preparation steps and also recurring tasks while the contest is running.

This page is supposed to cover these steps and best practices in order to help next year's organization administrators and improve our processes.

Before applying

[edit]
  • Read Admin responsibilities.
  • Subscribe to the general "Google Code-in Mentors" list (gci-mentors at googlegroups dot com).
  • Read the tips and guidelines for org admins: https://docs.google.com/document/d/1Ah8iHIaOzi9Nj8PNCREWjnXPWMTx2Wq5qlTVBmUrt8c/edit?usp=sharing.
    • In 2017, 75 available tasks in total were required at the start. Having more tasks (that we don't publish necessarily on the first day) is highly recommended.
    • In 2015, 50 tasks had to be unique ("instant count" of 1).
  • Set up Google Code-in/20xx page - basically copy the initial version of the previous year but also check the final version of the previous year if there are improvements to take over. Also link that page from Google Code-in.
  • Create #Google-Code-in-20xx tag in Phabricator with initial description:
For tasks that you would propose for [[ https://www.mediawiki.org/wiki/Google_Code-in/20xx | Google Code-in 20xx ]] **if Wikimedia gets accepted as a participating organization**.

Note that tasks **must** have at least one mentor defined when you add this project tag. Just add a comment "I will mentor this in #GCI2018" or share the name of the mentor.

These tasks will be made available to GCI students if Wikimedia gets accepted and once the contest has started.

Before getting accepted

[edit]

After getting accepted

[edit]
  • Announce that we are in (2013, 2014, 2015, 2016, belated 2019)
    • Also announce via meta:Social media services to create awareness and reach potential students?
  • Watch the Mentors table at mw:Google Code-in/20xx for people adding themselves as mentors.
    • Check if they have been active Wikimedia contributors. If not, see #Unknown mentors below.
    • Inviting them will require an email address that you can either find in last year's data, via Gerrit's autocomplete, in the database behind wikimedia.biterg.io, or by using "Email this user" in the side bar on the user's wiki page if all goes wrong.
    • invite them via Google's site so they can register. (They will receive an email with registration instructions.)
    • Use the email addresses on the Mentors page (there is a "View all member emails" button at the bottom) to add people to the google-code-in-mentors mailing list via https://lists.wikimedia.org/mailman/admin/google-code-in-mentors/members/add
  • Check the "Pending invites" on the GCI site and nag people.
  • Inform other org admins about status on google-code-in-admins mailing list
  • Update this year's wikipage to say that we have been accepted as an org
  • Update this year's wikipage to list names of organization admins
  • Update this year's Google-Code-In project description on Phabricator (2018 example)
  • Schedule a (Hangout; IRC) info session for new mentors (2016; 2017; 2018, 2019)
    • Send a reminder email a few hours before that info session
  • Contact Engineering Managers in WMF and WMDE to make them and teams aware (if they don't follow wikitech-l@ closely) (email subject "Will your team mentor some Google Code-in tasks?", 2017-11-13); or email the internal tech-all@ mailing list (email subject "Are you going to offer and mentor a Google Code-in task?", 2018-10-19)
  • Make someone in the WMF office in San Francisco put up a Google Code-in info poster on a whiteboard?
  • Either manually create tasks on Google's GCI site (leave the mentor field empty if mentors are not registered yet in Google's site), or
  • Import tasks from Wikimedia Phabricator into the GCI site via its API (in 2018, an org needed 75 initial tasks). See the API high-level info and related documentation on format and commands.
    • Get tasks out of Phabricator by using Tony's script:
    • Potentially fix stuff in that script which has changed since last year when it was used (like IDs of workboard elements in Phabricator)
    • Get a CSV file as output
    • In that CSV file,
      • Add explicit column headers like "name", "description", "external_url" in the csv
      • Keep the "mentors" column empty, so we will easily recognize which tasks on the GCI site were imported and we need to go through
      • Set "time_to_complete_in_days" to "5" for all tasks
      • Set "categories" to "1" (code)
      • Set "is_beginner" to "0" as default
      • Set "tags" to "php" as default
    • Get the API key from https://codein.withgoogle.com/dashboard/profile/
    • Run Google's "python csv_uploader.py --api-key XYZ whatever.csv" from https://code.googlesource.com/codein/api
    • Edit the tasks manually on the GCI site and edit fields
    • Move imported Phab tasks to the "Imported" column on the Phabricator workboard. Post a link to the task URL on the GCI site but note that your admin's "Dashboard" URL path will not work; public URLs have the format https://codein.withgoogle.com/tasks/6342270513053696/ instead.
  • Creating recurring/clonable tasks: Use the "Instance Count" field when creating a task in Google's site.
  • Check all tasks marked as "beginner" if they really are such tasks (some mentors set that field incorrectly).

When contest starts

[edit]
  • Announce start of contest on wikitech-l (2015; 2016; 2017; 2018)
  • Send email to all mentors on the google-code-in-mentors mailing list when Google Code-in starts: Email template
    • Create a private Phab task with mentors listed under "Visible To" and "Editable By" to allow mentors post positive feedback about students who impressed them (2017 example) and update "Visible To" as new mentors join us. (probably obsolete as we have a mentors mailing list since 2019; plus adding each person to the task is cumbersome)
    • Include again info how to reach admins via mailing list and the private Phab task for posting positive feedback about students.
    • Announce the info session, mention who are org admins.
    • Explain again workflow that mentors can create tasks on the GCI site directly. Explain the workflow: After a student has claimed a task and clicked "Submit for review", you will either have to click "Approve task" or "More work needed" (plus you can also give more time to the student). Please note: Reviewing a patch as "improvements needed' in Wikimedia Gerrit (or such) won't make the GCI site know that, so the task would remain as "Submitted for review" and your 36 hours keep running. Make sure to also set "More work needed" on the GCI site when appropriate so we don't get angry emails from Google that our mentors are too slow.
    • Mention again 36 hours rule and also telling "pushy" students about timezones etc. Ask mentors to announce to admins if mentors plan to be off for a holidays
    • Link again to Google's "Mentor Responsibilities". If there are any issues with students (such as plagiarism) please let the org admins know.
    • When mentors know that they will not be available, make tasks summaries include a "[DONT PUBLISH BEFORE 20171231]" prefix or such.
  • Push two social media posts by contacting digitalmedia@ (2016 example for mentors; 2016 example for students)

Daily tasks while running

[edit]
  • The dashboard links to tasks waiting for review. Order by the "Modified" column to check tasks getting close to the 36h deadline for reviews (mentors and admins receive email warnings after 24h already).
  • Go through "Draft tasks" created by mentors: Review these tasks (are they clear and is all required info included?) and then publish them (or add "[READY]" to the summary and don't publish).
  • Check tasks "waiting for review" (<36h intended) and potentially provide feedback to help mentors
    • Mentors receive an email 24h after a task has been submitted for review, saying that they have 12h more to review. In case that a mentor does not seem to react, admins usually try to find either someone else to mentor or will let the student pass after those approx. 36h, as it's not the student's fault to have not received feedback on time.
  • Check number of unique tasks via in "Open"/"Reopened" state (>25 intended), potentially publish more ready tasks when getting close to the minimum limit of 50
  • For recurring tasks with several instances, check if enough are still open and if you should "publish" a task copy (if using suffix number in a title) as one student can only claim one instance of a recurring task. If you want one student to be able to work on more than one recurring task, you must create a separate copy of the task instead of increasing its instance count.

Weekly tasks while running

[edit]

Around half-time

[edit]

Before the contest has ended

[edit]
  • Contact mentors, thank them, ask them to name remarkable students, and ask to provide general feedback at Google Code-in/Lessons learned (What was good (socially & technically)? What to improve? Which tasks should we have offered but were missing? Which tasks did not get picked up + do you have a theory why? How was the interaction with students on IRC, mailing lists, Phabricator, Gerrit? Where did students struggle? Share your ideas and impressions.) (2016 Mentor feedback; 2016 Lessons learned) (2017 Email Template)
  • The last two weeks, potentially be a bit "stricter" with prospect finalists to get more "quality"?
  • Right before the contest ends, post a comment in the last task of each of the most active students to point to further tasks and local chapters. GCI2019 text is in https://phabricator.wikimedia.org/T200779#5824986

After the contest has ended

[edit]

Payments

[edit]

If Google offer to send any money for travel, as a donation, etc, to the organization (Wikimedia Foundation): This is handled via a Payoneer account (similar to GSoC). Payoneer account owner as of January 2020 is WMF Finance which can be contacted via accountspayable@.

GCI Grand Prize winners weekend

[edit]

Usually in June or July, the GCI Grand Prize winners get invited to California for a weekend. Google also invites one mentor to attend this weekend.

  • Receive an email from Google with instructions (something like "GCI Grand Prize Trip - One mentor to invite")
  • Create a Phab task (2018 example) and email the most active mentors to add a comment to the task if they are interested in attending
  • Admins to decide which one interested mentor/admin to attend (mentors with most task instance interactions?) via private emails (2016 example; 2017 example; 2018 example)
  • Contact the chosen GCI Grand Prize winners weekend attendee:
    • Include/forward the email from Google ("ACTION REQUIRED- Invite for your Org to send 1 Mentor for GCI Trip") which contains a link to Google's registration form
    • Explicitly state that Google has sent or will send travel funds to the Wikimedia Foundation via the Payoneer account: The attendee has to sort out travel with the Wikimedia Foundation and not with Google
    • Ask the attendee to inform themselves and sort out visas or ESTA required to enter the USA.
    • Provide a link to the "WMF Volunteer Travel Request Form" and ask the attendee to complete it ("Budget Approver" is the WMF budget owner listed above; "Department Budget" is the department listed above; "Hotel" field should be left empty as Google pays that directly; airport transfers from SFO airport to San Francisco are usually around 10USD one way using BART).
    • Ask the attendee to email the "WMF Volunteer Travel Request Form" to the WMF budget owner for approval of the trip (even though the trip is paid by Google). As of February 2019, that is Bryan Davis as head of Technical Engagement department.
    • Once approved, ask the attendee to forward the approval which includes the "WMF Volunteer Travel Request Form" to travelmanager@.
    • Afterwards, the WMF travel department will email the attendee directly with flight and/or hotel options for their trip, ask to confirm flights, and will finalize the travel for the attendee.
  • Potentially invite the Grand Prize winners (and their parents) who attend the GCI summit to also visit the Wikimedia Foundation office in San Francisco (needs someone in SF) (2018 example)
  • After that trip has taken place, email the mentor attendee and explain how they can reimburse any further money spent, quoting from (non-public) https://office.wikimedia.org/wiki/Expense_reports/Volunteers

GSoC Mentor Summit

[edit]

Usually in October GSoC Mentor summit takes place. In the past we were invited to send one GCI Wikimedia mentor. See phab:T227810 for the email and process.

Food for thought

[edit]

See Google Code-in/Lessons learned.

Copy and paste replies

[edit]

Unknown mentors

[edit]

Boilerplate text to reply to unknown mentors:

Thank you a lot for being available as a GCI mentor! Wikimedia mentors need to be able to guide students. Hence mentors need to be experienced Wikimedia contributors and need to already know the community and "how things work". Could you please share some information which specific Wikimedia projects you have contributed to and worked on so far? How would you describe your areas of expertise within Wikimedia which you'd like to mentor in GCI 2019? Are there any public Wikimedia contributions you could link to (for example your username or your Gerrit activity, or activity in Wikimedia projects on Github)? This would help us to get a better idea. (Also, for an invitation to Google's GCI website we need your email address.) And if you have not contributed to Wikimedia yet, we encourage you to start contributing to Wikimedia by checking out https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker ! Thank you!

Proxying for mentors not on the GCI site

[edit]

Boilerplate text to add to tasks with mentors who are actually not registered on the GCI site:

You *must* use the linked Phabricator task for communication with your mentors as some of the task mentors are not registered here on the GCI website, so they will not see your comments here.

No review within 36 hours happened

[edit]

Hi, I am sorry that your latest version in Gerrit has not been reviewed in a timely manner by the mentor (sometimes this can unfortunately happen), so I have approved this task to not block you from claiming your next task to work on! Good luck with your next tasks, and thank you a lot for your patch!

"Get on IRC" task in a silent channel

[edit]

Hi, I saw you were on #wikimedia-dev / #mediawiki earlier today and that time was rather silent. I'm sorry nobody replied to you on IRC! I still hope that you got a bit of an impression how we use IRC for some communication, and I hope that we will see you again on IRC! I wish you good luck and success with your next tasks!

Common tasks from previous years

[edit]

Beginner task ideas

[edit]

Beginner: get on Internet Relay Chat (IRC) (2015/2016/2018)

[edit]
Wikimedia development, like many free software collaboration efforts, [relies a lot on IRC](https://www.mediawiki.org/wiki/Special:MyLanguage/Communication) for discussion.

If you have not been on Wikimedia IRC channels yet, you can claim this task. You have to:

1. install an [IRC client](https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients) you like, but **not** IRC clients listed as "web" or [proprietary](https://en.wikipedia.org/wiki/Proprietary_software) (Examples: irssi, HexChat and KVIrc are good. mIRC, webchat.freenode.net, AndroIRC are not okay.)
2. connect to the "Freenode" network and [register your nickname](https://freenode.net/kb/answer/registration). Registration will not be complete until you send to nickserv the verification code that you received by email.
3. join the channel/room called `#wikimedia-dev` ([instructions](https://meta.wikimedia.org/wiki/IRC/Instructions)).
4. double-check that you are on `#wikimedia-dev`.
5. say hello on the channel, but never put personal info on IRC: Stick with your first name or username but not your full name, no phone numbers, no home addresses, etc.! Please mention that you are on IRC for GCI. The channel is public; it is a place for general discussion of Wikimedia development and not only for Google Code-in, so some people might not know what GCI is.
6. stay at least one hour before leaving.

When you have completed all (!) steps above, submit this task for review and tell us the nickname you used on IRC.

OPTIONAL: Follow conversations and updates on the channel: there might be situations to help someone else or be helped or click a link posted. You can also join [other IRC channels](https://meta.wikimedia.org/wiki/IRC/Channels) in your native language.

OPTIONAL: You may also subscribe to one of our [technical mailing lists](https://meta.wikimedia.org/wiki/Mailing_lists/Overview#General_development_and_technical_discussion) where non-realtime discussion happens.
  • ("60 task instances later, I think we proved that the IRC task is not so easy at all for the students. I think one third of them needed to resubmit their work after receiving additional instructions, or to have an extension, or abandoned the task.")
  • Compare to Drupal's Get on IRC task?

Retest 3 old open bug reports in Wikimedia's issue tracker (2015 / 2016 / 2018)

[edit]
1. Read [How To Triage](https://www.mediawiki.org/wiki/Bug_management/How_to_triage)
2. [Log into our issue tracker](https://www.mediawiki.org/wiki/Phabricator/Help) (called Phabricator)
3. Go to [Phabricator's advanced search](https://phabricator.wikimedia.org/maniphest/query/advanced/), set the "Statuses" field to "Open", set "Projects" to "testme" & set the "Updated Before" field accordingly (see [Searching For Items](https://www.mediawiki.org/wiki/Phabricator/Help#Searching_for_items)). Tasks in the "testme" project are bugs that someone wants to see retested.
4. Read those reports that interest you & try to understand them (if they are too complicated or advanced you have to choose other reports instead. This can happen quite often but it helps getting an idea of how complex software can be).
5. If you think you understand what the report is about (this might require looking up docs): Test if you can still reproduce the reported problem (and if the steps to reproduce are clear).
6. Add a comment in Phabricator & explain clearly which steps you performed (step by step) and the version you tested with (e.g. for MediaWiki you can find this information on the page "Special:Version"). Remove the "testme" project from the task by clicking "Edit the task".
7. Note: Some tasks might be easy to retest (for example on https://test2.wikipedia.org) and some might require [setting up MediaWiki yourself](https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker) - it's up to you!
8. Paste the links here to those tasks that you retested.
9. Thanks for helping clean up the backlog of open tasks!

(but: Not many students claimed the "Triage some #testme bug reports", maybe that choice was too limited?)

Set up your MediaWiki development environment and upload a screenshot of a MediaWiki extension (2016)

[edit]
Note that this is already an *advanced* beginner task (we also offer beginner tasks that are way easier and take less time, but this task is very useful if you plan to continue with coding related tasks.)

**Update: Vagrant 1.9.0 was released on November 28, 2016 and it is not working with our MediaWiki-Vagrant code. See [the bug report](https://phabricator.wikimedia.org/T151928) for details and updates. You may want to use an older Vagrant version until resolved.**

* Set up a Vagrant instance (your development environment) - see [instructions](https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker).
* In your development environment, install a [MediaWiki extension of your choice that is also installed on Wikimedia sites and which also does not yet have a screenshot](https://www.mediawiki.org/w/index.php?search=incategory%3A%22Extensions+used+on+WIkimedia%22+incategory%3A%22MediaWiki+extensions+without+a+screenshot%22&title=Special:Search&go=Go&searchToken=ceg4c6q8v8mq9uphazmn6fyo3) on the extension's home page on https://www.mediawiki.org
* Make a screenshot of the extension (if possible, please only display the content within your browser window, and do not include elements of your browser software itself or even your operating system)
* [Upload your screenshot of the extension to Commons](https://commons.wikimedia.org/wiki/Special:UploadWizard) (also [read about licenses](https://commons.wikimedia.org/wiki/Commons:Upload/screenshot)) and add the category `Screenshots of MediaWiki extensions`
* Insert the image into the home page of the extension (use the `|image = ` parameter of the [Extension template](https://www.mediawiki.org/wiki/Template:Extension))
* Tell us here which extension home page you edited by posting a link.
* Enjoy that you have your development environment ready, which will make any following coding tasks way easier for you! :)

If you have problems with installing MediaWiki-Vagrant, the best place to get timely answers is probably in the #wikimedia-dev and #wikimedia-tech [IRC channels](https://www.mediawiki.org/wiki/MediaWiki_on_IRC).

bd808, Tgr, unicornisaurous, Andre, Srishti

Write a Template Documentation (2019)

[edit]
English Wikipedia has a large number of templates and in order for other users to understand the use of the templates the documentation page plays a very important role.

We at English Wikipedia read the code of the template by viewing the source of it and document it's parameters and uses so that other users can use the template with ease.

Your task is to write a Template Documentations.

Points to be noted:
* You must be logged in with your Wikipedia account. Edits made while logged out aren't counted.
* You must create the template documentation as per the guidelines mentioned at https://en.wikipedia.org/wiki/Wikipedia:Template_documentation
* Must contain TemplateData. Learn about TemplateData at https://en.wikipedia.org/wiki/Wikipedia:TemplateData/Tutorial
* Please link to your documentation page in the GCI interface
* You need to create a new template documentation page - expanding a documentation isn't accepted.

Pro Tip: English Wikipedia has a category regarding Templates with missing or incorrect documentation at https://en.wikipedia.org/w/index.php?title=Category:Templates_with_missing_or_incorrect_documentation
Tags: template documentation

[Tracker] Get your local development instance running and send us a screenshot (2019)

[edit]
Get your local development instance of Wikimedia Tracker running. After you're done, please send us a screenshot showing your local Tracker instance running.

Steps (all paths are from repository's root):

1. Clone the repository (preferably from [Gerrit](https://gerrit.wikimedia.org/r/admin/projects/wikimedia-cz/tracker))
2. Setup the repository for use with git review. You can use [this tutorial](https://www.mediawiki.org/wiki/Gerrit/Tutorial)
3. Create /deploy folder
4. Create Python3 virtual environment (venv) by running `virtualenv -p python3 deploy/pyenv`
5. Activate the venv by running `source deploy/pyenv/bin/activate`
6. Install required packages by running `pip install -r support/requirements.txt`
7. Run `python support/makesettings.py` to get example settings.py
8. Edit settings.py's DATABASES sections to contain valid DB settings
9. Run `python trackersite/manage.py migrate` to apply [schema migrations](https://en.wikipedia.org/wiki/Schema_migration)
10. Run `python trackersite/manage.py runserver` to start the development server. It should listen on localhost:8000

Functional Programming 0: Setting up Score (2019)

[edit]
To have an idea of what is LilyPond and how it is normally used (i.e. for music engraving), try the "Transcribe music on Wikimedia wikis to LilyPond" task instead. LilyPond is a programming language for sheet music. It is also very extensible through Scheme, a lisp dialect (in fact it is Scheme with added features to make writing easier). These tasks will be expanding on LilyPond and the Score Extension's primary utility and learning the functional programming paradigm using it. Musical knowledge is not required for these tasks, although there may be some music involved.

For this task, follow the instructions laid out on https://en.wikipedia.org/wiki/User:Ebe123/GCI-Scheme#Task_0:_Setting_up_Score (just that section, not ones after).

This suite of tasks are inspired by http://lilypondblog.org/category/using-lilypond/advanced/scheme-tutorials/

Tags: scheme, music, lilypond, functional
Mentor: Ebe123

Clonable tasks from 2016

[edit]

Clonable tasks from 2019

[edit]
  • Get onto Internet Relay Chat (IRC) and stay for a while
  • Type hint $updater parameter in onLoadExtensionSchemaUpdates hooks - phab:T240073
  • Create a Wikimedia site configuration change
  • Deploy a Wikimedia site configuration change
  • Replace use of jshint and jscs with eslint in a MediaWiki extension - phab:T210365
  • Replace use of jsonlint with eslint in a MediaWiki extension - phab:T220036
  • Rename PHP files with the .inc extension to .php - phab:T184782
  • Take screenshots of Commons Android app in your native language
  • 10 Lua Learning tasks (by User:RexxS)
  • Functional Programming 0: Setting up Score - w:en:User:Ebe123/GCI-Scheme#Task 0: Setting up Score
  • Learn how to use Gerrit for code review, by submitting a patch
  • [Tracker] Get your local development instance running and send us a screenshot
  • Add yourself to the Jenkins whitelist in Gerrit to trigger testing unit test failures or code style issues yourself - phab:T235286
  • Add an HD logo for three Wikimedia project websites who does not HD logo enabled yet - phab:T150618
  • Write a Template Documentation
  • Add extension licenses to extension.json for one MediaWiki extension (so they appear correctly on Special:Version) - phab:T123943
  • Set up your MediaWiki development environment and upload a screenshot of a MediaWiki extension - phab:T178987
  • In MediaWiki core or extensions, replace wfMessage()->rawParams() with wfMessage()->plaintextParams() where applicable - phab:T182213
  • Empty PHP entry points where JSON entry points exist - phab:T140007
  • Transcribe music on Wikimedia wikis to LilyPond - phab:T201641
  • Retest 2 old open bug reports in Wikimedia's issue tracker
  • Improve documentation of a MediaWiki Action API page - phab:T237448


Create MediaWiki-Vagrant role for a MediaWiki extension (2015)

[edit]
[MediaWiki-Vagrant](https://www.mediawiki.org/wiki/MediaWiki-Vagrant) is a development environment for MediaWiki - a set of scripts to build a virtual machine, install MediaWiki on it and configure various extensions and other options.

Extensions are added by enabling roles; a role corresponds to a simple Puppet script - a declarative description about the state of the virtual machine. The task is to add a role for an extension that does not have one yet. Some suggestions are listed below but you can pick any other extension that works with the current version of MediaWiki.

Familiarity with Puppet or Vagrant is NOT required for this task; you can pick it up as you go, from the MediaWiki-Vagrant documentation and by looking at existing roles.

//Requirements//

* [create a task](https://phabricator.wikimedia.org/maniphest/task/create/?projects=google-code-in-2016&description=TODO:TaskURL) in Wikimedia's bug tracker for the specific extension you are writing a role for
* submit a patch for the "mediawiki/vagrant" repository in Gerrit containing the actual role
** roles should contain documentation ([this is a good example](https://phabricator.wikimedia.org/diffusion/MWVA/browse/master/puppet/modules/role/manifests/templatedata.pp); you can use [RDoc markup](http://jan.varwig.org/wp-content/uploads/2006/09/Rdoc%20Cheat%20Sheet.pdf) for links etc).
** if the functionality of the extension can be well demonstrated on a wiki page, add such a demo page to the role ([example](https://gerrit.wikimedia.org/r/#/c/189182/7))
* after the patch is merged, add the role name to the wiki page of the extension ([example](https://www.mediawiki.org/w/index.php?diff=prev&oldid=1958443))

//Some extensions you can pick//
(TODO: add links)

Code; Vagrant, puppet; tgr (but: Not too useful in 2016 according to Tgr)

Write tests for modules that are in the stable MobileFrontend extension and have low code coverage

[edit]
Despite these features being surfaced in the stable version of [MediaWiki's MobileFrontend extension](https://www.mediawiki.org/wiki/Extension:MobileFrontend) they have very little [code coverage](https://en.wikipedia.org/wiki/Code_coverage):

TODO: Add examples

 Let's get these up to at absolute minimum 50%

See https://phabricator.wikimedia.org/T103440 for more information.

Expected: Update the test coverage in at least one of the modules listed above by 5%.

QA; mobilefrontend, qunit; Baha

Add screenshots of MediaWiki extensions or skins to mediawiki.org

[edit]
This is already an advanced beginner task (we also offer beginner tasks that are way easier and take less time, but this task is very useful if you plan to continue with coding related tasks.)

* Set up a Vagrant instance (your development environment) - see [this wiki page](https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker) for instructions
* In your development environment, install a [MediaWiki extension of your choice  and which also does not yet have a screenshot](https://www.mediawiki.org/w/index.php?search=incategory%3A%22Extensions+used+on+Wikimedia%22+incategory%3A%22Extensions+without+an+image%22&title=Special:Search&profile=default&fulltext=1), on the extension's home page on mediawiki.org, and if possible, that is also installed on Wikimedia sites
* Make a screenshot of the extension (if possible, please only display the content within your browser window, and do not include elements of your browser software itself or even your operating system) - [read more information about good screenshots here](https://www.mediawiki.org/wiki/Help:Screenshots)
* [Upload your screenshot of the extension to Wikimedia Commons](https://commons.wikimedia.org/wiki/Special:UploadWizard) (use "MediaWiki screenshot" when a license is asked)
* Insert the image into the home page of the extension (use the `|image = ` parameter of the [Extension template](https://www.mediawiki.org/wiki/Template:Extension))

Doc/Training; mediawiki, screenshots, extension; Andre/Niharika/Legoktm

Help fix the localisation/internationalisation of MediaWiki

[edit]
Read the [internationalisation hints](https://www.mediawiki.org/wiki/Localisation#Internationalization_hints) (ideally, the whole Localisation page), keep the [messages API manual](https://www.mediawiki.org/wiki/Manual:Messages_API) at hand.

Pick 3 [i18n tasks](https://phabricator.wikimedia.org/maniphest/query/uojcohgxGwqq/#R) and/or [MediaWiki open support requests](https://translatewiki.net/wiki/Support/Open_requests#MediaWiki) (translatewiki.net threads). Comment on each bug report or thread to say that you're working on it; add Nemo to the Subscribers/CC list on Phabricator if missing.

[Triage](https://www.mediawiki.org/wiki/Bug_management/Triage) the request appropriately to identify the issue and the correct action to take. Submit patches to gerrit, or provide the translator with the information needed to translate the messages (by [editing their /qqq subpages](https://www.mediawiki.org/wiki/Localisation#Message_documentation)), or reject the request if the message shouldn't be changed.

[Add reviewers](https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews#Add_reviewers) to your patches in Gerrit: at least Nemo. All questions on each task will be asked and answered on the relevant bug, patch or thread.

Post here a link to a gerrit change, bug or thread for each of the 3 issues; the task will be accepted here when they are marked merged/closed.

Code; i18n, php, language, l10n; Nemo

Add licenses to 3 MediaWiki extensions so they appear on Special:Version page

[edit]

TODO: This requires thorough checking of the codebase, hence improve the task description and potentially talk to Ricordisamoa before offering this task! 

Some MediaWiki extensions are missing "license-name" in extension.json or $wgExtensionCredits. This means no license is specified for them in Special:Version (e.g. https://en.wikipedia.org/wiki/Special:Version)

To fix this, you will need to make changes similar to https://gerrit.wikimedia.org/r/#/c/264553/ in the code bases of extensions. One needs to check the LICENSE or COPYING file to verify which license the extension has, and then add the license-name.

As well, some extensions are possibly missing a LICENSE or COPYING file, which would result in a broken license link.

You are expected to find three extensions missing license information (for example by checking Special:Version of some MediaWiki sites, or by checking the code via downloading the extension repositories via https://www.mediawiki.org/wiki/Download_from_Git#Download_all_extensions if you have enough internet bandwidth), write three separate patches fixing the problem, putting your patches into Wikimedia Gerrit, and receiving a +1 or a merge.

https://phabricator.wikimedia.org/T123943

Doc/Training; json, license; Andre, aude, Reedy

Pywikibot: Add one doctest to the library

[edit]
Add one doctest to a docstring in the Pywikibot library

See https://phabricator.wikimedia.org/T120024

doctest are pieces of text in docstrings that look like interactive Python sessions.

They are included in the documentation generated by Sphinx, such as https://doc.wikimedia.org/pywikibot/api_ref/pywikibot.data.html#pywikibot.data.api.Request , allowing quicker understanding of how to use a class or function.

Pywikibot only has a few doctest. By adding more, we will help users quickly understand the functionality.

When you submit a change to be reviewed, it will automatically be checked for syntax errors with a report of any syntax errors will so you can fix them.

Pywikibot is a Python-based framework to write bots for MediaWiki. See https://www.mediawiki.org/wiki/Manual:Pywikibot for more information. See https://www.mediawiki.org/wiki/Manual:Pywikibot/PAWS for a easy way to explore Pywikibot. Patches can be submitted via Gerrit (you need a MediaWiki.org account). See 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. 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 ).

Code, Doc/Training; python, doctest; jayvdb

Fix 3 todos in MediaWiki code

[edit]
A TODO is a reminder stored in a code comment. Do 3!

* Pick 3 todos from the list at https://doc.wikimedia.org/mediawiki-core/master/php/html/todo.html : each box is one todo, where the cell content briefly describes what you are expected to do and the header links the code file.
* Understand them and if necessary edit the todo itself to clarify for future fixers.
* Complete the todos you have selected and remove the todo notes from the code!
To complete a todo means to accomplish what the todo text says or to supersede it in another way, e.g. by executing the "order" that it contains (examples: "document this function", "move this method elsewhere", "This test method should be split").

All the todos are in MediaWiki, so you have to follow the [general instructions](https://www.mediawiki.org/wiki/Google_Code-in_2015#Instructions_for_GCI_students) to [send a git patch](https://www.mediawiki.org/wiki/Git/Tutorial) in the [mediawiki/core repository](https://phabricator.wikimedia.org/diffusion/MW/). If you want, you can also select [todos from one of hundreds MediaWiki extensions](https://tools.wmflabs.org/mediawiki-mirror/html/dd/da0/todo.html), whose code is [in other mediawiki repositories](https://phabricator.wikimedia.org/diffusion/query/xSM3MiBclJ0T/#R).

Code, Doc/Training; mediawiki, php, doxygen, todos, technical-debt; Nemo

Make MediaWiki documentation translatable for your first time: just one page!

[edit]
You'll be upgrading existing English text and translations so that they are translatable with MediaWiki's Translate extension, which greatly improves translation workflow hence making coverage of translated docs vastly broader. You must not add new translations yourself, that's forbidden by the rules.

Detailed steps available at https://www.mediawiki.org/wiki/Project:Language_policy/Migration_list#Google_Code-in_task_description

Before submitting this task, you need: at least ONE page marked for translation; and a total of at least 20 paragraphs imported from a previous translation (technically, 20 contributions in the "Translations" namespace, as visible from your [[Special:Contributions]] page).

TODO: When your work on this task is approved, consider the [second task](https://codein.withgoogle.com/tasks/123) to show what you learnt!

Doc/Training, Outreach/Research; i18n, wikitext, translation, multilingualism, l10n; Nemo

Localize Huggle UI

[edit]
Some strings are hardcoded to English language. Make them localizable / translatable. See the full task description here: https://phabricator.wikimedia.org/T67950

In order to finish this task, you should find and replace at least 20 items that are currently hard-coded.

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.

Code; beginner; c++, l10n, i18n; Petr, Ankita

Blog about your GCI experience (findings and learnings) with Wikimedia

[edit]

Note: As per 2018, this task might be more problematic due to GDPR. Google recommends to not have blogpost tasks. 

To claim this task, you must have completed at least 3 GCI Wikimedia tasks.

Take some time to reflect on the past GCI weeks with Wikimedia & share your thoughts with the world!

What was good? What did you learn, socially & technically? What could be improved?

Did you find enough interesting tasks? Which tasks did you miss? Was a task harder than expected and you are proud that you solved it? How was the interaction on IRC, mailing lists, Phabricator, Gerrit? How easy was setting up your development environment? Which documentation pages would you improve for the next contributor and how? (It's a wiki - you can edit it!)

Do you plan to continue contributing? Did you subscribe to some of Wikimedia's [mailing lists](https://lists.wikimedia.org/mailman/listinfo) to follow&join discussions? What is the next thing you want to work on? Have you checked [New Developers]((https://www.mediawiki.org/wiki/New_Developers) or [Good first bugs](https://www.mediawiki.org/wiki/Good_first_bugs) for more ideas?

These questions are just ideas: no need to answer (all of) them. But we do want to hear more from you than "It was a great experience. Some tasks were hard but I learned a lot." We helped you, you help us, so we can all learn together!

Publish your text on your personal blog (if you don't have one, consider creating one!) or any public place which is appropriate to reach more students like yourself. Your text must be published under a free [CC-BY or CC-BY-SA license](https://creativecommons.org/choose/). Including an image is welcome but not mandatory. You can write in English or your own language.

Please post the link (URL) here and also [add it to the wiki page](https://www.mediawiki.org/wiki/Google_Code-in_2016#Wrap-up_blog_posts).

Outreach/Research; gci, text, experience, summary; Andre, Nemo

Pywikibot: Improve docstrings to the Pywikibot library

[edit]
Amend one docstring to completely and accurately summarise the behaviour of a method, documenting its inputs and outputs.

https://phabricator.wikimedia.org/T118423 Examples: https://gerrit.wikimedia.org/r/#/c/262668/ https://gerrit.wikimedia.org/r/#/c/262667/

Documentation is automatically extracted from the docstrings in the Pywikibot library, and converted into html using Sphinx to create https://doc.wikimedia.org/pywikibot/api_ref/index.html

Many methods in the library do not have adequate docstrings that describe the parameters, return type and exceptions that may occur.

These should be added to docstrings using epytext fields.

When you amend a docstring and submit it to Gerrit, a Jenkins job will automatically validate the docstring, and -1 the changeset if it includes syntax errors.

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

Doc/Training; python, pywikibot; jayvdb

Add documentation to 3 of the most used undocumented pages on Commons

[edit]
Wikimedia Commons is a file repository used amongst all the projects of the Wikimedia Foundation (including Wikipedia). We use many wikitext templates in them, but many are poorly documented and many of the most used templates on Commons do not have documentation pages that meet current community standards. The task is to find and document such pages:

1. List of templates in need of documentation can be found at [this page](https://commons.wikimedia.org/wiki/User:Jarekt/e), and I will try to keep it up to date. Also [this database query](http://quarry.wmflabs.org/query/6313) can be used.
2. Documenting templates should follow best Commons practices and should include:
* /doc subpage and [Template:TemplateBox](https://commons.wikimedia.org/wiki/Template:TemplateBox).
* description of all the input parameters (marked with {{{...}}} brackets) and will require studying the template wikicode and possibly the code of pages using it.
* All the categories should be at the /doc page and all the interwiki links should be done through [Wikidata](https://www.wikidata.org/).
* If edits need to be done to protected templates than a message should be left at the template talk page with [Template:Edit_request](https://commons.wikimedia.org/wiki/Template:Edit_request).
* Examples of well documented pages: [Template:Documentation/doc](https://commons.wikimedia.org/wiki/Template:Documentation/doc), [Template:Description/doc](https://commons.wikimedia.org/wiki/Template:Description/doc), [Template:Artwork/doc](https://commons.wikimedia.org/wiki/Template:Artwork/doc)

See also:

* https://phabricator.wikimedia.org/T120366 for more info and future discussion about this task
* https://commons.wikimedia.org/wiki/Commons:TemplateData
* https://commons.wikimedia.org/wiki/Special:MostTranscludedPages for live examples.

Code, Doc/Training; commons, templates, documentation; JarekT

Transcribe music sheet images into score tags on three pages on Wikipedia (2017/2018)

[edit]
This is a task for people who like music. :)

Musical articles on Wikipedia pages often have an image of sheet music to show a motif or incipits, etc. However, built into Wikipedia is [a MediaWiki extension called "Score"](https://www.mediawiki.org/wiki/Extension:Score) to display sheet music more natively than with images. It also allows for playback so others can listen to the music!

Your task is:
1. Learn [Lilypond](https://en.wikipedia.org/wiki/Help:Score)
2. Find and select 3 musical articles that use images for a music sheet on a Wikipedia page. (This does not have to be the English Wikipedia.)
3. Make sure you are logged in. (Create an account on Wikipedia via the "Create account" link at the top, if you haven't done already.)
4. Transcribe the images into Lilypond, replacing the images by the `<score>` that you have written, and publish your changes on those pages. An edit summary for your changes like "Convert musical sheet image into a score" or something like that is welcome, so other Wikipedia authors know what you have been doing in your Wikipedia edit. [General information on editing wiki pages is available.](https://www.mediawiki.org/wiki/Help:Editing)
5. Provide links to your changes here in this GCI task.

User Interface, Outreach/Research; music, lilypond, sheets, scores

Add two MediaWiki extensions to zuul/layout.yaml, so Jenkins can run builds

[edit]
It was noticed that [Jenkins](https://en.wikipedia.org/wiki/Jenkins_(software)) was silent on some patches for extensions in https://phabricator.wikimedia.org/T175794 when those patches were submitted into Gerrit.

To keep things clean and make Jenkins track all extensions, run builds and tests for them, it would be good to include missing extensions in the file `zuul/layout.yaml` in the [`integration/config/`](https://phabricator.wikimedia.org/source/integration-config/) Git repository. 

You are expected to add such a [CI](https://www.mediawiki.org/wiki/Continuous_integration) test into [Zuul](https://www.mediawiki.org/wiki/Continuous_integration/Zuul) for two code repositories (extensions):

* mediawiki/extensions/Extension1
* mediawiki/extensions/Extension2

Please provide two separate patches in Wikimedia Gerrit, one for each of the two code repositories. See https://www.mediawiki.org/wiki/Gerrit/Tutorial for how to set up Git and Gerrit.

https://gerrit.wikimedia.org/r/#/c/373408/ is an example change on [SendGrid extension](https://www.mediawiki.org/wiki/Extension:SendGrid) on a similar thing that needs to be done. When working on a patch, make sure the location of where the extension is added should be in alphabetical order as to make it easy and clear. :)

Updating the task description of https://phabricator.wikimedia.org/T183674 is welcome once your patches are in Gerrit: Use "Edit Task" in the right menu. If you don't have an account in Wikimedia Phabricator, see https://www.mediawiki.org/wiki/Phabricator/Help

Code, QA; yaml, zuul, jenkins

Beginner: Take screenshots of Commons Android app in your native language (2019)

[edit]
The Commons app allows Android users from all around the world to upload pictures for use in Wikipedia, Wikivoyage, etc.

As part of the app's localized documentation, we need screenshots in as many languages as possible.

Your task is to take screenshots of the app in your own native language.

Steps:
1) Check whether your native language (for instance "Telugu") is on this list: https://github.com/commons-app/apps-android-commons/wiki/Languages If it is not on the list, it unfortunately means that the app is not localized to this language and uses a fallback language, and thus you can not claim this task.
2) Claim this task, and post a comment saying what is your native language, for instance "Telugu".
3) Follow the instructions at https://github.com/commons-app/apps-android-commons/issues/960#issue-274097308 to take the required screenshots and send us a Git pull request.
4) Post the URL to your pull request here, then submit for review.

Note for people who have several native languages: Please choose your language which is the lowest on the list at https://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers, or one which is not in that article. For instance, if you can fluently speak both Telugu and English, please choose Telugu. If you can fluently speak both Italian and Slovenian, please choose Slovenian because it is not on that list. Please avoid English, because we will probably get enough screenshots in English. Thank you!

Documentation/Training; android, git, screenshots

Design a sticker (2017/2018/2019)

[edit]
''(Explain what should be on the sticker here.)''

- For this task, you must use software which allows creating and editing [Vector Graphics](https://en.wikipedia.org/wiki/Vector_graphics). If you don't know the difference between vector graphics and [bitmap graphics (also called raster graphics)](https://en.wikipedia.org/wiki/Raster_graphics), then please read the Wikipedia articles and [look at this image](https://commons.wikimedia.org/wiki/File:VectorBitmapExample.svg).
- Your design work must be submitted as a vector [.svg](https://en.wikipedia.org/wiki/SVG) file (which can be resized without pixellation). The design must not include any bitmap graphics (examples for bitmap file formats that are not allowed: PNG, JPEG, BMP, TIFF, WEBM, etc). You are not allowed to convert a bitmap file to an SVG file.
- Your work must be [free](https://en.wikipedia.org/wiki/Free_content) and must not include any non-free materials. If you re-use another author's design work, the [license](https://en.wikipedia.org/wiki/License) of the author's work must allow this, and you must give credit as required by the license. Please mention the [free CC license](https://creativecommons.org/licenses/) under which you publish your work, for example: Creative Commons Attribution 4.0. If you re-use another author's design work, the license of the author's work must allow this, and you must give credit as required by the license.
- Upload your design to Wikimedia Commons and [use a descriptive filename](https://commons.wikimedia.org/wiki/Commons:File_naming). Uploading to Commons also requires you to license your work. OR: Upload your design in the [Phabricator task](https://phabricator.wikimedia.org/Txxxxxx). (If you do not have a Wikimedia Phabricator account yet, [create one](https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account)!)

Design, Outreach/Research; conference, logo, stickers, community, graphics

Create a Wikimedia site configuration change (2018)

[edit]
# Requirements
You will need basic knowledge of PHP or any other programming language. 

# Task
From time to time, one of the many Wikimedia communities request a [configuration change](https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes). This is usually done by a change in [operations/mediawiki-config](https://github.com/wikimedia/operations-mediawiki-config) based on a request created under [Wikimedia-Site-requests](https://phabricator.wikimedia.org/tag/wikimedia-site-requests/). 

A site configuration change is something like this:

* Create or amend a namespace ([example](https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/463582))
* Create or amend a user group ([example](https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/460701))
* Changing a project logo ([example](https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/460773))
* Add a domain to `wgCopyUploadsDomains` ([example](https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/460700))
* Add an [account creation IP throttling exception](https://meta.wikimedia.org/wiki/Mass_account_creation#Requesting_temporary_lift_of_IP_cap) ([example](https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/464122))

Your task will be the following:
1. Check the [Wikimedia-Site-requests project](https://phabricator.wikimedia.org/tag/wikimedia-site-requests/) and pick one suitable configuration change (see examples above). I strongly recommend you to confirm that you can work on the task you picked, as some requests require special knowledge and/or permissions. 
2. Once you have a configuration change you'll be working on, claim the task on Phabricator and change its priority to Normal. (You will have to [register an account on Phabricator](https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account) for this.)
3. Be careful to make sure there is community consensus.
4. [Propose a patch](https://www.mediawiki.org/wiki/Gerrit/Tutorial) for the`operations/mediawiki-config` repository in Wikimedia Gerrit fulfilling this configuration change (see examples above).

# Next task
You can [get the change deployed](https://codein.withgoogle.com/tasks/5149827009609728/) after you completed this.

# Materials
* [How to request a configuration change](https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes)
* [operations/mediawiki-config repository](https://gerrit.wikimedia.org/g/operations/mediawiki-config)
* [Gerrit tutorial](https://www.mediawiki.org/wiki/Gerrit/Tutorial)
* If you want to try to work with Gerrit before working on this, use [this task](https://codein.withgoogle.com/tasks/4513104365879296/) for it.

Code; mediawiki, configuration, php

Deploy a Wikimedia site configuration change (2018/2019)

[edit]
# Prerequisites
* You must first complete any of those tasks before working on this
    * [1](https://codein.withgoogle.com/tasks/5612296471576576/)
    * [2](https://codein.withgoogle.com/tasks/5763295794429952/)
    * [3](https://codein.withgoogle.com/tasks/5470221453230080/)
* Install the `X-Wikimedia-Debug` browser extension ([Chrome](https://chrome.google.com/webstore/detail/wikimediadebug/binmakecefompkjggiklgjenddjoifbb), [Firefox](https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/)). During deployment, you may need to connect to special debugging servers. This extension will allow you to connect to this debugging server. 

# Task
You must have already submitted a configuration change to Wikimedia Gerrit, which is awaiting deployment. Such deployments happen at certain times (the so-called "[SWAT windows](https://wikitech.wikimedia.org/wiki/SWAT_deploys)"), which occur three times a workday (except Friday).

# Steps
1. Choose a SWAT window (EU Mid-Day SWAT, Morning SWAT or Evening SWAT)
2. Login on [Wikitech](https://wikitech.wikimedia.org/w/index.php?title=Special:UserLogin&returnto=Deployments) (the same login and password that you use for logging into Gerrit can be used).
3. Edit the [Deployments page at Wikitech](https://wikitech.wikimedia.org/wiki/Deployments) and add your patch to the SWAT window of your choice.
4. Before the window starts, join the `#wikimedia-operations` [chat channel on Freenode IRC](https://www.mediawiki.org/wiki/MediaWiki_on_IRC). (If you have not used IRC before, the beginner task "Get on Internet Relay Chat" could be a task to do first.)
5. The SWAT deployer and the mentor will guide you through the deployment process. 

# Add this to the Deployments wiki page
```
{{ircnick|your irc nickname}}
* [config] {{gerrit|changeid}} Commit message
```

Code; mediawiki, configuration, php

Learn how to use Gerrit for code review, by submitting a patch (2019)

[edit]
Wikimedia uses [Gerrit](https://gerrit.wikimedia.org/) as its code review system. That's where you propose code changes and others will review them before your code changes will get merged and become available to everybody.

Many Wikimedia tasks want you to submit your work to Gerrit. Gerrit has a test repository called `sandbox`. In this task, you should upload a patch against that repository. 

Please read through [Gerrit tutorial](https://www.mediawiki.org/wiki/Gerrit/Tutorial). With the help of this tutorial, upload a patch to [sandbox repository](https://gerrit.wikimedia.org/r/admin/projects/sandbox). This commit should add new file "yourusername.txt" (please use the same nickname as on the GCI site), which can contain any text you want. The file should be located in `/gci` folder.

You also want to read https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines, which guides you how to write good commit messages.

Code, outreach/research; beginner; git, gerrit

Retrieved from "https://www.mediawiki.org/w/index.php?title=Google_Code-in/Admins&oldid=6153860"