Hi All, Google Summer of Code is back! It has been publicly announced<http://google-opensource.blogspot.com/2011/01/google-summer-of-code-announced-at-lca.html>, 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!). No organization admin has been chosen yet. 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. Know everything already? Don’t wanna read more! Want to help? Sign yourself up <http://groups.drupal.org/node/121634>! What happens during SoC? SoC is roughly broken up into 6 phases: 1. 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. 2. 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 <http://groups.drupal.org/node/9487>, for reference. 3. 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. 4. "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. 5. 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. 6. 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 on http://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.Okay, so how are we going to do this? Want to help? Sign yourself up<http://groups.drupal.org/node/121634> ! *Sumit Kataria* (415) 830-6313 | Skype: sumit.kataria1 Google Voice: (510) 394-4339 <https://www.google.com/voice/#phones> LinkedIn <http://www.linkedin.com/in/sumitkataria> MyBlog<http://www.sumitk.net>