Google Summer of Code. Information for mentors

Expectation: it is the time you spend reading about the program (2 to 3 hours) and the time you wish to spend submitting project ideas (maybe 3 to 5 hours per project idea).

When you get the call for mentors announcement towards the end of December or beginning of January, it is time to think about joining the Jenkins GSoC program as a mentor. During this phase, the mentor responsibilities are:

You can also:

Optionally, you can:

The important aspect of this phase is to produce a list of good project ideas, as this is key to be accepted in the GSoC program.

The deadline for producing this list is indicated on the Official GSoC timeline.

Jenkins GSoC Org Admins are responsible for submitting the application form for the Jenkins organization.

Expectation: 2 to 3 hours per week until organizations are announced.

During this period, we wait for Google to approve our application request.

Mentors should keep interacting with students during this period.

Google publishes the list of accepted organizations according to the Official GSoC timeline. If we are accepted, we move on to the next phase.

Expectation: a few hours before the Proposal ranking and slot request phase.

We want mentors to form mentor teams of at least 2 or 3 mentors and to co-mentor projects together. Please spend a few hours forming your mentor team as soon as possible but no later than the start of the Proposal ranking and slot request phase.

If you do not have enough potential mentors for a project, do spend a few hours looking for co-mentors (mailing list, chat room, social media, etc.) and contact them. You should also setup introduction audio or video conference with them, and you should invite them to the office hours meeting. It is good to discuss your mutual interests (why you are interested in the same projects, your respective backgrounds in open source, etc.) and your respective availabilities during the program.

Mentors must make sure they get invited by org admins, and must make sure to respond to that invitation by the time the Proposal ranking and slot request phase phase begins.

All mentors work with the student during all phases on the program, answering the student questions, coaching, advising, motivating, unblocking, reviewing code and pull-requests, ensuring the process is followed, ensuring communications are in public as this is an open source program, and report issues to the lead mentor, etc.

Expectation: about 2 to 5 hours per week (more if you submit your own project ideas which we encourage highly) until the student application phase ends.

Officially, this phase is divided in two:

During this long phase, mentors are expected to actively interact and discuss with students on projects they wish to mentor. This means that you need to:

You can still submit new project ideas during this phase.

This is a very important phase, use it to get to know the students who apply to projects that are of interest to you.

For this deadline, please see the Official GSoC timeline.

Expectation: about 5 hours total, plus continuous interaction with potential students, until the community bonding starts.

This phase is divided in two sub-phases:

Mentor teams are formalized during this phase, and mentors must be registered with the GSoC website. For details on forming mentor teams, see Mentors and mentor teams.

Student proposals are ranked for slot requests, and a final selection is made.

Note that we are NOT allowed to communicate any information regarding the selection to students during this phase until Google makes the official Student Project Announcements. We do not make this announcement, Google does.

This only usually lasts a few days.

We wait. We are NOT allowed to communicate any information regarding the selection to students.

Expectation: about 5 to 8 hours per week, until coding starts.

This is the most critical phase when it comes to working with your student. Year after year, if this phase goes well, the rest of the program usually goes well, but if this phase does not go well, the project usually fails.

Mentors are expected to:

We have written a guide for this phase, read it and follow it.

In rare cases, it is acceptable to re-work the project idea, even change it completely, as long as the student and the mentors all agree. Written documentation about this is essential, if it happens, let the Org Admins know.

Let Jenkins Org Admins know as soon as possible if there is any need for knowledge transfer sessions. We often organize special public presentations to go over plugin and core development flows and code that students and mentors alike benefit from attending.

Expectation: about 5 to 8 hours per week until the end of the program.

See also: student coding periods.

You are mentoring now. Guide, coach, review pull-requests, unblock the student, ensure students use Jira for task, bug and feature tracking, meet your student at least once or twice per week over a live one-on-one session (video conferencing and screen sharing is infinitely useful here).

What if the student is done early? Student and mentor must determine other work that can be done and let the Jenkins Org Admins know.

Expectation: same as during the coding periods.

See also: student evaluations.

Mentors are expected to evaluate their student, while they continue to mentor them. Coding seldom completely stops during this period.

Mentors are expected to: * ensure that the student creates a presentation and prepares a demo * ensure their student presents their project (presentation and demo) at a public meeting in the style of an on-line meetup. We record these presentations and publish them on YouTube. * evaluate their student by comparing the student project plan with the actual code produced. There is usually great flexibility as we allow mentors and students to agree on what the expectations are in terms of features and content. * fill in the GSoC evaluation form and provide written feedback in that form to their student and to the Google GSoC organization.

This period is a good time to review the Jira tickets and prepare the tickets for the next coding phase.

If too little code is produced for reasons that cannot be understood, inform your student of your concerns, and ask the student why this is happening. Often students are blocked on a technical problem and do not communicate with their mentors. As a rule of thumb, there should be code pushed to Github almost every day. If not, let the Org Admins know as soon as possible.

Many students ask their mentors how they can continue to contribute after the program.

You could setup one-on-one on-line meeting with the student on a monthly basis. You can invite the student to SIG or other community meetings. Jenkins also has on-line meetups with various people presenting that the student might be interested in joining.

Usually, you can invite the student to look at the bugs and features that have been captured in Jira during the coding phases for inspiration on what to do next. You can also invite students to apply next year as a student or even as a mentor. Students like to see their projects continue, and becoming a mentor is a great way to make that happen.

Google organizes a mentor summit a few months after the program has ended. Each year, the Jenkins Org Admins select 2 mentors who get to go to that summit (travel costs and accommodations are paid for by Google). Mentors agree that this is a fantastic event!

Some mentors travel to the Jenkins World conference and get to meet students and other mentors. This is definitely a conference worth attending for mentors and students alike.

Here are some posts by mentors from past years conferences: