Google Code-in/Admins

Jump to navigation Jump to search

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 getting accepted[edit]

For tasks that are **proposed** for Wikimedia's potential participation in [[ | Google Code-in 2015 ]]. 
If Wikimedia will get accepted by Google, these tasks will be made available to GCI students once the contest has started.
Tasks **must** have at least one mentor defined: Add a comment "I will mentor this in #GCI2015".
  • Find org admins. Preferably from more than one timezone.
  • Announce that we applied (2014 example, 2016 example)
  • Reach out to potential mentors. Instead of becoming an "my email inbox" bottleneck, give people a link to the wiki talk page to ask any questions.
    • Explicitly reach out to Google Summer of Code and Outreachy mentors and students from the previous round.
    • Explicitly reach out to projects listed on New Developers such as Commons Android App maintainers
    • Explicitly reach out to GCi mentors and students (if you can find their email addresses in Gerrit) from last year (see table on the wikipage)
    • Reach out to Possible mentors
    • Consider reaching out to tool maintainers on ToolLabs.
    • Reach out to numerous mailing lists: pywikipedia-l@, mediawiki-i18n@, multimedia@, wikitext-l@, wikidata-l@, qa@, analytics@, labs-l@, mobile-l@, Kiwix, design@, potentially translators-l@ for translation tasks (allowed since 2017). Provide URLs to their latest Phabricator/issue tracker tickets marked as "easy" in their fields of interest. See 2016 links. Consider bundling that email in groups of 5-9 lists per message, to minimise the amount of duplicates that people receive.
    • Generic wikitech-l email examples from 2013: 1, 2, 3, 4.
    • Ask on certain wiki pages. See 2016 links. Examples from 2014: English Village Pump, German Technik-Werkstatt, Commons Village Pump, Lua,'s Gadget kitchen, Template Data.
    • Ask GCI mentors from last years. (TODO: email subject "Google Code-in 2016 and Wikimedia: Interested in mentoring again?")
  • Create placeholder beginner tasks (2017 example) as Google wants to see a bunch of example tasks
  • Help finding tasks:
  • List which people are an org admin on the wiki page.

After getting accepted[edit]

  • Announce that we are in (2013, 2014, 2015, 2016)
    • Also announce via meta:Social media services to create awareness and reach potential students?
  • Watch the Mentors table for additions and invite mentors via Google's site so they can register. They will receive an email with registration instructions. Also check the "Pending invites" and nag.
  • Update wikipage to say that we have been accepted as an org
  • Update wikipage to say that tasks should be created on the Google site directly
  • Update Google-Code-In project description on Phabricator if needed.
  • Contact Product Managers in WMF to make them and their teams aware (if they don't follow wikitech-l@ closely) (email subject "Will your team mentor some Google Code-in tasks?", 2017-11-13)
  • 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. 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
    • Run Google's "python --api-key XYZ whatever.csv" from
    • 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 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)
  • 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
  • Schedule a (Hangout; IRC) info session for new mentors (2016; 2017)
  • Send email to all mentors when Google Code-in starts (Firefox allows to copy a table column by pressing Ctrl, or Command on Mac): Email template
    • Include 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 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 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, or when creating tasks put some "[DONT PUBLISH BEFORE 20171231]" prefix or such into the task summary. Link to Google's "Mentor Responsibilities". If there are any issues with students (such as plagiarism) please let the org admins know.
  • Push two social media posts by contacting digitalmedia@ (2016 example for mentors; 2016 example for students)

General recommendations while contest is running[edit]

Daily tasks while running[edit]

  • Review new unapproved "Draft tasks" (which were added recently by mentors and should get reviewed and then published by org admins). Check their quality and publish them.
  • Check tasks "waiting for review" (<36h intended) and potentially provide feedback to help mentors
  • Check number of unique tasks via in "Open"/"Reopened" state (>50 intended), potentially publish more ready tasks when getting close to the minimum limit of 50
  • Check for new tasks in "Unapproved" and "Unpublished" state and review/publish/subscribe to them
  • 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]

Before the contest has ended[edit]

  • Contact mentors, thank them, ask them to name remarkable students, and to provide general feedback (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)
  • When reviewing the last tasks, add "Here are more tasks (link); see you on IRC, the mailing lists, Phabricator and Gerrit" at the end of the contest in mentors' in comment. We do not have email addresses to contact students and we want to keep them involved after the contest ends, so we need to be able to actively ask "Do you fancy trying some more stuff?" and point to e.g. "easy", un-mentored bugs or software projects recommended to get started?
  • The last two weeks, potentially be a bit "stricter" with prospect finalists to get more "quality"?
  • Create "Write a blogpost about your GCI experience" task

After the contest has ended[edit]

  • Update Google Code-in 20xx page that the contest is over (2015 example)
  • Move subpage link on Google Code-in to "Past programs" (2015 example)
  • Advertise students' blogposts on wikitech-l (2017 example)
  • Decide on Google Code-in Grand Prize winners for this organization: 1) quality of work, 2) thoroughness of work, 3) creativity of their work. Community involvement like helping other students on IRC etc. can be included. (2014; 2015; 2016).
  • Send final summary to wikitech-l (2015 example; 2016 example)
  • Get some GCI-related blogposts out (2015: phab:T124656 and phab:T124781; 2016: phab:T156639; 2017: phab:T178481)
  • Potentially tweet about it (2016 example)
  • Close any Phab placeholder tasks as declined (2016 example).
  • Email mentors after winners have been announced about feedback to Google, saving work, heads-up about grand prize winners trip (2017 example)
  • Archive Phabricator project
  • Make best students aware of the next Hackathons, plus available scholarships and their deadlines (2016 example, 2017 example). Note: Deadline might be before end of GCI!
  • Potentially unsubscribe org admins from the admin mailing list so they don't receive spam

GCI summit[edit]

  • Define who of the mentors/admins to attend (mentors with most tasks, via private emails) (2016 example)
  • Forward email from Google containing the PO number to the person to attend the summit
  • Afterwards, attendee to invoice WMF (via accountspayable) to get reimbursed
  • 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)

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 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? Are there any public Wikimedia contributions you could link to (for example your username or your Gerrit activity)? This would help us to get a better idea. Thank you! (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 ! 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)[edit]

GCI mentoring, like most free/libre software collaboration efforts, [relies heavily on IRC]( for success. You don't understand why? Come see yourself!

If you have not chatted in Wikimedia IRC channels yet, you can claim this task. You will:

* install an [IRC client]( you like, but not IRC clients listed as "web" or [proprietary]( (for example irssi, HexChat and KVIrc are good, mIRC and are not ok);
* connect to the "Freenode" network and register your nickname;
* join the channel/room called `#wikimedia-dev` ([instructions](;
* introduce yourself on the channel (one sentence is enough). Please do mention that you are on IRC for a Google Code-in task - the channel is public and some people might not know what Google Code-in is;
* wait at least one hour before leaving.

When you have completed the steps above and the time has passed, you are done: just submit this task for review; mention the nick you used if different from the one you have here.

OPTIONAL: If you want to use your time at best, follow the conversation and the updates on the channel: you will probably have interesting occasions to help another person like you or be helped, click an instructive link, fix some bug. You can also join [another IRC channel]( in your native language, for instance.

OPTIONAL: You may also want to subscribe to one of our [technical mailing lists]( for longer help and training.
  • ("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)[edit]

1. Read [How To Triage](
2. [Log into our issue tracker]( (called Phabricator)
3. Go to [Phabricator's advanced search](, set the "Statuses" field to "Open", set "Projects" to "testme" & set the "Updated Before" field accordingly (see [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 and some might require [setting up MediaWiki yourself]( - 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]( 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](
* 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]( on the extension's home page on
* 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]( (also [read about licenses]( 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](
* 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](

bd808, Tgr, unicornisaurous, Andre, Srishti

Clonable tasks from 2016[edit]

Create MediaWiki-Vagrant role for a MediaWiki extension (2015)[edit]

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


* [create a task]( 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](; you can use [RDoc markup]( 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](
* after the patch is merged, add the role name to the wiki page of the extension ([example](

//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]( they have very little [code coverage](

TODO: Add examples

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

See 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[edit]

A significant number of extensions and skins on do not have a screenshot in their infobox. Please pick one extension or skin from the below categories to take a screenshot of.


Tell us in this task which extension or skin you have chosen.

Please see for details and more links on how to take screenshots, where they should be uploaded, and how to add them to the extension/skin page.

Doc/Training; mediawiki, screenshot, extension, skin; Andre/Niharika/Legoktm

Help fix the localisation/internationalisation of MediaWiki[edit]

Read the [internationalisation hints]( (ideally, the whole Localisation page), keep the [messages API manual]( at hand.

Pick 3 [i18n tasks]( and/or [MediaWiki open support requests]( ( 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]( 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](, or reject the request if the message shouldn't be changed.

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

To fix this, you will need to make changes similar to 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 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.

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


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

They are included in the documentation generated by Sphinx, such as , 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 for more information. See for a easy way to explore Pywikibot. Patches can be submitted via Gerrit (you need a account). See 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 and the #pywikibot IRC channel (see ).

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 : 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]( to [send a git patch]( in the [mediawiki/core repository]( If you want, you can also select [todos from one of hundreds MediaWiki extensions](, whose code is [in other mediawiki repositories](

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

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]( 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:

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: and

Source code is available at 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]

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]( to follow&join discussions? What is the next thing you want to work on? Have you checked [New Developers](( or [Annoying little 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]( 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](

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

Documentation is automatically extracted from the docstrings in the Pywikibot library, and converted into html using Sphinx to create

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 for more information. Patches can be submitted via Gerrit (you need a account). See 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 and the #pywikibot IRC channel (see ).

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](, and I will try to keep it up to date. Also [this database query]( can be used.
2. Documenting templates should follow best Commons practices and should include:
* /doc subpage and [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](
* If edits need to be done to protected templates than a message should be left at the template talk page with [Template:Edit_request](
* Examples of well documented pages: [Template:Documentation/doc](, [Template:Description/doc](, [Template:Artwork/doc](

See also:

* for more info and future discussion about this task
* for live examples.

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

Transcribe music sheet images into score tags on three pages on Wikipedia (2017)[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"]( 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](
2. Find and select 3 musical articles that use images for a music sheet on a Wikipedia page
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.](
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]( was silent on some patches for extensions in 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/`]( Git repository. 

You are expected to add such a [CI]( test into [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 for how to set up Git and Gerrit. is an example change on [SendGrid extension]( 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 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

Code, QA; yaml, zuul, jenkins