Google Summer of Code. Information for mentors

Jenkins GSoC

This page aggregates links to internal and external resources for Google Summer of Code mentors. Student resources can be found here.

What do mentors get?

  • A student who works full-time in the area of your interest for several months

  • Joint projects with Jenkins experts, lots of fun and ability to study something together

  • Limited-edition of swags from Google and Jenkins project

  • Maybe: Participation in GSoC Mentor Summit and other GSoC events/meetups

How to become a mentor?

During GSoC you can join an existing project at any time, including community bonding and coding periods. Just send an email to our GSoC mailing list. You can also propose your own project for GSoC, see below.

Expectations from mentors

Mentors are expected to…​

  • Be passionate about Jenkins

  • Lead the project in the area of their interest

  • Actively participate in the project during student selection, community bonding and coding phases (March - August)

  • Work in teams of 2+ mentors per 1 each student

  • Dedicate a consistent and significant amount of time, especially during the coding phase (~5 hours per week in a team of two mentors)

  • We recommend to keep the communications with the students in the open, no private emails unless it is a personal matter

    • Use the existing mailing list and channels of the community

    • If you need a new communication channel (new chat room or other) let the Org Admins know

    • It’s okay to initiate conversations and introductions in private, but:

      • Make sure the information given to the student is also available in public

      • Make sure that no student is put at an advantage by seeing answers not seen by other students

      • You could create a Q&A in the project description details where questions are anonymized

Mentoring does NOT require strong expertise in Jenkins plugin development. The main objective is to guide students and to get them involved into the Jenkins community. GSoC org admins will help to find advisers if a special expertise is needed.

GSoC is an international program. Some events and deadlines in the timeline may coincide with holidays and celebrations around the world. Although we do our best to accommodate everyone, it is impossible to change the GSoC timeline. Please communicate your holidays to Org Admins, your co-mentors and your student as soon as possible.

Expectations from mentors per phase

We have divided what mentors should expect in the different phases.

Overall for mentors the time commitment is (for details of activities see below):

Call for mentors and organization application phase

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:

  • Read this document and the related links

  • Reach out to the Jenkins GSoC community in the gitter chat

  • Add your name as potential mentor to the project ideas you wish to mentor (in pull-requests)

  • Propose new project idea(s)

You can also:

  • Engage with prospective students in Gitter and the mailing lists

  • Encourage students to study code and send newbie friendly pull-requests

  • Ensure the project ideas you are interested in are discussed in the community with subject matter experts and potential users

Optionally, you can:

  • Recruit additional mentors for projects (if possible)

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 timeline).

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

Organization approval waiting period

This phase lasts 2 weeks.

Expectation: 2 to 3 hours per week.

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 timeline). If we are accepted, we move on to the next phase.

Student exploration and application phase

This phase lasts 5.5 weeks.

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

Officially, this phase is divided in two:

  • Students explore and discuss projects and project ideas

  • Students formally apply to GSoC with Google

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:

  • answer questions from students and clarify the project’s detailed objectives with them

  • help the student prepare a high quality proposal

  • review the student pull-request(s) if any (some students send fixes for small issues during this phase to get familiar with the process)

  • find out who else is interested in the same project as you (your co-mentors)

    • of course we appreciate if you help us find more mentors if you can

  • participate in the weekly public meeting

  • make sure the students follow the process and that their application meets the requirements in the template

    • make sure the students determines whether they are eligible

  • if the student proposes a genuine project idea in your area of interest or expertise, make sure it is presented and discussed in the community

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 timeline).

Slot request and selection phase

This phase lasts 3 weeks.

Expectation: about 5 hours total.

This phase is divided in two sub-phases:

Mentor team are formed during this phase, 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.

Regarding forming mentor teams

In the Jenkins Org, we have the concepts of lead mentor and co-mentors.

The lead mentor has the responsibilities of a co-mentor, and is also primarily responsible for the administrative duties (fill in the evaluation documents, ensuring representation at meetings, and report issues to the Org Admin team).

The co-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.

Subject matter experts and active community contributors also participate in GSoC but not in official mentor roles.

Regarding the slot request sub-phase

This sub-phase lasts 2 weeks.

The goal of this phase is to determine and request the minimum and the maximum number of projects we can take on as an organization. This process is explained in the Mentor Guide in the Slot Count section.

We have two weeks to send our slot request to Google. It is an intense and critical period for Org Admins and mentors, as this determines who participates in the rest of the program!

During this phase, mentors and org admins need to rank the projects. Fake and incomplete proposals are discarded. Good proposals are ranked in order of chances of success. Here we look for quality, completeness and compliance of the student applications and our capacity to mentor. We usually get more projects than we can mentor, so we must make a selection.

Regarding our capacity to mentor a project, it is critical at this phase that mentors register their name in the Google GSoC system and assign themselves to all the projects they would like to mentor (as if they had infinite time).

When we rank projects, we make sure mentors only get the number of projects they want (usually one or two) regardless of how many projects the mentor registers for. We also ask mentors to rank the projects they’d like to mentor in order of their preference. Org Admins make sure there is at least TWO mentors per project. The Org Admins help organize mentor teams and projects are ranked in a manner that tries to maximize success and happiness for everyone.

Note that we allow mentors to participate in more than one project only if the mentor agrees with it. We do not recommend taking on more than two projects. You can still contribute in the Jenkins project while you mentor in GSoC.

This all sounds complicated, but long story short, this phase is when the match making process formally happens between mentors, students and projects.

The max number should never exceed our total mentoring capacity. The min number is the quantity of projects we feel confident we can mentor and succeed. For example We can feel very confident about 5 projects, and reasonably about 2 projects, and not enough confident about the rest. Then our min and max would be 5 and 7.

Then we send our slot request min and max numbers to Google.

Final selection phase

This phase lasts one week.

This phase start immediately when Google sends us our final number of slots. We may get only the minimum. Sometimes heart wrenching decisions need to be made at this time.

During this phase, mentors and Jenkins Org Admins hold a private meeting to make the final project selection and the mentor teams are finalized and confirmed. Then we submit our final selection to the GSoC program.

Final selection awaiting period

This phase lasts a few days.

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

Community Bonding

This phase lasts 3 weeks.

Expectation: about 5 to 8 hours per week.

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: * Do not delay, start this phase immediately * Organize your first official meeting with the student, within the first week. * Set the pace, establish your regular meeting times together. * Firm up on the main communication channels. * Make sure the student works on a detailed plan and one a design document * Get the student to create issues in Jira for the work items of the coming coding phase

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.

Coding Periods

Expectation: about 5 to 8 hours per week.

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.

Evaluation periods

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 presentation 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 mentor and student to agree on what the expectation 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.

After the program

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 the SIG meetings 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 project 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:

Regarding mentor time off

The GSoC program lasts several months. We know people go on vacation and need to take time off from their regular day job. We are flexible. This is one of the reason why we also assign at least two mentors per student. Make sure you timely communicate your availability to your student, your co-mentors, and the org admins.

If you must withdraw from the program completely, let the Jenkins Org Admins know as soon as possible. Life happens, but we need to know about unplanned changes so that we can ensure continuity of the ongoing GSoC projects.

Conflict of interest prevention

We appreciate mentorship provided by any Jenkins contributor. On the other hand, we want to avoid any conflicts with GSoC rules and spirit. We also want to avoid conflicts of interest between all sides.

  • Only an individual contributor may be a mentor according to GSoC rules. One or more company representatives may act as individual contributors

  • All mentors and org admins are considered as Jenkins community representatives. They must follow the Code of Conduct

  • If a mentor works for a company, which use Jenkins in commercial products…​

    • The mentorship work should be performed during spare time or during the OSS contribution time dedicated by the company. In the latter case the mentor should ensure that there will be a consistent time dedicated over the entire GSoC mentorship period

    • The project proposed by mentors should not overlap neither with direct responsibilities within the company nor with the company product roadmaps.

    • He/She should ensure there is no conflict of interest between the project and the work responsibilities

There are several examples below:

  • "I would like to have this feature in my Jenkins installation. I have already made a commitment to deliver within my company. I will lose my bonus if I fail the commitment"

    • NOT FINE, you have a conflict of interest. GSoC project may fail due to many reasons

  • "I would like to have this feature in my Jenkins installation. It would provide us some added value, but we can live without it. I have not made any commitments"

    • FINE if the proposed project is useful to a significant part of the community. Added value will keep you motivated

  • "This feature has been already announced publicly by my company, we want to ship it as a part of our product"

    • NOT FINE, you have a conflict of interest

  • "This feature has not been announced publicly by my company, but we will do it after GSoC"

    • NOT FINE, you have a conflict of interest

  • "Our product may benefit from the feature, but it’s not in our roadmaps. The project idea is useful to the community"

    • PROBABLY FINE, consult with GSoC Org Admins

  • "I want to mentor this feature, but I see that somebody works on the similar feature in open-source"

    • PROBABLY FINE, consult with the developers of the competing solution. Try to join forces and get them as mentors.

  • "I want to mentor this project, but I see that another company provides a similar closed-source solution"

    • FINE, but ask GSoC Org Admins to contact the company. Maybe they agree to open-source it (and to assign a mentor). If no, it’s their problem.

  • "I want to implement a feature based on a patented algorithm/technology. It’s open-source, so we are free to do whatever"

    • NOT FINE, Jenkins project recognizes laws. We are under umbrella of Software In Public Interest organization, which is a subject for US and international legislation. Contact the patent holder to get a license (needs a review by Jenkins Governance meeting).

  • "I went through the list and still have concerns"

    • PROBABLY FINE, contact GSoC Org Admins

All potential issues should be escalated to GSoC admins. Intentional violation of the rules above may be a subject for Code of Conduct violation process.

On this page

Connect