This page aggregates links to internal and external resources for Google Summer of Code mentors. Student resources can be found here.
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
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.
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 in the Jenkins community. GSoC org admins will help to find advisers if any 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.
We have divided what mentors should expect in different phases. Always refer to the Official GSoC Timeline for the official timeline, phases and their duration. As soon as you become a registered mentor, you will receive via email all timeline updates and reminders.
Overall for mentors the time commitment is (for details of activities see below):
Call for mentors and organization application phase: 2 to 3 hours per week
Organization approval waiting period: 2 to 3 hours per week
Mentors and mentor teams: a few hours
Student exploration and application phase: 2 to 5 hours per week until the student proposal submission deadline
Proposal ranking and slot request phase: about 5 hours total until the slot request submission deadline, but because this phase is time critical and short, we insist that you make an extra effort to attend meetings and participate actively in this process (see below for details).
Community Bonding: 5 to 8 hours per week, this phase is critical for the success of the project, make sure you get on the ball right away.
Coding Periods: 5 to 8 hours per week until the end of the program. The number of hours tend to vary, more at the start, less at the end, not everyone is the same.
Evaluation periods: Same as coding.
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 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:
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 determine 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 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:
Initial proposal ranking and slot request sub-phase: usually 2 to 3 weeks (not very long)
Final proposal selection sub-phase: usually 1 week (very short!)
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.
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 three 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.
This phase is very short and starts immediately when Google sends us our final number of slots.
We may get only the minimum of slots. Sometimes heart wrenching decisions need to be made.
Org Admins and Mentors need to make an extra effort to devote time to this phase because it is very short and this does not leave us much time to make critical decisions, and it just as important as the other phases.
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.
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:
Send a welcome message to their student within 24 hours after the projects are announced (GSoC timeline)
Organize your first meeting with the student, within the first week. Bring as many contributors as possible there, and make sure to celebrate and to discuss the next steps.
Set the pace, establish your regular meeting times together.
Agree on the main communication channels (chats or mailing lists). GSoC org admins can help you to create communication channels if needed
Help the student to do first contributions to the project if it has not happened before. Newbie-friendly issues might be a good start. Get them merged and released as soon as possible
Make sure the student has a detailed plan and a design document for the first coding phase before it starts
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.
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:
GSoC 2019 Report, multiple authors
Google Summer of Code with the Jenkins Project, by Jeff Pearce
Google Summer of Code Mentor Summit 2018, by Martin d’Anjou
Google Summer of Code Mentor and Org Admin Perspective, by Marky Jackson
Jenkins World Contributor Summit and Ask the Expert booth, by Marky Jackson
Jenkins in Google summer of Code 2018 Results by Oleg Nenashev
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 reasons 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.
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 the umbrella of the Linux Foundation, subject to US and international law. 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.