Summer of Code Mentor Checklist for FreeBSD Mentors

This page collects ideas and suggestions for FreeBSD developers mentoring student projects during Summer of Code 2012. Any questions can be discussed on the soc-mentors@ mailing list or brought to the attention of soc-admins@.

Contents

Summer of Code Mentor Checklist for FreeBSD Mentors
Frequently Asked Questions
1. Do I have to use Perforce/Subversion? Can my student work in another SCM?
Other Links
1. Mentoring Guidelines / Advice for FreeBSD Mentors

Ideas/Planning Phase, Before Student Applications Accepted

In 2012, student applications started being accepted in April. A few things need to be under way before then.

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.

Student Proposal Period, Before Student Applications Due

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.

Community Bonding Period, Before the Summer (April 24--May 21)

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

Which version control system the student would like to use. We are able to offer accounts with either the SummerOfCodeSubversion repository, or the SummerOfCodePerforce repository.
When are you available? Vacations (both mentor's and student's), class schedules, and other factors should be well-understood before the beginning of coding. Keep in mind that the GSoC schedule is designed around US class schedules, which generally end in mid-May. You may need to find ways to adjust if your student is on a different class schedule.
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.
Does the student need to do any preparatory work before start-of-coding? It's a good idea to make sure your student is at least comfortable building and upgrading FreeBSD from source. If your student needs to be working with -CURRENT (most do), you should make that clear and help them get started working in that environment. Otherwise, students are likely to spend the first weeks of the summer dealing with routine issues like learning the difference between "make kernel" and "make buildkernel" and learning to read UPDATING.

First Half of the Summer, Before the Mid-term Evaluations

In 2012, coding officially begins May 21, with mid-term evaluations beginning in early July. Generally, this is a ramp-up period where students gain familiarity with their specific project and make their first concrete progress.

Review before or after commit? Some mentors have had good results using an explicit review cycle (student sends patch, mentor approves, student commits) for the first week or so. Regardless, you should watch your student's commits carefully and give them feedback on their progress.
It is mandatory that students have committed some code prior to the mid-term. Please be clear with your student about this.
Mid-term evaluations should be based on what the student has actually accomplished. In particular, if a student disappears or makes no demonstrable progress, they should be failed.
The mid-term is also a good point to renegotiate the project scope and milestones.

Second Half of the Summer, After the Mid-term Evaluations

In 2012, coding completes in late August. After the mid-terms, your student should have clear goals and be able to make steady progress.

Final evaluations can only be based on what the student has accomplished during the GSoC coding period.
If your student has not made any progress during the second half, we will likely have to fail them. Talk to the FreeBSD GSoC administrators if you have any questions.

After the summer

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.
Follow up and encourage your student to keep working on FreeBSD after the summer.
If they did well, consider nominating them for a commit bit.

Frequently Asked Questions

Do I have to use Perforce/Subversion? Can my student work in another SCM?

For administrative reasons we'd like to keep the number of revision control systems to a minimum. Starting in 2011, we are providing either Subversion or Perforce as options, and the student is free to choose whichever they prefer. For projectsworking against the src repository, these options are almost certainly the best as the full FreeBSD src tree is available for easy copying and merging.

For userland or ports projects, there is more flexibility. Please talk with soc-admins if necessary.