April 2024 - This site, and Kamaelia are being updated. There is significant work needed, and PRs are welcome.
Note, this page relates to the Kamaelia team's involvement with
Google Summer of Code from 2006 through 2008. In particular this covered
the summer of 2008. At this point this page is for historical
interest.
Kamaelia Summer of Code
Mentoring
Since we have external mentors this year with Kamaelia as part of
summer of code (external to BBC research this is!). As a result, I think
it would be good to discuss how we've handled mentoring in previous
years. This has normally been part of a welcome to the project
email, but it's worth pulling out.
We have one expectation regarding students which has to be adhered to
- communication. Schedules and aspirations do not always match, and
unforeseen problems can throw projects out of kilter.
The way we usually work therefore is as follows:
- Students are given space in SVN for all their development, and are
expected to check in every day they write code. (this
makes it possible for a mentor to be familiar with their work and see
progress)
- To balance this mentors are expected to read the check-ins, and
check code as and when it becomes runnable. (ie be familiar with what
their student is doing!)
- We expect students to hang out on IRC during what they view as
office hours, though idling the rest of the time is welcome.
Likewise for mentors as much as they can.
- We've previously held weekly meetings during GSOC, and experience
shows that this is a good idea - everyone gets a better idea of how
their work fits in with other projects, and gets to see common problems.
This meeting occurs on IRC and has a standard format to speed things up.
It is forcibly limited to an hour, and focusses on DONE/TODO (in next
week)/BLOCKED and focusses on getting people unblocked.
- Each student arranges with their mentor a specified time/duration
each week which is their guaranteed mentor time. Less than an
hour is a bad idea. Huge amounts risks spoon-feeding &
micro-management. Experience has shown that if this is skipped that a
project tends to drift. So, whilst it can be skipped if people are clear
what's going on, skipping it two weeks in a row is a bad idea. Note:
this isn't a maximum amount of time, but more a guarantee between the
student and mentor that they will be around for that period as a
guaranteed minimum. (given the idling on a channel requirement,
for some people this minimum has seemed superfluous)
- We expect questions to be raised sooner rather than later (ie people
shouldn't wait until either meetings or guaranteed time), and likewise
if you hear a question you know the answer to, you're expected to answer
it, to avoid the bystander
effect.
Better to think of this (your mentor) as "someone who's
looking out for you" rather than "boss". Becomes even more obvious why
micromanaging doesn't make sense with that description, but "boss" is a
far shorter word, even if totally inaccurate!
There's various ways to view this, but the key one is this - consider
if you were working on-site:
- Your boss wouldn't micro-manage you on a daily basis. (you'd hope
not anyway) They'd expect to see activity towards your goal, but being
micro-managed isn't fun and neither is micro-managing. Similarly, when
you raise an issue it'd be useful if your colleagues had an idea as to
what you've been doing. (cf checkin emails)
- Team meetings are useful for seeing how everyone is doing, and to
see how your work fits in. Similarly raising common issues then is a
good idea. (weekly irc meetings)
- Likewise, if having a weekly time when you can take time out to
raise issues - either in front of the rest of the team or in private
would be considered useful. (guaranteed mentor time). Not every issue is
shared.
- Similarly, one of the best ways of getting help and building
connections & friendships with those you're working with is by
simply being around and being social. (hence being
on-channel)
Generally speaking, mentors should be willing and able to answer
questions when students ask them, but students have to be willing and
able to accept that they might not get an instant answer. If they don't,
repeating the question over email (over the public mailing lists) is
important, since it captures the question and answer. (Much like in a
busy office you could go over and ask someone a question and they might
say not now, drop me a note and I'll get on it)
Put another way, mentors should consider students as equivalent to
new colleagues who need help being shown the ropes, rather than people
who need micro-managing. This will vary across the board from technical
issues through to admin.
As a result having a variety of modes of communication is extremely
useful, and provides good reasons for the students to raise and air
issues without concern, and the same for mentors. IRC is a critical
medium in making this work.
However at the end of the day, getting excited about your student's
work and sharing in their successes, and assisting them towards that
generally appears to be the only common success factor. You can only do
that if there's sufficient communication going on, and if your student
has communicated a clear vision of what they want to achieve.
If that is the case, then both student and mentor can often have a
very enjoyable and successful summer.