Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tree: d89a4aed29
Fetching contributors…

Cannot retrieve contributors at this time

file 110 lines (81 sloc) 5.079 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110
Mentors,

This mail is trying lay out some guidelines everyone mentoring a student this
year should be following. I'm trying to keep this as small as possible. If
you're interested in more reading on your mentoring duties, please refer to
http://www.booki.cc/gsoc-mentoring/_v/1.0/mind-the-gap/ and the chapters
following that.


Backup mentors
==============

This year, given the number of slots we were assigned and the huge amount of
mentors at our disposal, we have the luxury of giving each student two mentors
to reduce the load on the mentors, to provide the student with more feedback and
to be able to detect problems early.

However, each project can only have one assigned mentor. I'll refer to that
mentor as the "primary mentor". The second mentor is the "backup mentor".

Backup mentors are, of course, free to get involved into the mentoring process
as much as they like. However, the minimum a backup mentor has to do will be
monitoring the status of the project as well as the communication between the
primary mentor and the student, as described later on in "Keep in touch with the
student".

Primary mentors and backup mentors should get in touch with each other well
before the coding period starts and discuss how exactly they plan to handle the
mentoring tasks.


Make sure your student is ready to start working before he has to
=================================================================

After the participating students have been announced on April the 25th, go and
talk to your students and help sort out possible problems they might have
getting started on their projects.

Some of the projects require some prelimary work to be done. For others the
student might still have to familiarise himself with the version control system
being used, the coding style he's expected to use, and similar things. Make sure
that happens - help out as necessary.

If you've not already done so, work with the student to ensure that the schedule
for the first few weeks of the project is agreed on..


Keep in touch with the student
==============================

In order to avoid surprises, it's necessary to keep track of what exactly the
student is up to. For that, students will be required to send weekly progress
reports to their mentors as well as the tpf-soc-students@googlegroups.com list.

Keep track of those progress reports. If possible, provide the student with
feedback on his report. That includes correcting a wrong path the student might
have chosen, providing feedback for the code written that week, as well as
setting your expectations for next week.

Try to figure out what problems the student is faced with and provide
guidance. Don't assume the student will always proactively ask for help.

If the student fails to provide his report in a timely fashion without giving
prior notice with a good reason, find out why and also drop me an email.

If a mentor fails to provide feedback on the student's report, the backup mentor
should be filling in to prevent the student from being blocked from doing
further work. If this happens, or if there's any other communication problem
observed by any mentor, I'd also appreciate being notified by email so we can
work out a plan to fix things.


Maintain a schedule
===================

The students have already provided a project schedule with their
applications. Use that as a basis and maintain it throughout the summer,
amending it based on the progress of your student. Any changes to the schedule
should be made in agreement with the student. Make sure the student always has
an up-to-date copy of the schedule.

This is particularly important because the completion of the schedule is an
essential criterion for student evaluation, both mid-term and at the end of the
summer.


Evaluate the student
====================

The student being paid entirely depends on his mentor's evaluations. You'll have
to submit two of those to Google - a mid-term evaluation, due on June 15, and a
final evaluation, due on August 26. In those evaluations you'll have to answer a
couple of questions about the student's work and your interaction with him, as
well as give him either 'pass' or 'fail' as a grade. When failed, the summer of
code is over for the student.

Only the primary mentor is able to fill out evaluations on the melange site.

The grades in the evaluations should never be a surprise to the student. Based
on the weekly feedback to his progress report as well as the current progress on
his schedule, the student should already have a good idea on where he
stands. It's the mentor's job to make sure he has that
understanding. Additionally, if things aren't going well, be sure to get in
touch with your backup mentor and me early on, so we can try to come up with a
plan for rescuing the project without failing it.

If in doubt as to whether to pass or fail your student, err on the side of
failing. A project that has got badly off track tends to be very hard to
rescue. It's often better to cut your losses than to prolong suffering on both
the mentor and the student-side.
Something went wrong with that request. Please try again.