This page provides information for students about participating in Jenkins GSoC program. See the main GSoC project page for other information and links.
First or all, take the time to read the Google Summer of Code Guides.
Also bookmark the timeline. Print it and hang it where you can see it every day!
The aforementioned documents are the reference and the inspiration for this document.
You must verify that you are eligible to participate in the program. We cannot make any exception. Please:
Check out the GSoC 2019 Project ideas
Select an interesting project idea or draft your own proposal.
If you are not familiar with Jenkins, read the introductory info on the website and try using Jenkins with one of your previous projects.
Join the firstname.lastname@example.org mailing list (archives).
Join the Jenkins GSoC Gitter Chat
Using the mailing list or the Gitter chat:
Introduce yourself to the Jenkins GSoC community,
Start a discussion about a Jenkins GSoC project.
Be patient, there are time zones, and mentors have full time jobs outside of the Jenkins community.
Eventually, you may have to join both the Gitter chat and the mailing list, but initially you can reach us either way.
Add GSoC office hours to your calendar (to be announced on the main GSoC project page).
Recommended: Do some contributions in the area of your project idea
You can find more details about application steps below.
When you apply to the GSoC program, you are committing to 30..40 hours of coding per week for the duration of the program.
We expect students to get involved into project discussions at the beginning of the student application period in order to have the opportunity to discuss the project with potential mentors and to jointly review the proposal drafts.
We expect students to attend at least one office hours during the application period.
The official communication language is English, and English is a second language to most of us. Learning proper English grammar is key to good communications. This is a challenge for mentors and students alike.
We encourage all students to spend some time improving their knowledge of the English language to increase their chances of success in open source. There are many good videos on youtube that can help you improve written and spoken English.
Remember that the goal when communicating is to be understood. Frequent grammar mistakes include run-on sentences (they are confusing), sentence fragments (they are incomplete), or miss constructing clauses and phrases (confusing).
It is always good to start at the basics, that is how to write a sentence, and how to write a paragraph.
The following links are suggestions to help you improve your communication skills:
We expect almost all communications to be done in public.
Students and mentors do not communicate privately regarding the technical aspects of the project or the GSoC program. Mentors are not expected to respond to such students inquiries when made in private. Students will get much better answers when they ask in public rather than in private, as mentors will collectively complement each other.
Students please note that mentors do not have "special information", or "privileged information" that they would reveal only to you privately. Students should not ask mentors to hide information from other students, this is simply not how open-source development works. In open-source development, all ideas are presented and debated publicly. All the information we have is in the project ideas, or is shared on the public channels (for example gitter, mailing list, office hours). Students are expected to find this information on their own using the search tools.
Student proposals are also public. Students might be afraid of another student copying their proposal or stealing their ideas, but there is nothing to fear. First, mentors can easily tell when ideas and proposals have been copied. Second, Jenkins is a community driven open source development organization, where all proposals and ideas are debated in public and are visible to the entire community. There is always a public debate on ideas and proposals.
We strongly encourage students to engage with the mentors as early as possible. If you wait until the last few days to submit a proposal, mentors will not have time to discuss with you, and your chances of being accepted are greatly diminished.
You can have additional sections or paragraph if they are applicable:
A contribution history section: if you participated in any open-source projects or proposed any patches in Jenkins, you can definitely list them in this section.
An appendix section of detailed design, architecture or implementation. This section could contain code samples, pseudo-code, diagrams, mock UIs, etc.
A section related to testing your project: unit tests, integration tests, test automation.
A section or paragraph on deliverables: demos, presentations, releases (alpha, official).
A section or paragraph on improvements, bug fixes, benefits to the community.
Any other section that the student deems is applicable and helps the proposal
In the proposal, we also expect students to disclose all known commitments that overlap with any of the program phases (community bonding, coding periods, evaluation periods, etc.):
Disclose your vacations periods, part-time or full-time job, school, classes, tests, exams, periods of non-availability, etc.
Failure to disclose known commitments may lead to immediate failure, especially in the case of another jobs or internship.
Unexpected events: we understand there can be unexpected events in life, and those cannot be planned. Please inform us as soon as possible if you need time away from the program. You can use private messaging for sensitive information.
|Please note that the mailing list is publicly visible inside and outside the community. It is required to join the mailing list for the initial review and feedback collection.|
Selecting a thread subject
Please use the [PROJECT_NAME] prefix in your email thread subjects.
Creating personal intro thread is also fine.
Contents. In the first e-mail we would be interested to see the following information:
A short self-introduction: your area of study, interests, background
Motivation letter. Why are you interested in the Jenkins project? Which projects ideas do you want to work on?
If you participate in open-source projects, please reference them
If you have a GitHub, Twitter account, a blog or technical/scientific publications, please reference them as well
|In GSoC we do not hire you in the common sense. Please DO NOT send us your CVs/resumes or universal cover letters. We are mostly interested to understand your interests and your motivation to work in the project.|
We highly recommend to make some contributions to the project while you work on the application. It will help you to polish the proposal, and mentors will consider contributions and interactions with the community when processing applications.
Here are a list of links to help you get started on participating in Jenkins and in coding for the Jenkins project, in increasing level of difficulty.
There is also a list of newbie-friendly issues.
Feel free to contact potential mentors and org admins if you need help with choosing a newbie friendly issue to tackle. See the contact links in project proposals.
Once the application period is over, administrators and mentors make a decision on which proposal to accept based on the proposal submitted to the Google Summer of Code website. Only proposals submitted before the deadline to the Google Summer of Code website are considered.
We understand students are anxious to know whether they are selected or not, but admins and mentors are bound to secrecy until Google announces the selection results. We will not discuss the selection with students until Google makes the announcement.
We thank all students who reach out to us during the application period. If you have not been selected read this, there could be many reasons, and some are even outside of our control. Do not feel bad, we encourage you to stay with the community, and apply again next year.
If you have been selected, the community bonding period starts within two days after the announcement.
As soon as the students are accepted, the community bounding period starts. During this period, students are not expected to be coding immediately. Instead they are expected to prepare to code.
A successful community bonding usually leads to successful coding periods. It is our experience that poor community bonding leads to difficult coding periods.
Use the community bonding to:
Define the communication channels with your mentors:
If it does not exist, setup a gitter chat room for your project.
Setup the weekly meeting schedule with your mentors:
Two meetings per week is recommended,
Announce your meeting schedule to:
The gitter chat of your project.
Send a google calendar meeting invite to the mentors, CC the org admins.
Get introduced to the key stakeholders and contributors in the area of the project by your mentors:
For example, an introduction to subject matter experts.
Continue to discuss and plan the project with the community and the mentors:
Work on the design document of the project.
Work on clarifying objectives and expectations,
Study, refine and discuss the design and the project plan,
Top-level architecture document:
Create diagrams of operation,
Answer questions such as "How is the user going to use this?", "What configurations are needed?", etc.,
Some people find it useful to write a mini user guide or how-to guide, as if the project was already done. This usually helps define the project.,
Create an implementation plan with milestones per coding period.
At this point it may be appropriate to discuss the project on the email@example.com mailing list or on the relevant SIG mailing list. Talk to the mentor about it.
Setup your computer and your development environment to work on the project (see Useful links).
Learn and discuss the process with the mentors:
Setup the github project,
We use Jira to track GSoC tasks:
Create an account using this link.
Become familiar with navigating Jira.
Students are expected to…
Work on the GSoC project as it is a full-time employment.
It means that 30..40 hours per week is an expected workload though it can be adjusted upon the agreements with mentors.
Push code to github almost every day of every coding period.
Follow the Code Style Best Practices
Chat a line or two about what you are doing, almost every coding day, in your project channel (writing code, writing tests, updating documentation, etc.).
Just saying "Hi, today I am working on these classes" or "writing tests for …" is good enough, but you can of course interact more as needed.
Write a short summary of the work done each week, published to:
A personal blog, or
The relevant SIG mailing list, or
A paragraph or two should be enough.
It’s okay to say things like <this> and <that> were challenging because of <reason>.
Interact with the community in a timely fashion when you need help (do not stay stuck without telling mentors).
Say something when you are stuck, lost in the code, confused about the objectives, etc.
Produce good quality code with reasonable amount of testing and documentation.
Follow the Code Style Guidelines
Have a finalized deliverable at the end of the project.
For plugin development projects, this means releasing a plugin to the alpha or to the official update center.
Have documentation on how to use the plugin of the features developed during the project.
Take Time off
You have approximately 5 "vacation days" during the project, do not hesitate to use them if required.
Notify your mentors in advance when you take time off.
Use weekends to have a rest, avoid significant overwork and enjoy coding
Timely notify mentors in the case of emergencies and outages (missing scheduled meetings, etc.).
Timely notify mentors and org admins about unexpected time commitments (life goes on, it is normal - mentors will let you know if they can’t be reached too).
Be present on-line
Be around in the project chats during the working hours (the Jenkins GSoC Gitter Chat, and the Gitter Chat of your project)
Be proactive; reach out to the community if required
Optional: Attend Jenkins governance meetings if the timezone allows
Students are not expected to…
Strictly follow the originally submitted mini-design and the project proposal
The world is not ideal, and there may be unexpected obstacles or shortcuts
Upon the discussion with mentors, any plan can be adjusted
We expect students to achieve at least some goals in the original proposal
Investigate and solve every issue on your own
We have mentors and experts, who can help you by answering questions and doing joint investigation if required
At the end of each coding period, students are expected to:
Do a public on-line presentation,
The presentation consists of Google Slides and a demo, on recorded broadcast.
This event is recorded and made public.
Prepare for this presentation approximately one week before the end of the coding period.
Mentors will offer to do presentation dry-runs, if they forget, students should ask for it as needed.
Publish a summary of your status and the next steps
As a part of the Final evaluation, students present the project results at the Jenkins Online Meetup
|The secret to making excellent presentations is to be ready ahead of time, and practice, practice, practice. Write a script, and practice out loud, exaggerate enunciation when you practice, and put on a little smile to lift your voice just enough. If you create a slide or two per week on the work you have done that week, you will be ready. Repeating a presentation numerous times will help you breeze through it with fluidity.|
Past years presentations and blog posts may inspire you. Here are some links:
Students should adopt best practices as soon as possible in their coding career. Learn to configure your IDE to have proper spacing and proper indentation is a must. By default, the IDE you use may not have the correct settings.
Best practices include topics such as space and indentation, naming conventions for variables, class members, methods, classes. These are all important when writing code.
The best practices can be learned:
From the Code Style Guidelines
By reading existing code
By asking mentors or submit a pull-request and ask for review
By reading code style guidelines of other organizations found on the internet. Here are some popular ones:
Documenting code with Javadoc can be learned by imitation, but it is better to read the reference: it’s here.
When it comes to testing, Jenkins projects must come with:
If your project is a plugin and you are ready to release it, you also need to learn the plugin release process.
Since the Jenkins community is distributed across all time zones, and since the gitter chat rooms are more difficult to search, we recommend using mailing lists for the most of communications.
Students must join the Jenkins GSoC mailing list:
firstname.lastname@example.org - sync-ups on organizational topics (meeting scheduling, process Q&A) (archives).
After talking to the org admins and/or the project mentors, and once the project is ready to be discussed with the developers, the student should join the developer mailing list:
email@example.com - for all technical discussions and the project application (archives).
firstname.lastname@example.org - for private communications with org admins (escalations, issues with mentors)
Please DO NOT use this mailing list for applications and intro emails
We use the Jenkins GSoC Gitter Chat for office hours and real-time discussions. Note that mentors and org-admins may be unavailable in the chat outside the Office Hours slots (see below).
Once the projects are announced, mentors and students may switch to another communication channel.
In addition to chat and mailing lists, we have regular office hours for sync-ups between students, org admins and mentors.
See the main GSoC page for the schedule.
Congratulations, you have made it to the end!
Once GSoC is over, final results are announced by Google. But this is not the end of the road.
Depending on the project results, and available budget, we may offer a sponsored trip to DevOps World - Jenkins World or another Jenkins-related event to students who successfully finish their projects. This sponsorship is not guaranteed though.
If students agree to go to such event, we expect students to present their project and to write a blog-post about the trip. In 2018, one of our students, Pham Vu Tuan, attended DevOps World - Jenkins World, and wrote this blog post about it.