Google Summer of Code. Information for GSoC Contributors

Jenkins GSoC

This page provides information for contributors about participating in Jenkins GSoC program. See the main GSoC project page for other information and links.

GSoC Contributor Application Process

First of all, take the time to read the Google Summer of Code Guide.

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.

Eligibility steps

You must verify that you are eligible to participate in the program. We cannot make any exception. Please:

  1. Make sure you are eligible to participate in the program

  2. If you are an accepted student in the United States of America on an F1 visa, you must obtain an authorization before you can participate.

Application steps

  1. Check out the GSoC 2022 Project ideas

  2. Select an interesting project idea or draft your own proposal.

  3. Use the project proposal template to write your project proposal.

  4. If you are not familiar with Jenkins, read the introductory info on the website and try using Jenkins with one of your previous projects.

  5. Join the Discourse communication channel

  6. Join the Jenkins GSoC Gitter Chat

  7. Using the Discourse channel or the Gitter chat:

    1. Introduce yourself to the Jenkins GSoC community,

    2. Start a discussion about a Jenkins GSoC project.

    3. Be patient, there are time zones, and mentors have full time jobs outside of the Jenkins community.

  8. Eventually, you may have to join both the Gitter chat and the Discourse channel, but initially you can reach us either way.

  9. Add GSoC office hours to your calendar (to be announced on the main GSoC project page).

  10. Recommended: Do some contributions in the area of your project idea

You can find more details about application steps below.

Expectations

When you apply to the GSoC program, you are committing to 30..40 hours of coding per week for the duration of the program.

  1. We expect contributors to get involved into project discussions at the beginning of the GSoC contributor application period in order to have the opportunity to discuss the project with potential mentors and to jointly review the proposal drafts.

  2. We expect contributors to attend at least one office hours during the application period.

Rules of Engagement

Communications are in English

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 contributors alike.

We encourage all contributors 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:

Communications are public

We expect almost all communications to be done in public.

Contributors 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 contributors inquiries when made in private. Contributors will get much better answers when they ask in public rather than in private, as mentors will collectively complement each other.

Contributors please note that mentors do not have "special information", or "privileged information" that they would reveal only to you privately. Contributors should not ask mentors to hide information from other contributors, 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, Discourse channel, office hours). Contributors are expected to find this information on their own using the search tools.

Contributor proposals are also public. Contributors might be afraid of another contributor 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.

GSoC Contributor Proposals

We expect proposals from contributors to contain all the sections discussed in the Google Summer of Code Guide, specifically the Elements of a Quality Proposal.

Contributors need to use the project proposal template to write their proposals. Contributor proposals should not be confused with project ideas.

We strongly encourage contributors 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 paragraphs if they are applicable:

  1. 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.

  2. An appendix section of detailed design, architecture or implementation. This section could contain code samples, pseudo-code, diagrams, mock UIs, etc.

  3. A section related to testing your project: unit tests, integration tests, test automation.

  4. A section or paragraph on deliverables: demos, presentations, releases (alpha, official).

  5. A section or paragraph on improvements, bug fixes, benefits to the community.

  6. Any other section that the contributor deems is applicable and helps the proposal

In the proposal, we also expect contributors to disclose all known commitments that overlap with any of the program phases (community bonding, coding periods, evaluation periods, etc.):

  1. Disclose your vacations periods, part-time or full-time job, school, classes, tests, exams, periods of non-availability, etc.

  2. Failure to disclose known commitments may lead to immediate failure, especially in the case of another jobs or internship.

  3. 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 Discourse channel is publicly visible inside and outside the community. It is required to use this channel for the initial review and feedback collection.

First begin a communication in Discourse

  • Please use the [GSOC 2022 PROPOSAL] Your Name and Project Title subject in discussion.

    • If another contributor is interested in the same project idea, you can contribute to their thread, or start your own thread.

  • Contents. In the first communication 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.

First contributions

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.

GSoC Contributor Selection Process

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 contributors 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.

Congratulations, you have been selected…​ or not

We thank all GSoc contributors 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.

Community Bonding

As soon as the GSoC contributors are accepted, the community bounding period starts. During this period, contributors 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:

  1. Define the communication channels with your mentors:

    • If it does not exist, setup a gitter chat room for your project.

  2. Setup the weekly meeting schedule with your mentors:

    • Two meetings per week is recommended,

    • Announce your meeting schedule to:

      • The Jenkins GSoC mailing list.

      • The gitter chat of your project.

      • Send a google calendar meeting invite to the mentors, CC the org admins.

  3. 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.

  4. 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 jenkinsci-dev@googlegroups.com mailing list or on the relevant SIG mailing list. Talk to the mentor about it.

  5. Setup your computer and your development environment to work on the project (see Useful links).

  6. Learn and discuss the process with the mentors:

    • Setup the github project,

    • Pull-requests,

    • Code reviews.

  7. We use Jira to track GSoC tasks:

    • Create an account using this link.

    • Become familiar with navigating Jira.

Coding periods

GSoC contributors are expected to…​

  1. Work on the GSoC project as it is a full-time employment.

    • It means 12 weeks of writing good code, about 20..30 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.

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

  3. 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

GSoC contributors are not expected to…​

  1. 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 contributors to achieve at least some goals in the original proposal

  2. 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

Evaluations

At the end of each coding period, GSoC contributors are expected to:

  1. Do a public on-line presentation,

    1. The presentation consists of Google Slides and a demo, on recorded broadcast.

    2. This event is recorded and made public.

    3. Prepare for this presentation approximately one week before the end of the coding period.

    4. Mentors will offer to do presentation dry-runs, if they forget, contributors should ask for it as needed.

  2. Publish a summary of your status and the next steps

    1. As a blog post published to:

      1. To the Jenkins website blogs (see adding a blog post)

      2. And announce the blog post on the Discourse channel.

As a part of the Final evaluation, contributors 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:

Code Style Best Practices

GSoC contributors 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:

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.

Getting in touch

Discourse Channel & Mailing List

Since the Jenkins community is distributed across all time zones, and since the gitter chat rooms are more difficult to search, we recommend using the Discourse channel for most of the communications.

Contributors should join the following Jenkins mailing lists:

  • https://community.jenkins.io - sync-ups on GSoC organizational topics (meeting scheduling, process Q&A).

  • jenkinsci-dev@googlegroups.com - for all technical discussions and the project application (archives).

    • Join this list after talking to the org admins and/or the project mentors, and once the project is ready to be discussed with the developers

Other mailing lists:

  • Org admins mailing list- for private communications with org admins (escalations, issues with mentors)

    • Please DO NOT use this mailing list for applications and intro emails

Chat

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.

Office hours

In addition to chat, Discourse 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.

Post-GSoC

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.

You can:

  1. Continue to develop your project within the Jenkins community

  2. Present your work at a local Jenkins Area Meetup

  3. Participate in other Jenkins projects

  4. Participate again next year

  5. Become a mentor in Google Summer of Code for next year

  6. Become a mentor in Google Code In

Depending on the project results, and available budget, we may offer a sponsored trip to DevOps World or another Jenkins-related event to contributors who successfully finish their projects. This sponsorship is not guaranteed though.

If contributors agree to go to such event, we expect contributors 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.

On this page

Connect