Summer of Code Mentoring Guidance for The FreeBSD Project
This page is a collection of notes sent about mentoring students working on FreeBSD Projects for the Google Summer of Code.
Todo:
Develop student checklists.
Requirements for Mid-term evaluation success
- Code submitted to Subversion is a necessary but not sufficient condition for a passing evaluation at the mid-term period. All mentors should be keeping track of the repository to ensure there student has ironed out any access issues, and has submitted code well before the mid-term period.
Information on being a mentor
Robert Watson
As we have a large number of new mentors who haven't previously done the student mentoring thing, I thought I'd send out a few notes. If you've previosuly mentored new committers, that's not an unreasonable model to follow. Here are some points:
Primary mentor
Each student will have a primary (designated) mentor, who ultimately will be held responsible for mentoring of the student. Additional co-mentors are a good idea, since it can help spread the load, add expertise, etc, but the primary mentor is responsible for making sure the student receives mentorship.
Mentors should be in regular contact with their students, and budget time for that. Ideally, you speak with your student at least once a week by the medium of your choice. It would not be surprising to find that you were spending 4-8 hours a week per-student, and possibly more in some cases.
We encourage you to seek regular status reports from your students -- perhaps once a week by e-mail -- in order to keep track of their progress. Get these reports in writing so you have them later.
Mentor replacement
If, for some reason, you are suddenly unable to continue mentoring, it is very important that you contact soc-admins as soon as possible, and help to find a replacement mentor. This does happen, and we need to be prepared for the eventuality. Collecting weekly status from your student can help make this a lot easier to handle.
What might a mentor do?
Some students are self-directed and highly competent in the area they will work in. In these cases, your role will be primarily a social one: helping them get involved in the FreeBSD project, understand our standards, approaches, preferences, code style, quirks, etc.
Some students are less well-motivated or will require significant hand-holding to get up to speed with our technology and approaches. You may find yourself telling them how to build FreeBSD, how to hook into our make system, and teaching them a fair amount about C, threading, locking, kernels, standards, man pages, etc.
If you discover that mentoring is taking a lot more time than you expected, and/or you are having trouble keeping up, do ask for help. Other mentors may be able to help pick up some of the slack.
Revise the proposal and be flexible
Google has set aside a period of time for aclimation before the summer project begins. This is a good time to review the proposal with your student, and work with them to improve the schedule, plans, etc, as well as confirm they are really up to what they proposed. It is OK to modify their approach and goals as you go along. If there is a really serious change of direction (entirely new project), please contact soc-admins to discuss the situation.
Make sure you ask them about their level of effort and availability over the summer--in particular, if they have travel plans.
Subversion, e-mail, etc.
We will provide all students with FreeBSD.org e-mail aliases and subversion accounts with a soc20xx work area. We will also add them to the soc-students alias. We expect that all project work will be done in Subversion unless a prior arrangement is made with soc-admins. Google *requires* that work be done in an open source repository, and that the work be monitored, etc. By using Perforce, we ensure the work is open source, widely available, can be collaborated on, and provide a common commit mailing list for all student projects. There's some excellent new user documentation available on Perforce, but you will probably find your student requires quite a bit of support in the first few weeks as they get up-to-speed.
- Student community and IRC
You should encourage students to interact with each other as a community--they will often be running into the same problems, and are often willing to help each other. In the past we've run a #freebsd-soc IRC channel for our students, mentors, and general helpers out, to join and use. This can be especially helpful if there's a significant timezone lag between you and your student, as they can seek help from others in the community more frequently.
Do suggest to your student that they seek feedback on our mailing lists, and that they submit a quarterly status report so that their work is exposed to the community.
Student evaluations and payment
You will be required to evaluate your students performance at least twice over the course of the summer. It is *very important* that this be done properly, and in a timely fashion on the schedule set by Google. Our continued participation in the program, not to mention student payments, depend on doing this right. Do *not* submit reports late. If you will be away, you can always provide the reports to soc-admins early and we can submit them for you.
Remember that the proposal is not a statement of work--evaluate them based on their willingness to get their hands dirty, finding interesting approaches to solutions, and their level of effort. If they fail to deliver the specific bullet points on their proposal but still do interesting work (which they've discussed with you along the way), they can still be paid, especially if it turns out the original proposal was unrealistic.
Students that go AWOL
Sometimes students simply disappear. If this happens, contact soc-admins pretty quickly. For example, if they don't turn up for the weekly meeting two weeks in a row, don't submit status, or nothing appears in P4, give us a ping. Perhaps they forgot to tell you they were going on vacation for two weeks -- or perhaps we need to shake the tree a bit. It's much better to find out sooner than later, since both we and Google can apply pressure if required.
What to do if things start going wrong
Talk to other mentors if you need advice about how to deal with unexpected problems. E-mail soc-admins quickly if you think things are going horribly wrong -- can't communicate with the student, complete expectations mismatch, your house burns down, etc. Do not leave things until an evaluation deadine approaches or the summer is over to notice that your student and you are not talking!
Mentor Deliverables / Student Evaluation Deadlines
Murray Stokely
Now is probably a good time to summarize the official 'deliverables' that we need from each mentor this summer. These take the form of the mid-term and end-of-term student evaluation surveys. These are generally quite short and relatively informal, but Google does need to know if the student has done the minimum amount of work and that you think they should be paid. The mid-term evaluations are currently scheduled for July 7-14th and the final evaluation deadline is September 1st. Please keep this in mind and make sure you will be available to submit evaluation forms through the web application if you are listed as the mentor for any student. Co-mentors don't have access to submit the forms by default, so the listed mentor in the webapp needs to be available during those dates. It is also worth noting that some open source organizations have not been invited back to participate in summer of code if it was too difficult to get student evaluations completed on time, and we'd like to avoid that in our case.
The best way to ensure that somebody (ideally the assigned mentor) can write a short evaluation is to ensure that at least biweekly status updates are available from the student and that the code is checked into perforce along the way. Status updates can take many different forms, but they need to be linked from one canonical location for all students. That location is FreeBSD Wiki, and we'll setup an account for each student. The SummerOfCode2010 page will have a list of each successful student project with a link to a separate wiki that the student maintains. That wiki can point to other blogs, or wikis, or whatever, but it must be clear from visiting that canonical location what the student has been doing, where are they relative to the original proposal, what is the status of the code, etc..
Status update emails sent by the student privately to the mentor do not work well in case something comes up and the mentor is travelling or unavailable when the forms are due. It is very much in the student's interest to maintain these status updates in a more public location where alternate mentors could find it and get apprised of the progress. I will make a few passes throughout the summer to make sure these pages are being updated, and will nag any students and mentors where it is not clear from this page what work is happening.
For any edge cases or problems you can talk with Robert and I first (or all of soc-mentors@) and we will escalate to Google if necessary. There are over 100 other open source projects so I'd really like to handle all of our own issues with students without having to escalate to Google when possible.