Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
165 lines (125 sloc) 7.81 KB
Students,
This mail is trying lay out some guidelines all TPF summer of code students
should be following. I'm trying to keep this as small as possible. If you're
interested in more reading on how exactly this summer of code thing works, I can
wholeheartedly recommend the unofficial students manual at
http://www.booki.cc/gsocstudentguide/ and the chapters following that.
Your mentor*s*
==============
This year we have the luxury of giving each student two mentors, to provide you
with more feedback, to reduce the load on the mentors, and to be able to detect
problems as early as possible.
The summer of code website only allows one person to be signed up as an official
mentor. That's your primary mentor. The second person listed next to your
project in the previously announced list of accepted projects is your backup
mentor.
It's up to the mentors of your project to decide how they want to divide the
mentoring duties. Your mentors will let you know how things are going to
work. However, one thing the backup mentor absolutely must do is to follow the
progress of your project. That's why all communication you're having with your
mentor should, where possible, be available to your backup mentor as well. For
emails, Cc him or make sure he's subscribed to the mailing list you're
discussing your progress on. If you're discussing things on IRC, try to do it in
a channel where both of your mentors are present.
I recommend you get in touch with your mentors early. Say hi in an email or on
IRC - they're all nice guys and as excited about your projects as you are.
Community bonding period
========================
Now that you're accepted the summer of code program suggests that you prepare
yourself for the coming tasks. Some of your projects require preliminary
work. Make sure you'll manage to finish that before the coding period
starts. Familiarise yourself with the version control system being used for the
project you're working on, find out what coding style you're expected to use,
etc.
All these things are excellent opportunities to get involved in the community
you'll be working with. Sign up for the development mailing list of your project
and try to hang out on its IRC channel. Play with the existing code base and
learn to find your way around it and experiment. Ask questions as they come
up. Get to know some of the other contributors. Your mentors will be happy to
introduce you.
Be sure to get to the point where you can actually start your work when the
coding period begins on May 23.
Regular status reports
======================
We don't want you to feel alone in your endeavour. We want to help you as much
and as well as we can. For that, it's critical to know what you're up to.
To ensure we're not missing out on anything, we need you to update us on your
progress on a regular basis. We ask you to do this by sending an email to both
of your mentors as well as the tpf-soc-students@googlegroups.com mailing list at
the beginning of each week. Start by the beginning of the coding period at
latest, but of course we'd also love to hear what you're up to in the community
bonding period, so feel free to keep us updated even before that. Feel free to
also send a copy of your report to your project's mailing list or any other
place you like, such as your personal blog.
These reports don't have to be very long. Include a brief summary of whatever
you've been working on the week before and which milestones you might have
completed as well as things such as the problems you've overcome, possible new
problems you're facing, links to code you've written, and things you might be
blocking on.
Based on these reports, your mentors will provide you with feedback on what
you've done, and try to help you plan the next steps for the following week.
If, for whatever reason, you won't be able to send your report in a timely
fashion, please give your mentors advance notice and try to explain what the
problem is, when it might be over, and what they might be able to do to help you
fix it.
Please don't miss status reports. It's our primary way to know what you're up
to, and without knowing that, we can't help you. For a successful summer of code
project, good communication is essential. Failures to communicate will lead to
failing projects almost all the time. Try not to fail at communication :-)
Similarly, if your mentors fail you and don't provide feedback to your status
reports or replies to your questions in a reasonable amount of time, make that
known. Send me an email, and we'll work on fixing the problem. Spend as little
time as possible waiting and doing nothing.
Be proactive
============
If you ever get lost or run into a problem you're not able to solve on your own
in a reasonable amount of time, don't wait for your mentors to notice that on
their own and offer their help. Instead, ask questions early and often. That's
one of the most important things mentors are there for.
If you don't understand your mentor's answer right away, follow up on it. Ask
for specific examples, guidance, and suggestions.
Plan ahead, but not too much
============================
Your mentors are there to help you figure out what the next thing you should be
hacking on is, but they have other responsibilities too, so it might take them a
couple of days to get back to you. Therefore, always be sure to understand what
the next step will be so you won't end up being blocked by your mentor's
communication lag and do nothing for a week.
However, don't think too far ahead either. Don't get lost in trying to figure
out how all the things you're working on are going to fit together. Your mentor
will ensure that all the steps will fall into place naturally.
Stay focused
============
We love to see you getting involved with the community you're working with as
well as the greater Perl community. However, don't get side-tracked too much in
discussions about what your project should or shouldn't do with other community
members that might have a much less deep understanding of what it is you're
trying to achieve. Remember the scope of your projects as per your proposal and
only change it in agreement with your mentors.
Evaluations
===========
At two points during the summer your work will be evaluated by your mentors:
once in a mid-term evaluation, due June 15, and once in a final evaluation, due
August 26.
The most important measure your mentors will use for your evaluations is the
project schedule you prepared as part of your application. If you're too far
behind on the milestones in there, being failed becomes quite likely.
Make sure to stick to your time-line as close as you can, but also note that the
schedule is not set in stone. When you and your mentors discover unforeseen
problems, for example, you should discuss appropriate modifications of the
schedule. Changes to the schedule are only possible in agreement with the
mentors. Your mentors will maintain one authoritative version of the schedule
and share the updated version with you whenever it is changed.
If, at any point, you're unsure if you'd be passed or failed if the next
evaluation was happening tomorrow, someone failed to communicate. You should
always be clear about what your mentor's expectations are and how well you're
currently fulfilling them. If you aren't, bring the issue up, either to your
mentors or to me privately, and we'll figure things out.
In a similar fashion to how the mentors will evaluate you, you will also be
asked to evaluate your mentors. And exactly like the grade your mentors will
give you shouldn't ever be a surprise, your mentors should always know how
satisfied you are with their performance at any point. If you're unhappy about
your mentors' response times, the amount of guidance they give you, or the way
they communicate, tell them! If that doesn't help, drop me an email describing
your problem and we'll get it sorted out. Don't be shy - we love feedback and
want to improve.