Summer of Code Mentor Checklist for FreeBSD Mentors

This page collects ideas and suggestions for FreeBSD developers mentoring student projects during Summer of Code. 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
Other Links
1. Mentoring Guidelines / Advice for FreeBSD Mentors

Ideas/Planning Phase, Before Student Applications Accepted

A few things need to be under way before the application period opens.

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.

Scoring proposals

Although Melange provides built-in functionality for scoring proposals, it doesn't allow us enough flexibility to really assess proposals and identify weaknesses or causes for concern in each. Instead we use a Google Docs spreadsheet, which enables us to score in multiple dimensions, and see each others scoring. See Summer of Code Scoring for more details.

Community Bonding Period, Before the Summer

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. More information is available at Summer of Code VCS.
When are you available? Vacations (both mentors and students), 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

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

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