Google Summer of Code/Administrators

Participating in Google Summer of Code 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

 * Find and define two organization admins
 * Apply as an organization by filling out the form
 * Check the general manual for admins and mentors (?)
 * Create Google Summer of Code 20XX page (using information from Google Summer of Code 2016 as a guideline)
 * link to that page from Google Summer of Code and Template:GSoC
 * Request and create "Google-Summer-of-Code-20xx" project in Phabricator
 * Try to connect the priorities of community wishlist and other tech priorities with the Google Summer of Code project, with an intention to bring out possible projects from there. T126961 should serve as a model for the same. For org Admins, this means exploring the domains/tasks which could serve as potential projects.

After getting accepted

 * Send out an email to Wikitech-l/Wikimedia-l (T91374; 2016 example)
 * Update mw:Google_Summer_of_Code_20xx from "Wikimedia has applied" to "Wikimedia has been accepted"
 * Start cleaning out https://phabricator.wikimedia.org/tag/possible-tech-projects/
 * Looking good, details missing: Needs Discussion + comment explaining what is missing.
 * Clearly not for this round, but maybe next: Re-check in August 2015 (new column at the far right).
 * Not a good possible project: remove project tag.
 * Reminder: A good possible project will be about 2 weeks worth of effort for an experienced dev and 3 months for a complete beginner
 * Also note, as we start accepting repeat participants, we can keep in some harder projects as well.
 * Go through the "Needs Discussion" column:
 * Agreement, template filled, two mentors: Moved to Featured column.
 * Agreement, template filled, 0-1 mentors: Missing mentors
 * No agreement until right before student application period opens: Re-check in next round
 * Above mentioned template:
 * Primary mentor: @mentor
 * Co-mentor: @mentor
 * Other mentors: (optional, Phabricator username(s))
 * Skills: Tools/Languages/Platforms
 * Estimated project time for a senior contributor: x weeks
 * Micro tasks: Phabricator tickets
 * Keep an eye on the above tickets as micro tasks get exhausted quickly and you'll have to ping mentors for more quite frequently
 * Once the application period opens, send an email to Wikitech-l with the updates ( 2016 example )

Proposal submission phase

 * Every prospective intern needs to make a subtask of the original project ticket (by clicking Create Subtask on the right) and use this for their proposal.
 * Some examples of good proposals can be found here: https://phabricator.wikimedia.org/T93106, https://phabricator.wikimedia.org/T76199
 * IMPORTANT: All project related communication between mentors/student MUST occur on the project ticket and NOT on the proposal ticket to ensure that late-incoming students can see all the communication in one place. If you see anyone not following this, please correct them and ask them to move their discussion to the main ticket. (Feel free to mention this in the initial email you send out to wikitech-l)
 * Similarly, private IRC chats/emails is not encouraged. Chat in public IRC channels is very welcome.
 * Holding an IRC party a week or so before deadline turned out to be a very good idea. It introduces students to IRC and helps answer everyones questions at the same place. Logs from last year's chat can be found here https://meta.wikimedia.org/wiki/IRC_office_hours/GSoC-Outreachy_2015_IRC_Party.
 * Remind students to submit proposal on official GSoC website too. Some didn't even know that was needed(!). We don't need the whole proposal in the official place, link to phabricator proposal is fine.
 * IMPORTANT: Candidates who are eligible for both Outreachy and GSoC should be asked to apply for GSoC only. Remember, we pay our Outreachy interns while Google pays GSoC ones. This makes it possible to have other interns for Outreachy who are ineligible for GSoC.

Selection Phase

 * When the application period is over, send out an email such as https://phabricator.wikimedia.org/T91374#1159227 to our mailing lists.
 * Outreach programs/Selection process is your guide for this task.
 * IMPORTANT: Only candidates who have completed a significant micro task are eligible for selection. If it's a coding project, a micro task counts as a patch in gerrit, hopefully related to the project. For late-incoming students, give them a week or so to complete a micro task but do not select a student without any contribution. Make this amply clear to them - so that they don't come up with the excuse that they were not told this was a requirement.
 * IMPORTANT: All mentors are advised to schedule at least one hangout with their chosen candidate before finalizing selection. This is more important than it seems. It weeds out fraudulent students and helps establish a rapport.
 * Don't forget to attend the deduplication meeting held by GSoC admins.
 * Send out an email to the lists when the selection phase is over and results are out. Mentors are not allowed to disclose results to students before the official announcement. Last year's announcement email: https://lists.wikimedia.org/pipermail/wikitech-l/2015-April/081617.html

Bonding period

 * Last year we asked the students to merge the main project task and their proposal task and copy over the content. In my opinion, this turned out to be confusing for the students and should not be repeated. The students should work with their proposal task as the main task (ignoring the original task for the project time period). All reports/evaluation tasks should be a blocker for this task.
 * Every project needs to have its Phabricator board created. Other requirements last year can be seen here: https://phabricator.wikimedia.org/T94166
 * Last year the students were asked to create the report task themselves. Not a good idea. Students are inherently lazy and most did not do it until I pinged them 5 times or so. Batch creation would make this easy for the org admins to do themselves. Same for weekly reports. Link students to example reports wherever possible. Everything from last year can be seen at https://phabricator.wikimedia.org/project/board/1035/?order=natural&filter=all
 * The report should be assigned to the mentor although the students need to fill up the required fields first.
 * IMPORTANT: Weekly/bi-weekly hangouts/IRC meetings between the student and mentors is a must. Make sure this is done.

After internship start

 * Keep an eye on the weekly reports. If the students lag behind by more than two weeks, ping them. Last year's tracking task: https://phabricator.wikimedia.org/T100998.
 * Consider hosting another IRC chat session before the mid-term evaluation where students can showcase their progress.

Mid-term evaluations

 * Tracking task from last year; https://phabricator.wikimedia.org/T102942 - Org admins can create tasks for students.
 * Report is must.
 * IMPORTANT: MVP must be completed and publicly hosted somewhere that mentors can follow along on the work. Any student failing to achieve this should not continue.
 * There will be some difficult discussions with mentors that must be had. Mentors cut students a lot of slack sometimes and can be overly generous. If the student became active a couple of weeks before the mid-term evaluation period, it's not a good sign. S/he should not be allowed to continue. Failing students for not doing the work is okay. (You might be tempted to change your mind if they plead, but please don't give in to these tactics.)

End-term evaluations

 * Tracking task for last year's evaluations: https://phabricator.wikimedia.org/T109204
 * Wrap-up report on Phabricator and blogpost can be the same. Lots of screenshots encouraged.
 * IMPORTANT: Get the past projects page updated Google Summer of Code past projects
 * Write up an email to the mailing lists announcing completion.
 * Write a blog post for Wikimedia blog: https://phabricator.wikimedia.org/T108054 -- Writing this takes some time and effort. Start early.
 * Wrap up IRC meeting: https://phabricator.wikimedia.org/T110929
 * Encourage students to participate in lightning talks to demo their project. (Not mandatory)
 * Last year I tried to start an experiment for sending goodies to students. This turned out to be a very bad idea. It should not be repeated. Cost of the goodies was about ~USD 30 each but cost of shipping was ~USD 100 each. USPS turned out to be a massive failure and some students had to be re-sent goodies via DHL. Some students haven't got them yet.

Some suggestions for the next round
Here I enlist some problems I encountered and ways to avoid them next time.
 * Contacting students! You read that right. There was just no way to contact students sometimes. They had no email address in their proposal and they won't reply to my Phabricator/Conpherence pings. In addition to this, it was very difficult to keep all student's information consolidated in one place. My solution to this problem is having a Google Form that is filled up by the students during the Bonding period. Possible fields:
 * Email address
 * Physical address
 * Name
 * Mentors
 * Project title
 * Phabricator handle perhaps some more...