Doing better on Google Summer of Code 2014

skyredwang's picture

Google Summer of Code is a program that offers student developers stipends to write code for various open source projects. Google works with a several open source, free software and technology-related groups to identify and fund several projects over a three month-period. Historically, the program has brought together more than 6,000 students with over 300 open source projects, producing millions of lines of code. The program, which kicked off in 2005, is now in its eighth year, following on from a very successful 2006, 2007, 2008, 2009, 2010, 2011, and 2012.

---- https://code.google.com/p/google-summer-of-code/

At Drupal community, we had been successfully participating in GSoC since the first year, 2005 (http://drupal.org/google-summer-of-code). However, our community was NOT accepted as an organization for the year of 2013.

Let's discuss what went wrong and what we can do better.

Comments

This year is my last year as

Jerenus's picture

This year is my last year as a student in the community. I will graduate this summer, and I am very frustrated to lose this chance.

人人为我, 我为人人。

Very sorry to hear that. :(

webchick's picture

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

Dwindling interest -- my fault too

chx's picture

I can only talk of last year because this year I was not an org admin. The idea list was horribly short last year. I should've perhaps pressed for more. I should've stepped down the moment when we only got 13 slots. That was already a failure. Then I didn't hold the reins tighter and didn't demand weekly updates. I have more excuses but they don't matter now.

Long story short, whoever will run GSoC next year needs to be able to dedicate a huge amount of time and effort and drum up a lot of strong support early in the process.

I don't want to say that this

slashrsm's picture

I don't want to say that this is completely correlated, but this year's Code-IN may have been a smoke that indicated a bigger fire.

http://janezurevc.name/google-code-drupal

Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name

I think you are partly right.

fuzzy76's picture

I think you are partly right. Drupal is getting more and more "enterprise" both in size, requirements and learning curve. This is good for the larger sites, but it means less grassroot support. This means that 13 year olds won't learn it, which means Code-IN is not for us. And it probably gives some signals to GSOC as well.

You couldn't be more wrong

chx's picture

Code-In is absolutely for us. If we have the crew to support it because it's a lot, lot of work we can get fabulous results.

We need a new approach

highermath's picture

Instead of saddling one person to run these programs until they burn out, we should create a position, likely on the Drupal Association Advisory Board, that is charged with recruiting folks to oversee these programs each year.

We should use this as an opportunity to identify and promote more leaders within our community, not just burn out the ones we know.

What does this role take?

holly.ross.drupal's picture

First - huge thanks to chx, slashvsm and sumitk for working on this. I know we didn't get the results we were looking for, but I appreciate all the effort. It's pretty amazing all that you folks give for the community and the Project.

I would love to better understand what needs to happen to make a successful run at this and figure out if it's something we can support at the DA in a more formal way. Perhaps we could meet up at DrupalCon (BoF? Would there be enough interest?) or just grab a beer/coffee/appropriate beverage.

It takes a person in a role

highermath's picture

It takes a person in a role that is charged with making sure the community is aware of the importance of the project, what is needed and the deadlines involved.

I think that there are plenty of folks in the community who could and would do this. We just need to ask. I suggest that this be an Advisory Board role of some sort.

Here's a run-down of what's entailed...

webchick's picture

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

Well then!

holly.ross.drupal's picture

I guess that sums THAT up Angie! Thanks so much for all the detail there. Now... all we have to do is do ti, right? Are there like 20 lines of code that can make this all happen? :)

Ha! :D

webchick's picture

Unfortunately, not really. It's actually an incredibly people-powered process, and it can be extremely difficult to drum up momentum necessary to make it successful.

I'm eternally grateful to sumitk, slashrm, and chx for keeping the flame alive all these years. Let's find out more specific reasons why we weren't selected next week, and become the "comeback kids" next year!

During GSoC (June - September)

chx's picture

What students also need to do: write weekly, public updates. If they don't, it's automatic fail. Obviously, missing one or two because of an off-grid vacation (which the mentor knows about), hospital stays is fine (poor student, spending the summer in a hospital, it happens alas). As usual, use common sense.

Erm, no. ;)

webchick's picture

Micro-managing students is not fostering their growth and learning. I get the desire to not have students fall off the grid, but that's what engaged mentors are for. If anything, get the mentors to report weekly/bi-weekly on what's happening.

Obviously though, students should be encouraged to blog about their stuff, and promoting it in a really prominent way when they do is a great way to get the visibility/transparency you want without making it feel like an overbearing chore.

I agree with chx. While you

slashrsm's picture

I agree with chx. While you do not want to completely occupy student with bureaucracy I believe it is crucial to see regular reports and regular progress on the project. Any failure to do should immediately turn on a big red light.

I am speaking this based on my mentoring experience. It is sometimes very hard to regularly follow student's progress and this can lead in a failed or at least poorly completed project. Specially if you have a lot of other things to care about (who doesn't, right).

Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name

You can count me in.

slashrsm's picture

You can count me in.

Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name

Did GSoC say why the Drupal

Dustin@PI's picture

Did GSoC say why the Drupal Communitty ws anot accepted for this year?

Off topic

chx's picture

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.

Google also paid to bring

kreynen's picture

Google also paid to bring mentors from participating organizations together. Who went to that event? Are there any differences between Drupal's approach to GSoC and the organizations who were approved again this year?

Attending the GSoC meeting now...

webchick's picture

Pretty close to 100% of the feedback towards other orgs is around the ideas list.

What they want to see:
- An ideas list generated in advance of the application.
- Each idea should include:
- A well-fleshed out idea.
- Suggested mentor(s)
- Programming language(s) required
- Approximate difficulty level

Looks like we did that in 2012: http://groups.drupal.org/google-summer-code-2012/community, but not for this year (there are only about 4 ideas in this group :\ )

I think one immediate process change we can make is stop making a different group for this every year. It requires us to re-build momentum from scratch every year. We should just make a single "Google Summer of Code" group and use dates on the posts to determine what year it was for.

Then we could keep a "running" ideas list in a more permanent location that we could also use for things other than GSoC.

Preparing GSoC 2014

skyredwang's picture

Google has announced GSoC 2014 http://google-opensource.blogspot.com/2013/10/google-code-in-2013-and-go...

let's please get started with:

  1. create a new group "Google Summer of Code"

  2. create a wiki page preparing the organization proposal to Google, answering questions listed under "What should a mentoring organization proposal look like?" http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gso...

  3. create an idea template, so people can start submitting their ideas.

  4. create the Group Panel to feature GSoC 2014 program timeline and idea list (a Wiki or Views)

Google Summer of Code 2013

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: