This is the final post in a series of three posts on the DOs and DON’Ts for Google Summer of Code students, mentors, and organization administrators. This post deals with mentors; the first post dealt with students and the second post with organization administrators.
The role of a mentor is to monitor the progress of each accepted student and to mentor them as the project progresses. Based on our experience with Google Summer of Code, we’d like to share these tips and antipatterns with you to raise awareness and help mentors avoid the same mistakes that have been made by many others. For even more advice, check out the mentor/admin guide.
| DO | DON’T |
| Be an active member of the community you are mentoring for. One of your goals should be to integrate your student in the project community. You can do this best if you are a part of it yourself. Introduce the student to the people in your community and your communication media. Also familiarize the student with the rules and norms that your community abides by and that they might not be aware of yet. Apply as a mentor only after interacting with the community. | Apply as a mentor to organizations where you don’t contribute. Every year, a surprising number of people request to become mentors for nearly every organization in Google Summer of Code simultaneously. In general, this is treated as spam and you will be blacklisted for doing it. One of the goals of Google Summer of Code is to introduce the student to the community. You may be an expert in the code, but the goal is to integrate code and transform students into long-term contributors; if you don’t know the community, both of these are much harder. |
| Focus on one student. New mentors should concentrate on doing an amazing job mentoring one student instead of spreading themselves too thinly. Even experienced mentors should take caution when thinking about mentoring two projects—it’s not unusual for both projects to be mentoring-intensive. If that happens, you may not have the time to do your students justice, and it’s unfair to fail students because of your own difficulties. This is one reason backup mentors are critical. | Take on too many students. Mentoring more than one student in your first year is a recipe for failure. Even if it’s your second year, this advice still stands, as the amount of time needed to mentor a student varies wildly between students, projects, ideas, etc. People mentor multiple students successfully each year, but many people fail at it every year too. If you have experience and still want to mentor two or more students, plan to set aside time during your full-time job because your free time probably won’t be sufficient. |
| Communicate frequently with your student and org admin(s). You’ll need to answer to both your org admin and student— make their lives easier by being available when they need you. Most admins will periodically check in to make sure all your organization’s projects are on track; if you don’t respond in a timely manner, they may think your project is failing. Your student often has a regular stream of questions, some of which can’t be answered by Google, so be available to avoid wasting your student’s time and delaying the project. | Disappear. Some students will need constant access to their mentors. If you intend on being out of touch for even a relatively short period of time, even just a few days, let your student know ahead of time. Arrange it so that your student is able to reach a backup mentor during this time and having the student know about this backup mentor from the beginning of the project is also good advice. Although disappearing mentors are less common than disappearing students, they do happen. This can really put a strain on your org admin who has to replace you on short notice, maybe near a deadline. |
| Set aside at least 5 hours a week for mentoring. The student has to do the actual work over the summer but you’ve committed to help them along the way. Depending on how much help your student needs, this can be a significant task. Set aside at least 5 hours per week for mentoring unless you are certain the student is well integrated and supported by the whole community. And even then, plan for road-blocks along the way that you need to help with. | Underestimate mentoring effort. Mentoring takes time. No, really, it does. You might be lucky and have a student who needs little mentoring, but you probably won’t. If you don’t have at least a few hours per week over the course of the program, you have two options. You can either choose not to mentor or you can team up with another member of your team as a back-up mentor. Be aware that ‘a few hours’ can grow quite significantly if you or the student overestimated their abilities, underestimated the project, or they need more significant help than you planned. |
| Give your student frequent feedback on performance. Let the student know whether you are happy or unhappy with his performance. Chances are he can’t properly judge his own performance and abilities yet. Make sure your student sees failure coming a mile away; it should never be a surprise. You also want to ensure your student knows his work is high-quality, if it is. Give feedback regularly. This goes both ways—ask your student if he is happy with your mentoring and where you might be able to improve. | Provide zero feedback, then abruptly fail the student. The student depends on feedback from the mentor. This includes situations where things don’t go as planned. If it is the student’s fault, he should learn about it as soon as possible to be able to correct it, and more importantly, avoid repeating it. Failing your student by surprise is almost guaranteed to end up with bad feelings on both sides and can result in appeals to Google. It’s equally bad for a student to spend the summer frightened that they’re doing a terrible job because you haven’t told them that they are actually doing fine (or better). Communicate. |
| Ensure your student’s code is ready to integrate. Seeing code shipped in a release and then used by thousands of people is the ultimate motivation to continue being an active part of your community for many people. You should help and motivate your student to go those few extra steps and get their summer’s work into a release. You can jump-start this with small tasks and bug fixes before application time, or in the community bonding period. This way you can ensure your student has some code committed before even starting the project. Encourage students to keep code in a state where you can still integrate it if they leave the project immediately after, or even during, Google Summer of Code. | Fail to ship your student’s code. Your student might not have gotten the code into a state that’s ready to release or integrate by the end of Google Summer of Code. Do not wait too long with this—if the goal isn’t the next release, it may never happen. Committing the result is an expectation worth setting, so ensure your student understands this from the beginning of the project. If your student forks or branches early and doesn’t track any changes to trunk it can be hard to integrate. If your student develops in a non-agile style where the code doesn’t work at all unless the whole project works perfectly, the same problem can arise. |
| Prevent your student from going down dead ends with code. Your student will make mistakes and wrong decisions. It is your job as his mentor to intervene when he is stuck or heading in the wrong direction. Do this early. Google Summer of Code is too short for anything else. This requires you to keep a close eye on what he is doing. Some teams prefer short daily meetings to make sure everyone is on top of things and know what everyone else is working on. It’s also important to reinforce good practices so the student can continue to use them. | Review your student’s code for the first time at the end of the summer. Your student might be a genius and a mind reader but chances are that he isn’t. He probably won’t create an excellent design, write perfect code and deliver stunning documentation independently. He’s probably never done a project of this size before. If you don’t find problems early, they pile up and lead to a failed project with nobody to blame for it but yourself. |
| Promote your student’s independence. When your student encounters a problem and comes to you or the community for help, ask her to suggest a potential solution as well. This encourages your student to learn how to do research and to fully understand problems and how to get into the mindset of solving them. It also makes it much more likely that her questions are well-informed, giving the community a much better impression of your student. When possible, direct your student to participate directly in the community rather than acting as a conduit, because close ties to the community make it more likely that she will want to stay involved with the community after the summer. | Get between your student and the community or the code. It’s easy to fall into the trap of writing tricky code or solving every difficult problem for your student. This prevents students from gaining skill and confidence by solving their own problems, or at least making progress toward a solution. One of the best ways to ensure your student disappears at the end of the summer is to never invite her into the broader community of your organization. Without social ties, students are much more likely to move on to other things and leave your organization behind. |
Making Google Summer of Code the best possible program requires preparation and a commitment to excellence from all participants. Now that we’ve provided suggestions for mentors, org admins, and students, you should know how to avoid the most common problems at every level. Whatever role you would like to play in Google Summer of Code or a similar program, read everything you can so you are fully prepared for the experience. Good luck, and have fun in your endeavors.
By Donnie Berkholz, Lydia Pintscher, and Kevin Smith, Google Summer of Code Administrators for Gentoo & X.Org, KDE, and XMPP Standards Foundation, respectively
