Google Summer Of Code 2007 @ Eclipse: Mentors Guidelines

(Shamelessly stolen from Joomla at http://forum.joomla.org/index.php/topic,141965.0.html and adapted to Eclipse.)
Google Summer of Code is a program that offers student developers stipends to write code for various open source projects. Google works with a several open source, free software and technology-related groups to identify and fund several projects over a three month-period. Historically, the program has brought together over 1,000 students with over 100 open source projects to create hundreds of thousands of lines of code. The program, which kicked off in 2005 , is now in its third year, following on from a very successful 2006.

This document describes the mentor guidelines for the Eclipse Google Summer Of Code program 2007. It contains information about the program schedule, program goals, program organisation, the mentor-ship selection process, conflict resolution/problem solving resolutions, what to expect (and what do we expect) and of course communications and tooling.

Mentors, please sign up here to join as an Eclipse mentor. Visit the Google Summer Of Code 2007 @ Eclipse: Mentors Guidelines page for more info. The mentor Home page at Google is here . Email the admins for the program to get your Mentor application accepted. A nice intro email should work if you have the right credentials: philippe.ombredanne (at) eclipse dot org and wayne.beaton (at) eclipse dot org.

What does it takes to be a mentor?

Above all, some serious committment to support and help one or more students to bring their projects to completion, and that for the duration of the program.
You must have a good Eclipse and open source development background. Sometimes, it is better if you are either a committer @ Eclipse.orgg or a committer on an open source Eclipse based project. (But is not mandatory). The amout of effort required may be between a few hours to a day per week for the duration of the program.

Currently, we have Wayne Beaton and Philippe Ombredanne as administrators for the program.
Potential mentors are to be listed soon.

General program schedule

Week of February 12th: Announcement that Google will fund GSoC 2007
March 5: Mentoring organizations can begin submitting applications to Google
March 12: Mentoring organization application deadline
March 13: Google program administrators review organization applications
March 14: List of accepted mentoring organizations published on code.google.com;student application period opens
March 27: Student application deadline (revised)
Interim Period: Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant
April 11: List of accepted student applications published on code.google.com
Interim Period: Students learn more about/integrate with their project communities
May 28: Students begin coding for their Google Summer of Code projects; Google begins issuing initial student payments
Interim Period: Mentors give students a helping hand and guidance on their projects
July 9: Students upload code to the Google Summer of Code project repository; mentors begin mid-term evaluations
July 16: Mid-term evaluation deadline; Google begins issuing mid-term student payments
August 20: Students upload code to the Google Summer of Code project repository; mentors begin final evaluations; students begin final program evaluations
August 31: Final evaluation deadline; Google begins issuing student and mentoring organization payments

Remember: This schedule is subject to change, latest and correct schedule can be found on the Google SOC 2007 Wiki

Eclipse Google Summer of Code

Program goals

The general goals of Google are recognized and extended with our own goals. In short, we want to improve the innovation within the project by offering students the opportunity to propose (research or enhancements) topics that are Eclipse related. Eclipse projects offers students an inspiring environment to do research, create proof-of-concepts or create working functionality. The students get well guided by field experts. We do not specifically target actual work for existing Eclipse projects (if it can be done in the Summer Of Code period this is perfectly ok), but we also want to support research, innovation and get students excited to build Eclipse-based software.

Here are some program goals defined below. Please bare in mind that this is an initial list of subjects we like to aim at, and in basic the final program content is open for discussion. It is important to understand that we need some guideline for project proposal evaluation, else we end up with all nice initiatives, but no choice between the individual project. In general we aim at the following type of projects:

1. Fixing important bugs and addressing important feature requests.
2. Adding new features to existsing projects.
3. Research oriented projects, like incorporating new technology in Eclipse.
4. Collaborative projects, to provide Eclipse-based support for other open source projects (like a studio for Joomla!), or integrating other open source services in Eclipse (like adding support for embedding Abiword in SWT)

Program organization

We strive for a shallow hierarchy (sic) for the Summer Of Code program. There will be a minimally formal program structure in place, but in general we like everyone to just do their job. For the mentors this means a big responsibility towards the students.

The total organization of the program will be done by the program leaders, one as main program leader (Philippe Ombredanne) and a second program leader (Wayne Beaton) to offer continuity when one of the two leaders is absent or on leave. The program team is completed with the team of mentors. For each accepted project there will be at least one mentor, depending on the subject there is no limit to the amount of mentors but we would like to limit to a maximum of two, else it is not clear to the student who is guiding him/her.

Mentor selection process

We can put together a real big questionnaire for the mentor selection...We like to make the selection process as easy as possible, we will describe the general "criteria" here:

A mentor needs to be familiar with Eclipse.
A mentor needs to be someone with experience in guiding people. You can have experience as a manager, project manager, a team coordinator, teacher or whatever. If this is the first time you are going to guide a student, help is available (see below).
A mentor needs to have knowledge about the topic he is going to mentor. If a student for instance wants to write an Eclipse plugin for Joomla!, the mentor should have decent knowledge of both Joomla! and Eclipse (just a fake example).
The mentor is responsible for guiding the student. This takes time, and with cultural and timezone differences this can be a real challenge! Last year, it took mentors about 1/2 day to a day a week over 3 months, and having less than one to two weeks of mentor time available for the program duration should be considered to be too low to be really successful. If you are not able to put this kind of time in being a mentor, don't even consider! There is nothing worse then a mentor dropping out in the middle of the program: it is bad for you, for Eclipse and the student, and will put a burden on the on the program management and the other mentors.

Conflict resolution and problem solving resolutions

It would be naive to assume that a group of people can work together in perfect harmony. There are going to be times when someone feels they have been wronged. In these times the following procedure should apply:

Talk privately to the person concerned.
If you still believe grievances exists, then bring in one or two other people to help mediate.
If this fails then try to address the issue to the program leaders.
The program leaders are infallible, so there should be no need for further escalation.

Team members are encouraged to self-mediate all disputes.

What to expect, and what do we expect from you?

What we expect is simple. Dedication, devotion, an open mind and above all patience and an understanding attitude with the students. They are actually here to learn, some even have never worked in a team before, or with Eclipse and don't know what a tracker or wiki is, explain and guide them. Communication wise, we prefer an information overload and over communication towards the the program management and the fellow mentors rather than to have to hunt you down for status and updated information needed to keep the program and community informed.

We also expect you to join the #eclipse-soc IRC channle on Freenode. Most of the communication and collaboration will take place there.

If you join as a mentor, what do you get in return? You can work in an open-source environment, meet great and inspiring people in a great open source project. It is all about sharing knowledge and work together to common goals. We will be there to support you also, like you do with students when you join.

Application selection

We have received close to 100 applications (101, but there are tow duplicates). Reviewing and ranking those application sis our first task. This is a delicate and work intensive process.
To support it we will come with tools (a good old spreadsheet) where you will be able to rank and comment on each student outside of the Google Soc web application. This application is not really easy to use when you need to handle 100 applications.

For now, you can feel free to provide constructive comments and feedback but should refrain to rank the application unless you requested ownership for it.

You will receivve additional instructions by email.

Communications

This is a very important aspect of the project. Communicating is all about sharing what you are doing, the challenges you meet and the problems you have solved. We expect the students to do a weekly report, and the task you perform is to communicate about the progression in relation to the planning the student makes. As a mentor you have the lead in addressing the time-zone, language and cultural barriers:

Time zones: Having team members in different time zones is one of the most frustrating and challenging aspects of being involved in a distributed team network. The worse combination is where certain members are separated by close to 12 hours. It is something you need to get used to and deal with. It typically requires you to plan to load the mailing list for questions that you know will be picked up in a few hours time by your team mates in another country. On the other hand it can be your ally, allowing a project to potentially have support around the clock. Please take care of yourself; it is very easy to be around hour after hour just to get in contact to those that are on the other side of the globe.
Language and Cultural Barriers: Projects will come up against differences in language and culture in either the user community or in the make up of your teams. There is no escaping it. When you are reading posts on a forum, submissions to a mailing list or even reading personal mail from another person who is not writing in their native tongue, you need to be sensitive to the fact that their translated dialog may not mean what they are trying to say. Sometimes you can unfairly brand a person as arrogant and rude because they have chosen forceful forms of words and phrases. Keep in mind it is generally not as bad as it sounds.

It also is import that we use the tools provided by this program, as a mentor you also have a leading role in "enforcing" the usage of tools. Tools are not targeted at communication, but using a compatible set of tools is more then advisable. In this section is a short list of some of the tools that are used within the Summer of Code.

Eclipse.org resources (wiki for all projects related documentation, Bugzilla for tracker and tasks).
Subversion or CVS for adequate source control (either at Eclipse, or Google).
Google Project Page (including wiki).
Mentor Application from Google
Eclipse forum (TBD) for general discussions
#eclipse-soc IRC channel for program discussions and weekly status meetings.

Guidance of your student

As you see on the time schedule, Google allows the student to familiarize with the project and tasks. You should prepare a kind of structure and document that can help both of you with topics like:

Planing of actions/tasks; make a planning including milestones up-front.
Communications such as status reports, achieved steps. Prepare the student to make a weekly report telling what was achieved last week, and what is planned for next week.
Time efforts and commitments. Students tend to under estimate the time and effort for certain tasks and you need to be prepared to cover those issues with some organizational help. Some of them might have different priorities e.g. exams, which might get in conflict of their plans. Being prepared from your side will help to make this project a success for you and your student.

Last Modified 3/27/07 6:46 PM

Hide Tools

Site
Changes
Index
Search

User
Log In
Register