... where "our" means The Perl Foundation organization's, but the subject got too long. Also, keep in mind that this is a very subjective piece of text.
Initially, I was made aware of that there's a Google Summer of Code going on this year again and that there could/should be a Perl-specific organization in it by Eric Wilhelm's short reminder mail to the perl5-porters list. Without re-reading the ensuing thread, I seem to remember that the discussion that started from there was semi-productive and nobody really volunteered. But I guess that's kind of the norm in public discussions.
So Eric just went ahead and pulled it off regardless. He collected proposals, wrote Wiki pages, and announced to other lists. It turned out that collecting proposals was relatively easy. Once he got the word out, the proposals wiki page filled up quite quickly. He went on to talk to the TPF people and the previous GSOC administrators for the TPF. With their help, he tried to pin down what went well and not so well in the past years and devised a scheme which would deal more gracefully with failures similar to those that happened in the past.
As far as I can tell, many problems in the past arose from the fact that central figures either underestimated the huge heap of work involved in managing the GSOC administration or were taken aback by other, non-voluntary obligations.
Essentially, I think, the three most important pieces to that plan for 2008 were
What Eric did to reduce the insane work load on the central figure was to add an extra layer of people between the mentors and the admin. He split the organization's involvement in different departments and appointed pilots and backup pilots (see point 1) for each of them. For example, for the Perl 6 branch, Jerry Gay and Will Coleda shared the responsibility. This extra layer of people not only reduced the burden on the admin, they were also chosen to be more experienced with their departments than the admin ever could be. Similarly a backup was sought for each mentor.
Eric et al went on to write the organization's proposal for getting into the program at all. Needless to say, we were accepted, or I wouldn't be writing this. Furthermore, a template for the student applications was prepared. Having this template turned out to be crucial to weed out bad applicants: If they weren't able to read, understand, and answer the questions posed, they likely wouldn't be able to do a GSOC project either. If anything, then because communication is a key ingredient to the success.
Still, guiding the would-be applicants took a lot of effort. This probably was the largest piece of work Eric off-loaded to the departmental pilots as they were listed as the contact persons for applicants.
Next up was finding the right mentors. Here, the Perl6 people really showed their commitment. Finding mentors for the Perl6 and Parrot related projects virtually seemed to take no effort at all.
Generally, there were more than enough mentors available, but getting the names nailed down for some of the propsals took some time.
Once the applications were in shape and ready to be ordered by preference, since we couldn't expect to get them all funded, the most disputatious part of the process started:
Who gets to choose which projects get funding?
Just dwell on that for a bit. It's easy to find good criteria: Probability of success, usefulness to the greatest number of people, probability that the student will stick around after the summer, etc.
But those don't really help much. Depending on who you ask, all three of those criteria could be interpreted in favour or against almost every single application. Needless to say, every
mentor liked his student's application best!
Ideas for a mode of selecting the best applications were batted around IRC for a while and in the end, a somewhat semi-democratic process was chosen.
All mentors got a fixed number of votes they had to spread among the proposals. Given the outcome of that, Eric reserved the right to veto an application
or to move one up/down a bit.
While that may sound arbitrary, it really wasn't. There wasn't a good prediction of the outcome. When every voter has a personal agenda, the democratic process doesn't necessarily produce the
best ranking. However, it was clear that some applications were very good and needed to be included. Having Eric as a fallback fix for this seemed the least problematic solution.
I think this whole selection process was the most fragile step of all, because it had the potential to alienate some of those involved. I guess everybody reading this has an idea of what
confusion, disappointment, and anger do to a volunteer!
We got funding for five projects out of fourteen which (if you ask me) should have been funded. Why not more? Because Google can't fund everything and the core of their algorithm is to spread
the slots according to the number of student applications. Through some extra-haggling, we got a special sixth slot for the Bricolage project.
After the announcement of the accepted projects, a so-called community-bonding period started. During that time, the students were asked to get familiar with
the tools, get to know the people involved, and, if at all possible, make themselves visible in the community.
When the coding period started, things seemed to go reasonably smoothly. Getting reports from the students and mentors was more work that it should have been and Eric, again, had to do a lot of that.
Some students (and mentors) were good at communicating their progress, some weren't. Maybe we should have found a way to make the student's work more visible. What was your impression, dear reader, did you
In the end, five out of six projects have been successful. I think that is an extra-ordinarily good result.
Looking towards next year, what needs to be improved over this summer?
Maybe you caught the problem with the master plan I outlined with three bullet points above. Points 1) and 3) contradict each other.
If Eric had disappeared, say, in the student selection process, our involvement in the SOC might have fallen flat on its face. I was told that something
like that had happened before. To my information, Eric put in more than a whole month of full-time work. We can't rely on anybody doing that next year.
So we need to find a way to share more of the burden among more people and make every single person involved non-crucial if at all possible.
Furthermore, I think, we need to increase the size of our student pool. We had many more mentors and projects than applications. We have to find a better way to reach out.
Ideally to universities. This is a bigger problem than just the TPF GSOC involvement, however.
As a minor nit, maybe the project proposals should have been a little more elaborate and glossy. Who wants to rewrite Module::ScanDeps because it's horrid? (That was my proposal, so I can trash-talk it at leasure.) I should have mentioned the shiny glitz of working with the best Perl introspection tool in existence (PPI) or something along those lines. Everybody knows dependency scanning is fun!
Finally, maybe we can find a more efficient application selection scheme. Maybe we can make it so that it isn't necessary than a single person needs to make the final decision.
It's not a fun thing to do.
I doubt many readers are left at this point. Regardless, I'd like to extend my thanks not only to Eric, whose work I have praised enough in the above text,
but also to the mentors for dedicating their spare time and Google for funding the whole program. Most of all, however, I want to congratulate the successful students for
having the stamina to stem their projects. You've done great work and I really hope you'll stay involved.
Thanks for reading.