Welcome to the Advice for GSoC Mentors Page

While participating in Google Summer of Code^TM is an incredibly rewarding endeavor, creating the necessary structures for participating in the program can be a daunting prospect. The collective wisdom captured here should help you determine whether your organization has the resources to commit to participating in the program, how to deal with common pitfalls in the mentoring process and how to best encourage your students to both successfully complete their projects and stay on the path to becoming full developers/committers.

Google's program administrators highly recommend that your organization takes the time to publicly document how you plan to structure GSoC involvement within the project and how your organization plans to address some of the issues described on this page. We hope this information will help you to more clearly articulate your project's culture to prospective students, as well as serving as the plan of record for dealing with problems that may arise during the course of the program.

In addition to the information shared here, a good deal of great information comes from our annual Mentor Summits. Check out the Mentor Summit wiki for more details. Many thanks to the good folks at Oregon State University's Open Source Lab for all their help in making the wiki and its contents available to everyone as a resource.

Applying to GSoC as a Mentoring Organization

We don't mean to brag, but Google Summer of Code^TM is a very cool program. While it just seems natural that many open source projects would want to participate, clearly articulating your project's reasons for applying is a most helpful beginning to defining your mentoring structure, your expectations of your mentors and your expectations for your students.

There are a number of benefits to being a mentoring organisation in the Google Summer of Code^TM. There is the obvious one, you get a paid software developer for a few months. But this is only the surface. Your mentors will learn more about how to effectively bring people into your community, how to make them feel involved and how to guide them through those difficult first steps into open source. As a result your project will be in a better position to guide new arrivals that come from more traditional channels.

For this benefit to be fully realised it is important to ensure that your whole project community are on board with the mentoring task. Just because an individual is named as the mentor, it doesn't mean that they are the only one who deals with the mentees issues. The mentee is just a member of the community, like any other. Of course the mentor has a few added responsibilities. It is them who has to ensure that the mentee is comfortable and that they are able to get the most from the community.

Creating Your "Ideas" List

Choosing tasks to include on your project's ideas list can be challenging: some bugs may have remained open for years because a problem is extremely difficult to solve, some tasks which could bore a more advanced student may prove the perfect training ground for a less advanced student. What steps can you take to make sure your project's Ideas list attracts the right mix of applicants?

Be Specific. No, Be General.

Some students will be attracted to ideas that are carefully described and documented by your team. Providing a thorough roadmap for the implementation of the idea helps prospective students judge whether they are a good fit for the program, and whether they feel confident in their ability to actually complete the work.

The more specifically you describe your ideas before the program begins, the more students will apply with those ideas as their proposals. Sorting through these proposals is difficult because you know where the idea came from, thus the student applicants don't have a chance to show creativity (by thinking of the idea to begin with), and you are left trying to weigh the other factors in their application, like their prior experience or grade point average.

On the other hand, some students will have their own ideas, or will thrive when given a vague goal and have to provide the details for achieving that goal on their own. It is a disadvantage for these students when you provide super-specific specifications in advance of the program. The applications of these "creative" students are easier to judge. First, they are presenting their own idea. The merit of the idea, as well as how it is presented, speaks loudly for the abilities of the student. Second, if any details are provided as to how the student hopes to implement their idea, you get a good sense of how familiar they already are with your project and the problem space they'll be dealing with.

The lesson here? To attract the widest variety of students, provide a variety of proposal ideas in different stages of detail. If your project needs a certain feature, and it is crystal clear how you need it implemented, spell it out. If you'd like to see general development in a certain direction, leave the door open for the students' proposals to be creative and encourage them to fill in the details themselves.

At the 2007 mentor summit Leslie Hawthorn shared this important factoid:

The most successful projects are the ones that are proposed by the students.

Scope and Scale

It is in everybody's best interest that your students complete their projects with flying colors. A small amount of useful code is worth more than a mountain of almost finished code. A happy student at the end of the program is more likely to keep working on his/her project than a frustrated one. Choose the scope and scale of your projects to reflect the following constraints:

• The brief duration of the program.
• The initial time that will be spent managing infrastructure and getting things set up.
• The fact that most students need the first month just to get their bearings and actually start producing code.
• The fact that any project that is worthwhile has inherent difficulties and real intellectual challenges, some of which won't be anticipated or predicted at the onset of the project.

Therefore, whether the idea for the project comes from you or from your student, be ruthless in scaling it back until it really fits within the time constraints. If all goes well, you and the student will have a lot of time after the program to implement phase 2 of the project, and add all those features that would be "nice to have".

Generating Ideas

Google Summer of Code can be useful to your project in ways that are not directly tied to gaining code and new contributors. For example, most projects have a portion of their community that is brimming with ideas and feature requests, but is not directly able to initiate the implementation of their ideas (ie they can't code). These are the people you want to engage when creating proposals for students to work on. Use your project's website and mailing list to collect ideas from all segments of your community, and keep them up to date with the status of the projects as the program progresses. Your students and your community will benefit from this.

Be Accessible

A successful SoC student will have good communication skills. This is a simple fact of the nature of distributed projects (such as most open source projects). The people involved must regularly overcome the barriers of distance, language, culture and time zones in order to come to agreements and exchange knowledge.

By making yourself available to discuss the proposed projects in advance, you are inviting the good communicators to reach out to you and demonstrate that they are suited for working on a virtual team where independence and cooperation must coexist. They will ask for suggestions on their proposals, bounce their ideas off you to see if they fit your project, and reveal aspects of their personality that will be useful to you when evaluating their applications later.

In most mentor organisations there will be more applications than slots available. This was certainly true at the ASF where the sheer number of projects we have means that we have had at least four times as many proposals as funded slots in previous years. In order to select the best projects committers interested in the GSoC programme have reviewed all the students applications, so the quality of the proposal was important. However, we added considerable weight to those proposals that had entered into a dialogue with the project community already. Just being smart is not good enough in open source, the ability to ask for and accept guidance is even more important.

Allocating Resources

A good rule of thumb when finding and assigning mentors is to have two mentors per student. It is also a good idea to have a spare mentor or two who can pay attention to many students and keep track of the big picture.

Why so many mentors? Assisting in someone's learning is a time-intensive operation. You must be able to keep up with the details and development of the project and be willing to spend time, even daily, communicating with the student. Chances are you'll be taking some time off during the program, or get otherwise caught up with real life. Having two mentors helps guarantee that neither one gets too heavily burdened by the responsibility of mentoring, and helps avoid the situation where a student's progress is blocked by an unavailable mentor.

It helps ease the burden of the individual mentors if you encourage your student to tap the wider community resources available to your project. Do you have developer mailing lists, support forums, IRC channels or a wiki? All of these should be on the list of places for students to go to get help. While it is the mentor's job to be personally involved in the student's success, it is all too easy for the student to view the mentor as one-stop-shopping for answers and support.

It's almost impossible to put a figure to how much time mentors will spend with students. It depends a great deal on the student, the level of community support, the project structure and many factors completely out of the control of those involved. However, as a rule of thumb, most mentors have reported that they spent about five hours per week working with their student.

Reviewing Student Applications

In order to select the best students for your project, your organization needs to have a good understanding of what you're looking to gain by participating in the program. Obviously, we're trying to bring new blood into open source, but choosing to work with a total newbie may not be the best decision for your organization. If you will be working with students who have little or no previous open source experience, your organization's approach and expectations will vary drastically from a project who is looking for more advanced developers. In an ideal world, your accepted students will have a wide range of development experience and expertise, allowing each to learn both from your organization's mentors and from one another.

During the selection process, it is important to have good communication lines open between the various mentors who are reviewing applications. Depending on the number of applications your project gets, this is a large task, so be prepared. Having hundreds of applications to review is typical for some of the bigger projects.

You will most likely want to start your reviewing process by eliminating those applications which clearly don't meet the standards of the program. Whether the applicant lacks qualifications, or is simply proposing something that doesn't fit to your project, paring down the field before seriously reviewing the top applications is a big time saver.

Your project has quite a bit of control over the selection process. For example, some projects require an interview with the students before they make their final selections. This can be done via IRC, phone, email, or however you choose. This is not a requirement, but it may serve to connect you with the applicants who will work best with your project.

It is also helpful to discuss with your mentors exactly what traits and qualities you are hoping to find in students through the application process. Communicating this to your applicants is also desirable. For instance, if your project hopes to solve a particular problem that requires very strong skills in some particular area, and you will be looking especially carefully for students who fit these needs, be clear about the fact during the application process. The better you are able to communicate what it is you are looking for, the easier and more transparent the selection process will be.

An extreme but effective way to be sure that your students are up to the task is having a qualification entry test. Nothing gives you more information on how good the candidates are than having them already try to cope with the burden of contributing to your project and to face peer community peer review. Obviously you must pick something involving enough to give them the chance to prove themselves, but small enough to be done in a few days. Some projects have asked all applicants to submit a patch before submitting their program application and have reported that the excercise was very useful.

If you do not receive enough qualified proposals to fill all of the slots you've been allocated, consider giving your open slots to other organizations who have too many qualified students. Its much better for students and mentors to both be fully excited about participating in the project, than to accept lackluster students because you have still have open slots.

At the 2007 mentor summit Leslie Hawthorn said:

The first student submission is almost useless. Follow up with promising students and guide them to improve their submission.

Robert Kaye, mentor for the MetaBrainz Foundation says:

Encourage students in your own community to participate in GSoC. Even though students may respond with: "I'm not good enough for that!" we've seen these students make excellent contributions outside of Google Summer of Code^TM that are on par, if not better than accepted students. Students from your community already understand open source and your project. Bringing in new students, especially students who are new to open source, can be a lot of work and result in culture shock.

Engaging Your Students

Once accepted, students will in many cases have no idea where to start. So, the first thing to do is to send them a mail with links to community resources describing how to contribute to the project. That is, how to record a bug, how to create a patch, how to discus design issues etc. Many projects will already have this documented and available on their web sites; if not, now is the time to do it.

Reassure the student that the community will help them understand the new processes and technologies they face. Make it clear that, as long as they can demonstrate that they read whatever documentation is available, i.e. they can ask an informed question, the community will be more than happy to provide additional guidance (especially if the student then clarifies the documentation).

It is also important that the students should concentrate on what they will bring to the project. They should ask themselves every day if what they are doing is creating value for the project. If it does, they will benefit from that automatically, but if they concentrate on what they are getting out of GSoC, such as the money, they are much more likely to fail.

Tim 'Mithro' Ansell says:

I feel it is important to make the student feel part of the community. This can be done a number of ways. For Thousand Parsec, when students passed the mid-term evaluation we sent them a project t-shirt as a suprise (it's all about the tshirt). Other things like announcing that they have passed and advertising their progress also helps. Try and get other people to test the student's code, nothing is cooler then having the project's founder lodge a bug report against your code :)

Communication

Since one of the objectives of GSoC is to introduce students to real open source development, it is important that communications are only made through the usual community channels. Furthermore, students should not be forced to do anything that other contributors do not do. If the student wants to blog, let them do so, but do not force them; requiring progress reports is a reasonable course of action, however.

Make it clear to the student that you will evaluate their performance based on the way they interact with and report to the community. They should not be evaluated solely on what they produce, but also on their contribution to the open source project as a whole. Clearly code contribution is important, but so is community contribution. Therefore, communication via the normal project channels is an important part of their GSoC experience.

Mentoring Best Practices

Approaches to mentoring are going to vary widely depending on individual and project preferences, but here are a few thoughts on how to effectively mentor your students that should at least be a good starting point for your organization.

Augie Fackler says:

For contact with a mentor, a regular status report is a fantastic idea. We didn't do this with Adium in 2006, and we had much better results overall when we required a status report from all students once every two weeks. It wasn't anything special, just a brief "this is what is going well, this is what is not" email from the student to the mentor and organization admin. Also, keep a "spare" mentor around - someone who can reasonably answer questions and could bear part of the burden of mentoring. That will help if one of your mentors isn't available for some reason

Ideally, a student will participate in the community. Try to have discussions (especially design discussions) in the regular way, even if it ends up just being a thread between the student and the mentor. The log of the discussion could be useful for other students or just the community at large. If you have regular online meetings of the core development team (on IRC, for example), the students should be invited to attend.

If you're using Subversion, don't make the mistake Adium did last year and move a student to trunk before the end of the summer - we had to write a script to parse which changes belonged to him and which didn't. It's far better to have the work all in one place.

TODO: Fill me in. :) what did your project do to help your students be successful? what was the particular approach of your mentors that worked quite well? anything approaches that you will never, never take again?

Mentoring Organization Best Practices

Similarly to individual mentors, the culture, leadership, and community cohesion will vary widely among different projects or mentoring organizations. Nonetheless, this is an attempt to collect some thoughts and practices that may help a broad variety of projects make the GSoC experience for their mentors and their students is as enjoyable as possible.

Communicate with and among your prospective mentors. Make sure they know from the beginning what to expect from the program, and what will be expected of them, especially if your organization is new to GSoC, or some of your mentors are. Give guidelines specific to your project and organization, such as the time commitment they should expect to make, what mentoring will consist of, and what they can realistically expect from students. Facilitate open conversation among the developers (one of whom will often be the organization administrator) about their motivations and what they expect to get out of the GSoC.

Be as diligent in selecting and preparing mentors as you would be for students. Mentors can make all the difference for students, in both directions. A brilliant programmer is not necessarily also the best mentor, and developers aren't necessarily well-trained in mentoring. We expect GSoC students to embrace communication, but in many ways the mentor will set the example. Try to identify how best to pair mentors for projects so that their strengths complement each other. Find out what other help your administrator or your project's entire community can provide to your mentors to help them in their role.

Less may be more. Resist the temptation to offer more projects than are backed by enough and fully committed mentors. Having to cancel a project after students applied to it, or worse after a student was accepted or even started to work on it is sure to waste a lot of time and energy, of more than just the people affected directly. A mentor dropping out or turning out to be overextended can always happen, but it shouldn't be something anticipated for a project to beging with.

Give leadership to (and expect it from) your organization's administrator(s). Though many open-source projects may not have a real leadership structure and may be run rather anarchic, that's not really how GSoC works. Google will turn to your organization administrator whenever there is a problem with one of your mentors, students, or with any administrivia, such as student acceptance conflicts, missing student evaluations, etc. Moreover, most of the suggestions above at the end of the day require a trusted person capable of and empowered with coordinating and making decisions, possibly overriding dissenters if consensus can't be achieved. The organization's administrator will also typically be the one to mediate when issues arise or escalate between a student and a mentor. Finally, someone needs to follow-up on the guidelines and policies (communication, progress reporting, etc) your organization agreed upon to make sure they are consistently applied.

Dealing with Common Mentoring Issues

Disappearing Students

At times, students simply drop out of contact for weeks at a time. Particularly since the program involves distributed work, it can be difficult to assess why a student has disappeared and whether pursuing the relationship with the student is worthwhile. If you do find that your disappearing student reappears, determining how to best ensure that s/he remains engaged throughout the rest of the program can also be challenging.

Don't bother hunting for missing students. A couple of mails along the lines of "Are you OK? Need any assistance?", followed by "I'm worried about your work here, it may affect your evaluation. Take a little time to inform me of your situation so I can accommodate it" are sufficient.

For students who disappear without notice and then reappear it is important to set some early (and tough) objectives for them to meet in order to catch up. If their absence was genuinely unavoidable they will be happy to work at meeting these objectives. If they are a freeloader they will spend more time coming up with excuses.

Get rid of the freeloaders quickly. There is no point in wasting your volunteer time on such people.

Personality Conflicts

It's a simple fact of life that we are not all going to get along with one another all the time. That said, there can be times when a student and mentor are well matched technically, but not personality-wise. There may be times when a student feels her/his mentor's expectations are unreasonable or unfair. In order to be best prepared, your organization should have a clear plan about dealing with personality conflicts.

Tim 'Mithro' Ansell says:

Our organisation tries to make it clear that a student can approach any mentor if there are problems. This gives the students an easy way to talk about problems with their mentors. This was specially important in our organisation as I was both a mentor and the project administrator. It also gives the student a choice of mentors to talk too.

Shy Students

Google's program administrators have commonly heard that it can be difficult to get students to communicate on the project's main development mailing lists; many GSoC participants are new to open source development and sending questions to a public mailing list can be an intimidating prospect. Even for those not new to open source, posting a question to a mailing list when you know that the project founder and lead developers are subscribers can cause great trepidation.

It's scary posting to a list of people you do not know, especially when the perception is that they all know more than you. So, consider how to lower them into the list gently. One trick is to ask them a few questions about integrating their work with existing code. Ask these questions in your initial welcome mail (sent off list) and suggest that you do not know the answers, but someone on the list will.

Now the student can either post answers to the list (a real confidence booster) or will be asking questions their mentor does not know the answer to. Both of which are less frightening than asking a potentially dumb question of your own. Once they have posted and not been shouted down the next post is easier.

Unproductivity

There will always be times when there are productivity lulls, but determining how to best motivate a student when such a lull occurs is never easy. The lull may be caused by a variety of factors: the student may take vacation, have a family emergency, or realize that the project is far beyond the scope of her/his expertise, etc.

Augie Fackler says:

Our students have always given us scheduled things like vacations as part of their timeline for completion so we know in advance how many "real" weeks of coding they're going to do. It's been nice to have. Don't be afraid to ask a student for information about planned vacations that could take them away from the computer.

At the 2007 mentor summit Leslie Hawthorn said:

If your student hasn't checked in code by the mid-term evaluation or if your student can't make themselves available to discuss the review, fail them. If you're not 85% certain that the student will continue with the project, fail them!

Work with your students to set up expectations; if your student doesn't follow these expectations, but you're happy, Google doesn't care. But if you're not happy, then reiterate your expectations to the student and make sure they understand them. If they still don't live up to their expectations, ask them to leave.

Make Summer of Code your own

You should make Summer of Code what you want it to be. Google intentionally leaves the structure of participating wide open to allow many varied approaches. This freedom gives mentors and students the most amount of control over the project. Don't worry so much about what Google thinks about how you're conducting your project. As long as you and your students are respectful, making progess and everyone is happy, Google doesn't care what form your project takes.

More Resources

Federico Mena-Quintero, GNOME mentor for GSoC 2006, has posted a great mentoring how-to document.

Sean Morrison, BZFlag mentor and org admin for GSoC 2007, has posted an overview of their participation in the program. Good reading for first time mentors. Warning: huge PDF, ~ 15 MB. You can also check out more notes on their project's wiki.

Jan Schauman, mentor and org admin for mutiple GSoCs with the NetBSD project, did an interview with Ars Technica on NetBSD's repeat performances in Summer of Code, amongst other topics.

Robert Kaye, mentor and org admin for the MetaBrainz Foundation posted an announcement how MusicBrainz changed its approach to participating in Summer of Code 2008