On Wed, Feb 11, 2009 at 12:27 PM, Don Stewart
gwern0:
(The following is a quasi essay/list of past Summer of Code projects; my hope is to guide thinking about what Summer of Code projects would be good to pick, and more specifically what should be avoided. If you're in a hurry, my conclusions are at the bottom. The whole thing is written in Markdown; for best results pass it through Pandoc or view it via your friendly local Gitit wiki.)
Thanks for the write up!
We explicitly pushed harder in 2008 to clarify and simplify the goals of the projects, ensure adequate *prior Haskell experience* and to focus on libraries and tools that directly benefit the communtity.
Oh, I didn't know that about prior experience. (I was tired enough when I finished it that I decided to not look at the students involved - how much prior experience they had, and how involved they were in the Haskell community afterwards.)
And our success rate was much higher.
That certainly does seem to be true. Looking over the 2008 projects, I see 0 outright failures (compared to 2 in 2006), and only 1 or 2 which might turn out to be unsuccessful (the physics engine, and perhaps GMap or the GHC API improvements).
So: look for things that benefit the largest number of Haskell developers and users, and from students with proven Haskell development experience. You can't learn Haskell from zero on the job, during SoC.
-- Don
Inexperience is a good criterion to add to the 3 I had in my conclusion, certainly. -- gwern