Hi All,
Google Summer of Code is back! It has been publicly announced, and applications from mentoring organizations (that's us - Drupal) to participate will be due the last week of Feb (just in time for everyone to be distracted by Drupalcon! … hmm.... ).
No organization admin has been chosen yet (aah time to get webchick in picture). That will be decided in coming weeks.
So let's start talking strategy about how to tackle managing SoC moving forward. We need people to help, preferably by a team of former mentors, students, and ardent summer of code fans.
Want to help? Sign yourself up!
What happens during SoC?
SoC is roughly broken up into 6 phases:
- Pre-applications: There is a bunch of up-front work that needs to be done in order to submit an application to be a mentor organization in SoC. Among the tasks here include recruiting mentors, coming up with potential SoC projects for students to work on, and working out logistics about how the later steps are going to happen. Work should ideally start on this now, or very soon.
- Submitting mentor application: Each organization that takes part (Eclipse, Drupal, Apache, etc.) needs to submit an application in order to be accepted into Summer of Code. There are a variety of questions, about motivation, about plans of attack for various problems that come up, etc. Here is our application from 2008, for reference.
- Reviewing student applications: If we're accepted as a mentoring organization, about a week later applications will start coming in from students. These need to be reviewed and voted on by the mentoring team. Voting ranks the applications, and the number of slots we get from Google will give us the top N applicants.
- "Community bonding" time: There is a 2-month period before Summer of Code officially starts that's intended to be a bit of 'dipping baby toes' into the water of a community. Things like getting a CVS account, setting up a wiki page / drupal.org project.
- Summer of Code: Here's where the actual coding and mentoring happens, over the summer. The biggest thing to do here is to make sure students (and mentors!) are keeping on track and not falling off the face of the earth. Constant communication is key. Be aware that Google will require a mid-term and final report from all mentors and students, and the mentors never follow through, so you will need to beat them.
- Post-Summer of Code: Here's an area where we've traditionally kind of failed miserably. Far too often, students get to the end of SoC and we never hear from them again. We should start envisioning ways we can entice students to stick around for the long-term.
About Mentor Recruiting
The more mentors we have in the more diverse areas, the more of a chance there is we can take more students. Mentors should be knowledgeable in their subject matter, kind and patient with new people, and available for at least 5-10 hours/week over the summer. You'll need gmail addresses from all of them, because they'll need to be added to the mentor panel on Google's side. If the timing works out, recruiting at Drupalcon would be ideal.
Traditionally, Drupal has had a system where each student is assigned two mentors, in case one is unavailable. I believe there's some contention around how well this works in practice, so we could talk about changing this if we want. The downside of the two-mentor rule is that if we end up with 20 slots again, that means you're essentially managing 60+ people and making sure no one's slipping through the cracks. This is really challenging, and is worth putting some thought into from the outset on how to deal with this.
Experience has shown that lots of people want to be mentors in theory, but can't actually hack it when the time comes (almost universally, due to unforseen unavailability). I recommend pairing a known experienced mentor with a new keen one. More often than not, the new keen one will be the superstar, but the old experienced one can lend guidance when required.
About Project Proposals
A good proposal is challenging. It needs to be specced out, but not too specced out. It needs to be do-able within a 2 month timeframe, bearing in mind that about half of these students are coming in with no Drupal experience. It needs to have community support. And, it needs a competent mentor (preferably more than one).
Each year, we handled this by asking community members (and students!) to propose their projects onhttp://groups.drupal.org/google-summer-code-2011 This allowed them to be vetted, which was actually kind of nice because it weeded out a few that were never going to be accepted. It also helps when ranking the applications if something has a lot of people excited about it.
About Application Ranking
This process has traditionally always been messy... you'll end up with 10 or 15 applications with +10 votes, 10 or 15 at the bottom with -10 votes, and everything else (100+ applications) hovering around +2 to -2 until you start begging and pleading with people to rank the dang applications. Furthermore, experience has shown that applications only are in no way a bullet-proof way to judge a candidate. We've had to fail people from SoC for going completely AWOL or otherwise losing touch. This looks bad for us, and bad for the program. Furthermore, our SoC student retention rate after SoC is pretty so-so.. we either end up with complete rockstars or we never hear from them again.
Ideas on how to optimize this process to ensure we're getting quality students who are going to stick around are GREATLY appreciated. Other mentoring organizations have done things like requiring IRC interviews, quizzes, and "assignments" (code a simple module) prior to accepting students. This might be an avenue to explore.
About SoC itself
Students you have to worry about going AWOL but more than that you need to worry about mentors going AWOL (or at the very least not checking in with the normal announcement channels that point out when reports are due, etc.) I have yet to find a good solution to this problem. The only thing I can think of is requiring that all interaction be held publicly in the issue queues or g.d.o. No e-mail correspondence. If there's no posts to the queue in a day or two, slam an e-mail at the mentors and student and ask what's up.
What I did last year was make this horrendously awful table which was a complete PITA to update so I never ended up keeping up with it. But something like that is probably the only way you can keep everything straight, or at least it was for me.
We might also want to think about requiring daily commits (or at most twice-weekly). Another huge problem is students who are bright tend to be perfectionists and think that code needs to be perfect before they show anyone. Breaking them of that habit early (and often!) is important, not only for transparency and to make sure they're staying on track, but also to help them break out of the "school assignment" mentality and more into the "contributing to a living, breathing ecosystem" mentality.
One thing we tested this year was having each student use a wiki page to post status updates, etc. In retrospect, kind of think this was a mistake. We should probably just have them use their drupal.org project pages for current status, and use the SoC group for posting announcements, weekly status reports, etc.