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.

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.