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.

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".
 * 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 2015, 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).
 * 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.
 * Find org admins from more than one timezone!
 * 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, 2015)
 * Invite people who have expressed interest in mentoring via Google's site - they will receive an email with registration instructions.
 * Copy/import tasks into Google's site even though mentors are not registered yet in Google's site. 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 Google's site. API to import tasks: https://developers.google.com/open-source/gci/api
 * Creating recurring/clonable tasks: Use the "Instance Count" field when creating a task in Google's site. Consider using the bulk uploader.
 * Actively find/recruit more 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
 * Update wikipage to say that tasks should be created on the Google site directly
 * Announce start of contest on wikitech-l (2015)


 * Find beginner tasks:
 * "Create MediaWiki-Vagrant role for a MediaWiki extension"
 * Set up a development environment / Vagrant, install an extension, and prove via screenshot.
 * "Get on IRC task". "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.""
 * Ubuntu had a beginner task in 2015 to set up a wiki user home page (and get used to wikitext editing?), should we have that too?

General recommendations while contest is running
NOTE: This section is partially outdated, as Google switched from Melange to a new site in November 2015.


 * 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
NOTE: This section is partially outdated, as Google switched from Melange to a new site in November 2015.


 * 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 some point to wikitech-l (2014 example after first week; 2015 example after half time)

Before the contest has ended

 * 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 at the end
 * 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

After the contest has ended

 * 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)
 * 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.)
 * 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).
 * Send final summary to wikitech-l (2015 example)
 * Potentially get some GCI-related blogposts out (2015: T124656, T124781)

2015 feedback from T123920

 * The CI whitelist caused confusion (and waste of time as the student had to wait for half a day due to timezone differences just so someone else can say "recheck"). Either need more documentation on how to run tests locally, or ideally add all students to the whitelist at the beginning. https://gerrit.wikimedia.org/r/#/c/261322/ Without adding, only a subset of the tests is run by jenkins and that can cause confusion.
 * For beginner tasks: Set up a repository in Gerrit and have a beginner task that requires students to clone that repo, create a file named with their GCI username or something, commit the file to their local Git clone, and submit the patch for review? Might also help start making students test their patches themselves earlier.
 * Vagrant docs might need better documentation for Windows platform?
 * Not many students claimed the "Triage some #testme bug reports", maybe that choice was too limited?
 * How to encourage having more tasks with more than one mentor?
 * Better workflow for mentors creating tasks to tell admins they are ready to publish? Or is "Either add a "[READY]" prefix to the task summary to let org admins know, or contact them explicitly."  sufficient?
 * Part of GCI is "getting work/tasks done", part is "recruiting new contributors / community members"
 * We miss a "pipeline" how to direct students to further stuff (try GSoC if you are 17?) Point to local hackathons? / "GCI is missing a follow-up program for the best contributors. (Or maybe the MediaWiki/Wikimedia technical community is missing a non-time-limited mentorship system?)" Every year there are GCI participants with a "hire on sight" competence level and it would be great to keep them engaged.
 * Students sometimes still have no way to gauge the complexity / required skill level of a task, and making a task description perfect can be the enemy of good.

pre-2015

 * GCI Organization Advice (Jan 2016)
 * RTEMS mentor advice
 * Beginner tasks:
 * Haiku (2014): Run or compile the OS for the first time and prove by showing a screenshot with some change in it
 * Ubuntu (2015): Set up your wiki user page
 * Go on IRC, talk to an org admin or mentor.
 * Set up a Vagrant instance / your development environment.
 * Triage some old tasks in Phabricator

Unknown mentors
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.) If you have not contributed to Wikimedia yet, we encourage you to start contributing to Wikimedia! Thank you!''