Drupal's approach to Summer of Code 2008

In case word hasn't reached you yet for some reason, Summer of Code 2008 is a go, and this is the week for college/university students to submit applications to work on projects for their mentoring organization of choice over the summer. Our hope is of course that a whole bunch will choose Drupal, which is an awesome, knowledgeable, and fun community to be a part of, and very supportive of SoC students (I know, because I was one myself back in 2005! :D).

As part of my duties for the Drupal Association, I help to administer initiatives that help bring in new contributors, like Drupal's involvement in Google Summer of Code. A huge thanks to the admin team -- chx, cwgordon7, and dmitrig01 -- for their tremendous efforts in getting the program kick-started!

We're trying something new this year that we haven't done in years past: public community review of student ideas and proposals, prior to their submission as formal applications for Summer of Code. There are multiple reasons why we chose to "beta test" this approach, which I will detail after the break.

However, for those who want to help bring new contributors to the Drupal project, and have a hand in deciding what new awesome projects get funded over the summer with Google's multi-thousand dollar investment, please jump in and help review some student proposals! The absolute deadline for student applications is Monday, March 31, 2008 at 17:00 PDT, so it's imperative that students get their questions answered and their proposals reviewed and refined as soon as possible so they have ample time to get their applications in.

Wait, what?

I hear you saying, "What? You're making these students who are brand new to Drupal to post their SoC project ideas to be publicly scrutinized by the entire community?! But they might get criticism about their ideas! They might be shy and not want to do that, and we'll drive them away! Are you completely NUTS?!"

It does sound scary, right? Well, there were a few reasons we chose to try this way out this year...

We want to provide students with a more realistic open source experience.

In the "real world," you don't come up with a proposal for a project, submit it off, have someone from a small group of people "grace" your idea, and then get paid to work on it. There's more elbow grease involved. You need to articulate your ideas so that people can understand them. You need to defend your ideas when they're challenged. You need to look into existing solutions and identify ways that what you're proposing won't overlap, and will in fact enhance what's already there. Students who vet their ideas in front of the community are getting this kind of experience, and are dealing with it smashingly.

We want to get students involved in the community early.

Posting ideas to working groups on groups.drupal.org and working with others to further refine them is exactly the way the Drupal community gets its own "big projects" off the ground. We're guaranteed that students will have a Drupal.org account when they apply, and will have a good sense of how the community gets stuff done. Students also get the chance to sort of "try out" our community to see if it's a good fit for them, and we also get to observe how students are likely to interact with their peers throughout the course of SoC. In the end, I'm hopeful that this will lead to more productive student/community relationships, and more "sticky" students who stay around after SoC.

We want to raise the quality of applications.

Students will know about criticism to their ideas ahead of time, so that they can work with the community to further refine them. Once an proposal has passed community review, it means that the student is treading new ground on something that's important to the community, their work is not overlapping existing modules, and the project they've chosen is neither far too vast nor too small in scope. This eliminates about 90% of the reasons we've had to reject SoC applications in the past.

We want the larger Drupal community to have a say in how Google's money is allocated

In the past, Drupal's group of SoC mentors have been the ones to pretty much solely figure out which projects and students are accepted, and thus dictate how multiple thousands of dollars are invested in the Drupal community. As such, this process is a harrowing, nerve-wracking experience, knowing that each slot that we fill with one awesome project and student means another student *won't* be participating in Summer of Code. :( By opening up reviews of students' ideas to the entire Drupal community, we can have much more confidence that when we vote to allow a student/project to fill a slot, it's for something that the community sees as a large need.

We want to amass a group of testers for each project.

If an individual takes the time to comment on a proposal idea, chances are they have a vested interest in seeing the project through to success. We can then call on these individuals later to lend help testing and providing feedback on the students' work as their projects progress.

We want to attract and entice new mentors who didn't think they had it in them to mentor. :)

The prospect of mentoring a student sounds really scary, but merely offering feedback on ideas does not. And over the past week, we've seen numerous contributors who didn't think they were worthy of nominating themselves for mentorship end up doing everything that good mentors do: providing feedback, encouragement, resources, etc. to students and passing on nuggets of knowledge they've managed to glean from working with Drupal and in the Drupal community. As a result, we have managed to grow our mentoring team even further with additional active, engaged members.

As a side-benefit, this process also allows us to see who from the existing mentor pool is actively engaged, and observe how they interact with students, which will help us in making intelligent decisions when it comes time to assign mentors to projects.

The Downsides...

As with any new idea, there are a few bugs...

• Keeping on top of responding to student proposals is a lot of work to manage, and it's all crammed into this one week. But the good news is that this work is spread out over many more people than ever before, which is leading to more thorough and thoughtful reviews.
• Students don't yet know of "who's who" in the Drupal community, so there can be confusion when two people are presenting competing view points as to which one's knowledge is more authoritative on a given subject. More people watching for this sort of thing and responding with, "Well, developer Foo wrote the Blargenhargen module, so if he says that this needs further refining, you should listen to him." will help with this point.
• Some of the proposals have gotten a little "bikesheddy" and going off on a tangent about something vaguely related, rather than focusing on the main goal which is to help a student refine their idea into an application. More people watching for this sort of thing and responding with "Ok, well I think if you address point A and B in your application, you'll be good!" will help this one.
• We will probably end up with fewer applications this year due to this new requirement. Well. This could actually be considered a positive, if you're a student who's applying to work with Drupal. ;)

Thoughts?

I'm very curious to hear thoughts from community members, mentors, and students about this new approach, and whether or not we should repeat it for next year. It might be a little early to say, but your initial impressions would be great, after you've reviewed a few proposals, of course. ;)