Having had the opportunity to be part of The Fedora Project's involvement in the last 4 GSoC and, reading about how other FOSS projects handle their involvement, I thought I'd note down few of the thoughts that I've had. In no particular order, here they are:
- identify projects and, prospects well *before* GSoC. As opposed to having the idea on a wiki somewhere and hoping that we have a good proposal. Most of the successes Fedora has had via GSoC have been as a result of initial, prolonged and continuous discussion
Traditionally, our project ideas for GSoC have always been drawn up in a rush. The result of this is, more often than not, a somewhat tenuous proposal that does not provide enough indications to prospective candidates about the ways to a solution
- have a set of qualifier tests for prospects. A number of FOSS project use this technique effectively and, the suddenly appearing talent are enthusiastic about proving their mettle and getting selected
We could begin this by providing more love to easyfix.fedoraproject.org and, gauging the great easyfixers :) However, we should take care of not giving out the impression that more fixes equates to improving chances of getting a GSoC seat.
- make blogging mandatory. Fedora folks get a planet.fedoraproject.org/gsoc and, that's all there is. Weekly blogs from all the candidates should be tied into the appraisals
Blogs, thanks to feed readers and planets, are the cheapest and low-shelf way to PR that a project can have. With the Planet infrastructure making it simple enough to have a /gsoc, we should actively encourage and, mandate blogging going to the extent of tying it to the mid-term reviews
- GSoC candidates should present/talk about their work at local events - does the job of showing off new talent and, providing role model for potential contributors
Having a role model or, icon to chat with or, look up to is always a good feeling. Encouraging and coaching GSoC candidates to talk about their work and, their experience at local events does a whole lot of things from getting new friends, to talking about features and, not to mention providing presentation experience to the GSoC candidates. The local teams are able to get new speakers as well.
- make a round-up mandatory. Debian does a reasonably good job of doing the following:
o annual round-up with emphasis about how the GSoC project was relevant in mainstream/upstream o annual round-up along lines of "one year later" thus checking health status of the GSoC projects
- ensure sustained ownership of GSoC contributions. No seagull participation of - code during GSoC and, vanish thereafter