In 2008, student applications started being accepted in April.

• Review the ideas list and add submissions. More than half of our student applications use ideas taken from the FreeBSD ideas list. Our students have a wide variety of backgrounds, so we can use ideas for all experience levels.

• Help identify other potential mentors. Every year, we have to reject a few worthwhile submissions because we can't find suitable mentors. While experience in other mentoring situations is helpful, all that's really needed is patience and interest in helping someone improve.

• Help mail students and communicate. In particular, we encourage students to propose their ideas on current@ and other public forums. Few things are more discouraging than getting no response at all. We also encourage students to try to locate FreeBSD developers to act as potential mentors; if you get an inquiry that you can't help with, forward the request to someone who can.

Before coding officially begins is a good time to discuss the project with your student and work out how you'll work together.

• When are you available? Vacations (yours and the students), class schedules, and other factors should be well-understood before the beginning of coding.

• How will you communicate? Email, IRC, in-person meetings (if you happen to be in the same geographic area) are all reasonable. You should work out something that works well for you and your student and figure out a suitable schedule. For most students, you should plan to communicate every day or two. Negotiate this explicitly with your student and plan to hold them to what you negotiate. Encourage them to pick a public forum such as mailing lists for most communications.

In 2008, coding officially began in mid-June, with mid-term evaluations in early July.

• Update the ideas list. If your student successfully completed a project listed there, remove it, or add a link to the work that was already done.

For administrative reasons we'd like to keep the number of revision control systems to a minimum. For kernel projects it almost certainly makes sense to use Perforce because of the ease of branching and tracking changes in -CURRENT.

For userland or ports projects however, there is more flexibility. Please talk with soc-admins, but it should be fine to use the hosted Subversion repository as part of Google Code, code.google.com, for example.

See SummerOfCodeMentoring for some guidelines posted by Robert Watson, Murray Stokely, and others.