At the start of the session, Sigurd Magnusson from SilverStripe? talked about their project's SoC? methodology. A number of useful tips were discussed, including:

* Appoint a single "gatekeeper" for SoC? (SilverStripe? had 10 slots, and around 40 applications, so larger projects probably need more gatekeepers.)
* Create an "entry exam" -- a relatively simple coding task that all applicants complete, in order to gauge their approximate skill level and areas of interest (and also to tell whether or not they can complete a task ;)). See for example http://www.silverstripe.com/php-coding-test
* Talk with each student over Skype first, to help gauge their communication skills.
* When choosing the students, not only pick the best, but also help tailor their project to their interests/skill level, based on entry exam. Assign mentors late, so that the right people are assigned to the right projects.
* Motivated students by promising exposure, then publicly congratulating work widely, through the use of screencasts, and adding them to Ohloh
    * http://www.silverstripe.com/google-summer-of-code-update-image-editing-glory/
    * http://www.ohloh.net/projects/8866/analyses/latest/contributors?page=1
* Keep assigning trac tickets to encourage participation

Community participation

* Get them involved in choices
* Frequent public communication
* Introduce students early on to the community
* Get them on the community resources (IRC, mailing lists...)

Tools

* Give them a blog on the project blog.
* Add public wiki repository
* Common mailing list
* Regular reports through IRC, etc.
* Treat them like any other developer
* Public discussions
* Have well-defined review process.
* Give them rights equal to others on the project.
* Mentoring program

Committing code

* Have experimental branch
* Have students participate in communication process
* Have other members do bug reports, etc.
* Track contributions
* Reward their contributions early; commit early, commit often.
* Have well-defined policy on how to commit code.

How to balance high bar of code quality in projects with requirement for students to feel involved?
* Create "experimental" branch
* Make them committers on their own stuff.
* Use alternative source repository (SourceForge?, etc.) for licensing problems.
* For situations where students have to submit patches, make sure someone is fast about reviewing it.

Encouragement

* Track and promote statistics
* It's all about "Fame" -- congratulate them for every success.
* Give them public kudos, make them feel proud.
* Find way to show students that their projects are used
* Offer prize to "best" project.

After

* Give them more things to work on after (interesting stuff, not just maintenance work).

How to handle students that are as keen about SoC? as they are about school, and so drop off the radar
* Make contribution a habit.. doesn't have to be code... could be documentation, etc.
* Keep them feeling involved.

Rewards

* Hire students
* Provide additional incentives.

Misc

How to deal with crazy ideas that are really cool, but would never make their way into trunk?

* Direct them to "umbrella" org that can take on things.

Mixed feelings about projects that are continuation of PhD? work, etc. ex. how do you determine what is pre-existing work?
* Need to define project really well at beginning.
* Can be very beneficial, as there's a good chance that student will complete project since they have a vested interest. ;)

For students who have grown into mentors, what things did and didn't work well?
* Easier set of requirements/process to get involved.
* More interaction/encouragement.
* Make it fun. :)
* Make friends. :)
* Use same tools as everyone else.
* Entrust them with responsibilities/give them ownership over things.
* Encourage any kind of participation not just code.
* Felt there was interest in the stuff they did.
* Feedback on whether or not stuff is used.
* Twam of "testers" that aren't mentors?