Google Code-in/Admins

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.

NOTE: This page is partially outdated, as Google switched from Melange to a new site in November 2015.

Before getting accepted
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".
 * Create Google Code-in 20xx page and link from Google Code-in
 * Create #Google-Code-in-20xx tag in Phabricator with initial description:
 * Reach out to potential mentors 2015 example/list
 * Potentially go through open "gci2013"/GCI 2014 tickets in Phabricator and update/comment on them.
 * Fill out organization application form
 * Announce that we applied (2014 example)

Before contest starts

 * Announce that we are in (2013, 2014)
 * Copy/import tasks into Melange even though mentors were not registered yet in Melange. Gives a better overview about actual number of tasks. Set yourself as (temporary) task mentor and put the mentor name as temporary [prefix] into the task summary to search for and update those items once the mentor has registered in Melange.
 * Creating recurring/clonable tasks: Use suffix in title of recurring tasks like (03), (04) otherwise email threads are hard to distinguish. Consider using the bulk uploader.
 * Actively find/recruit mentors.
 * Generic wikitech-l email examples from 2013: 1, 2, 3, 4.
 * Specific mailing lists: pywikipedia-l@, mediawiki-i18n@, multimedia@, wikitext-l@, wikidata-l@, qa@, analytics@, labs-l@, mobile-l@, Kiwix, design@. Provide URLs to their latest Phabricator/issue tracker tickets, existing tickets marked as "easy" in their fields, and open tickets from GCI2013.
 * Contact GCi mentors from last year (see table on the wikipage); GSoC and FOSS OPW mentors and students; Possible mentors; consider tool maintainers on ToolLabs.
 * Ask on certain wiki pages. Examples from 2014: English Village Pump, German Technik-Werkstatt, Commons Village Pump, Lua, mediawiki.org's Gadget kitchen, Template Data.
 * Check https://www.mediawiki.org/wiki/Talk:Google_Code-in if there's some good ideas/mentors
 * Find outreach tasks like T561, find beginner tasks like "Triage three bug reports" or "Install MediaWiki environment locally and prove via screenshot" or such.
 * Actively ask mentors to also register in Melange
 * Update wikipage to say that tasks should be created in Melange directly
 * Add existing GCI tasks which were in Bugzilla to Google-Code-in-20xx project in Phabricator
 * Accept "connections" (=mentors) in Google Melange

General recommendations while contest is running

 * Task overview in Melange: Click "Columns" at the bottom and add the "Modified on" column. In combination with status "NeedsReview" you can easily check tasks getting close to the 36h deadline for reviews.
 * Actively find more mentors. Contact existing mentors without open tasks if they have some more.
 * Try to actively follow students' activity on IRC: 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. Annoying little bugs.

Daily tasks while running

 * Check for new "Unapproved tasks" (which were not in the system from the beginning and planned to get published over time, but were added recently by other mentors and should get accepted and published by org admins). Check their quality, potentially subscribe, publish them.
 * Check age of tasks in "NeedsReview" state (<36h intended)
 * Check number of tasks via in "Open"/"Reopened" state (>50 intended)
 * Check for new tasks in "Unapproved" and "Unpublished" state and review/publish/subscribe to them
 * If recurring tasks exist, order by title to check if enough are still open and if you should "publish" the next one (if using suffix number in a title) that's been unpublished so far.

Weekly tasks while running

 * Gather statistics on open/claimed/closed tasks and publish them as a diagram (2013 example)
 * Send summary (at least after first week) to wikitech-l (2014 example)

After the contest has ended

 * Decide on Google Code-in Grand Prize winners for this organization: Use Leaderboard, check variety and quality etc. of submissions. Example for 2014.

Food for thought

 * RTEMS mentor advice
 * Haiku had beginner tasks like running or compiling the OS for the first time and proving by showing a screenshot with some change in it.
 * Potential beginner tasks: Go on IRC, talk to an org admin or mentor. Set up a Vagrant instance.
 * Potential tasks at the end: Write a blogpost about your experience
 * Boilerplate text: Add template link for "Here are more tasks once GCI has ended" at the end of the contest?