Doing better on Google Summer of Code 2014

We'd still love to have you as part of our community, whether through GSoC or not! :)

(Disclaimer: My memory is somewhat foggy because I haven't run GSoC since I was named core committer ~5 years ago. slashrm/sumitk, please make any corrections.)

See http://www.google-melange.com/gsoc/events/google/gsoc2013 for exact dates. It changes slightly from year to year.

Once GSoC is Announced (~February - March)

During this period, Google opens the floodgates for mentoring organizations to apply for GSoC. We need to submit an application, and that application needs to include a list of mentors, and a list of project ideas (probably amongst other things that I forget now).

To pull this off, you need:

• Recruit Organization Administrators: 2-3 folks who act as the "public face" of the Drupal project in interactions with Google, prospective students, and other mentoring organizations. Personable people with a high degree of competence and follow-through, plus great communication skills are a must. Their responsibilities include turning in required "paperwork" (like the Mentoring Organization application), participating on the GSoC mailing lists and IRC channel, monitoring overall student/mentor progress to make sure there are no major issues, whip-cracking to make sure mentors/students turn in mandatory reports on time. Bonus points if they're GSoC alumni.
• Recruit Mentors: Ideally, 30+ folks, who can make a reasonable time commitment (~5-10 hrs/week) throughout the summer months (May - September). We want a broad range of skillsets and interests (front-end, back-end, Drupal.org folks, core developers, performance geeks, government, higher-ed, etc.), because we don't know what kinds of students we're going to get, nor what kinds of projects they'll be interested in. These people also need to be personable, patient, and have great communication skills, as well as some savviness to be able to give students enough freedom to keep them engaged and feeling awesome, but know when it's time to rein it in and set them back on track. Bonus points if they're GSoC alumni. In the past, we've "doubled up" mentors to ensure students had coverage even over vacations, etc. but I'm not sure if that practice kept on in later years.
• Canvas for project ideas: A link to an "Ideas list" is required material in the mentoring organization application. Ideally, we'd have at least 20-30 really strong project ideas for students to choose from, if they don't come prepared with their own. This is shockingly hard to do. You need to find projects that not only are a reasonable scope to finish in 2-3 months of development by a student or may or may not be a very adept programmer, but also something that will not kill the world if it doesn't get done, something that doesn't duplicate work that others are doing, and also something that isn't going to get done by someone else between February and September. All of these are a bit hard to suss out in a busy community with thousands of active developers. In the past, the way we've done it is create a "GSoC 200x group" (like this one) and canvassed for community ideas there. This is helpful, because then the community as a whole can comment and "vet" ideas ahead of students seeing them. However, making a new group each year kinda sucks because we have to re-create the subscriber list every year.

  Things that have worked well as projects in the past are cool ideas that have been on the shelf for awhile and are in absolutely no danger of being picked up (we got project usage statistics tracking that way), highly specialized "niche" contributed modules (recommendation engines, usability testing tools), and stuff like that. Projects that do not work well at all are things that are Drupal core-related (the review cycle is too unpredictable; even very established core contributors have had issues…), or things that are one part of a larger project that will screw up everything after it if they're not done (like, say, a major chunk of the D7 upgrade), and also, frankly, Drupal.org-related projects (though I'd love to change this). Sometimes students flake out. Sometimes mentors do, too. :\

• A concerted communication machine to get the word out about all of the above. Drupal Planet, DA newsletters, front-page posts, Twitter, Google Plus, Facebook, DrupalCon sessions, user group hand-outs, pinging people directly on IRC, whatever. We don't really have a nice central way of reaching all of the people we need to reach so you need to get a bit creative and employ lots of options. Even then, some people won't ever hear. :\

  Back when NA DrupalCons were in Feb/March and not in May, we would often hold a GSoC BoF session there to inform people about the project and meet & greet students, and then run around with a clipboard on the sprint day signing people up as mentors/collecting project ideas. This was really helpful. Not sure how to replicate that in a year like this one.

When/if you're chosen as a mentoring organization and students start applying (~April - May)

• "Getting Started" Documentation for new students: Let them know how to find their way in your community, where they should be asking questions, where they should be posting ideas, etc. Most of this can probably be culled from previous years, or there might even be a canonical place for it by now.
• Appoint "welcome wagon" folks to monitor IRC, the GSoC mailing lists, the GSoC group on g.d.o, etc. Maybe 5-10 people in various timezones that are warm, personable, and friendly, who can answer students' questions, get them feedback on their project ideas, help point them at projects that might be within their interest, etc. I think one year we had set "meet and greet" times we published where the students and mentors could hang out on IRC for awhile (nowadays that might be Google Hangouts). This helps us to get a feel for the students, and the students to get a feel for us.
• Canvas for reviewers on students' ideas: We instituted a policy a few years back (which I hope still exists) that students should talk about their ideas publicly on g.d.o and get community feedback on them. This both introduces them to the collaborative nature of open source (for some, it might be their first foray into am open source community) and ensures their projects have good benefit for / excitement within the community. (This is important, because there are a limited number of slots available, and you want to make them count.) "Sorry, this looks like an exact duplicate of Foo module" is fine, but nothing sends alarm bells more than posting project ideas that get crickets in return.
• Review and rank applications, assign mentors: Based on the project ideas / applications that come in, pull some folks from your mentor pool you established in February and have them assist in ranking and reviewing the applications, and call "dibs" on projects. There are always going to be a couple of "HELL YES"es (projects from super keen students that are much-needed and have lots of excitement around them) and "HELL NO"s (obvious copy/paste applications, one-liners, etc.) and a whooooole lot in the middle. It's important that the middle stuff is considered and ranked appropriately, because at the end of the day, Google's going to give you N slots, so whatever your top N projects are, those are the people/projects that get funded.

  Here you want to engage students, ask more questions about their applications, challenge them a bit on their timelines/scopes if they're not aggressive enough/too aggressive, etc. A lot of times we make the mistake of picking applications because the projects sound awesome, but I'd love to see us picking applications more on the basis of who applies, and how passionate, collaborative, etc. they are. I think at one point we might've introduced something like an "application bonus" for applicants who upload a patch or something in advance of their application. Basically, we should get a feel for how they're going to function in our community before we give them a slot, because they're going to take away a slot from someone else.

  In the past, we tried to do something like a 33/33/33 split of existing, rockstar contributors (as a way to say "thank you"), totally brand-new people to Drupal who seem very keen (to bring in new, eager blood), and folks with existing Drupal experience who seem solid. We also tried to aim for some amount of geographical / gender diversity in that mix, too (not as "quotas" really, but more as a "tiebreaker" type of situation). Not sure if we still do that.

• A concerted communication machine to get the word out about all of the above. Ditto, everything above. :)

Once students are selected / slots are assigned (May - June)

• Make a big effing deal about these students! Make a front page post with their pictures on it, get the community really excited about their projects, try and find reviewers/testers for their code as it becomes more final, have the welcome wagon people doing their welcome wagon thing, etc. These students are a small handful of a small handful of people who get this opportunity. We should make them feel kick-ass to be part of our community!
• Provide a structured "on boarding" process for students to up to speed These days, I think that'd be pointing them at http://drupal.org/core-office-hours, which can help them learn Git, how the issue queue works, how patches work, etc. if they don't already know. But the org admins should give those folks leading office hours a heads-up first, and arrange for the GSoC mentors to provide extra hand-holding the day/days we know students will attend.

During GSoC (June - September)

• What students need to do: Code their brains out! :) But also, become immersed in our community; hang out on IRC, participate in issues and discussions,
• What mentors need to do: Mentors should be on the look-out for students who get caught up in "analysis paralysis" and fall off the grid for days or weeks at a time because they're too scared to ask for help (that was me in 2005 GSoC ;)) and also students who are off "moonlighting" and doing something else when they're supposed to be doing GSoC. A lot of mentors take more of a "hands-off" approach and wait for students to come to them, and that doesn't really work in my experience. They should be pro-active set up regular times to meet with their students and review their code, answer any questions, see if the project's on track and if it needs to be re-scoped, and encourage students to turn to the larger community for assistance where appropriate, directing them to the proper channels. (This doesn't mean micro-managing; this means listening to the student and giving advice. Y'know, mentoring.)
• What org admins need to do: Google (last I knew) has two reporting milestones: one at mid-project and one at end of project. Both trigger a payment of half the money to the student. Both all of the students and all of the mentors are expected to submit this report. The organization admin will need to hound mentors to make sure this happens, and also hound students and make sure they turn in their final code to Google. They will also need to intervene in any disputes that might arise between students and mentors (and they do happen, sometimes in an ugly way :\). They'll also be responsible for ultimately failing/passing the students (based on mentors' recommendations).
• Make a big effing deal about these students! Throughout GSoC make blog posts, videos, etc. going out about how awesome these projects are and how they're going to change our lives, and how kick-ass and smart these students are! Fly a couple of them to DrupalCon and put 'em in the limelight!

After GSoC

The Google Mentor Summit is a tremendously awesome event where luminaries from all sorts of major open source projects come together and have a "retrospective" of GSoC and what we can do better next year. There are lightning talks, break-out sessions, etc. We normally did a bit of a "lottery" thing to see who among the successful mentors would go, but these people (I think there are only 2 per year) are once again the "public face" of the Drupal community in this space, so it's important to pick people who can put our best foot forward. The Org admins choose who goes.

Wow, I had no idea you could write that much!

Neither did I! :D

Anyway, so in summary…

• We need org admins to oversee the process and keep things moving.
• We need beaucoup mentors to help students during their projects.
• We need beaucoup community members to submit and review project ideas.
• We need tons of communications help.
• Aaaand we need most of these pretty steadily from about February to October.

That is not on topic nor is it relevant. This is a forward looking topic. Believe me, there's nothing we can learn from our rejection this year.