While Google hasn't officially announced anything to my knowledge, word on the street is that the Summer of Code program will be running again in 2009. If it runs as it did in 2008, then it would be publicly announced next month, and applications from mentoring organizations (that's us - Drupal) to participate will be due the first week of March (just in time for everyone to be distracted by Drupalcon! ;)).
Traditionally, I've sort of headed up the administrative, getting-the-ball-rolling process at the beginning of SoC, and making-sure-things-are-chugging-along during the middle, with the help of Drupal's tremendous mentoring team. There is one BIG snag this year though -- last fall I got named Drupal 7 core maintainer, and have had to cut all other "extra-curricular" duties, and that includes SoC. :\ We therefore urgently need to look at a sustainable way to spread this responsibility across the mentoring team so it doesn't create a "single point of failure" in our organization.
So let's pre-preemptively start talking strategy about how to tackle managing SoC moving forward. Here's a brain-dump of everything related to managing SoC that will need to be looked after, 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. Beyond that, we didn't structure this last year (for example, write 3 core patches) and I think we should seriously think about doing something this year.
- 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).
Last year, we handled this by asking community members (and students!) to propose their projects on http://groups.drupal.org/soc-2008. 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.
Once a proposal is vetted (and if it did NOT come from a student), we added them to a "official" ideas list at http://drupal.org/google-summer-of-code/2008/ideas-list. I think this might've been confusing for people, but I couldn't really think of a better way to balance the community vetting process and an official reference we can point to in our application.
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.
It's possible that the two of these might help our student/mentor AWOL rate. I'm not sure.
About Planet SoC
http://planet-soc.com/ is a site that the Drupal community has traditionally provided each year to aggregate student/mentor blogs. As you can see, it's become horribly neglected. :P But during SoC, students really seem to like this.
Robert Douglass has the domain and the current server it's hosted on, and I know that he would like to have it moved off his machines. If someone wants to keep up the tradition this year, that would be awesome.
Hm. I think that's everything I know about SoC in one big brain-dump. :P Feel free to ask any other questions.
Okay, so how are we going to do this?