How to apply to GSoC

(Here is a link to the project list.)

Each year, the Checker Framework developers work with a small number of Google Summer of Code students who are paid to contribute to the Checker Framework. This document gives advice to make your application the best it can be. We look forward to your application!

The parts of your application

To apply, you will submit a single PDF through the Google Summer of Code website. This PDF should contain two main parts. We suggest that you number the parts and subparts to ensure that you don't forget anything, and to ensure that we don't overlook anything when reading your application. You might find it easiest to create multiple PDFs for the different parts, then concatenate them before uploading to the website, but how you create your proposal is entirely up to you.

  1. The proposal itself: what project you want to work on. You might propose to do a project listed on the "projects for new contributors" webpage, or you might propose a different project.

    The proposal should have a descriptive title, both in the PDF and in the GSoC submission system. Don't use a title like "Checker Proposal" or "Proposal for GSoC". Don't distract from content with gratuitous graphics.

    List the tasks or subparts that are required to complete your project. This may help you discover a part that you had forgotten. We do not require a detailed timeline, because you don't yet know enough to create one.

    If you want to do a case study, say what program you will do your case study on.

    If you want to create a new type system (whether one proposed on this webpage or one of your own devising), then your proposal should include the type system's user manual. You don't have to integrate it in the Checker Framework repository (in other words, use any word processor or text editor you want to create a PDF file you will submit), but you should describe your proposed checker's parts in precise English or simple formalisms, and you should follow the suggested structure.
    Warning: For GSoC students, the best projects are typically not in the "Create a new type system" category. The reason is that creating a new type system usually takes more time than one summer. It is better to succeed with a smaller task than to fail with a larger task. If you finish a smaller task quickly, then you can proceed to a more ambitious goal.

    If you want to do exactly a project listed on the "projects for new contributors" webpage, then just say that (but be specific about which one!), and the lack of further details will not hurt your chances of being selected. However, it can be helpful to show that you have thought about the problem, by adding details, discussing implementation strategies, or giving specific ideas about evaluation or extensions.

    Never literally cut-and-paste text that was not written by you without attribution, because that would be plagiarism. If you quote from text written by someone else, give proper credit. Don't submit a proposal that is just a rearrangement of text written by other people (for example, from the project ideas webpage or the Checker Framework manual), because that does not help us assess your likelihood of being successful.

  2. Your qualifications. Please convince us that you are likely to be successful in your proposed project.
    1. A URL that points to a code sample. Don't write any new code, but provide code you wrote in the past, such as for a class assignment or a project you have worked on outside class. It does not need to have anything to do with the Checker Framework project. It should be your own personal work. The code sample helps us assess your programming skills so we can assign you to an appropriate project. A common problem is submitting undocumented code; we expect every programmer to write documentation when working on the Checker Framework. Don't share a Google Drive folder containing multiple files; rather, provide a single .zip file or a GitHub URL. (The GitHub URL would be part of your single PDF document; a .zip file is allowed to be a separate upload.)
    2. What you have done to prepare yourself for working with the Checker Framework during the summer. You may wish to structure this as a list. Examples of items in the list could include:
      • Code you have annotated as a case study. Please indicate the original unannotated code (as a URL or a .zip file), the annotated code (as a URL or a .zip file), and the exact command to run the type-checker from the command line. Ensure that the GSoC mentors can compile your code. (It is acceptable to use the same code, or different code, for this item and the code sample above.)

        You should have shared the case study as soon as you finished it or as soon as you had a question that is not answered in the manual; don't wait until you submit your proposal, because that does not give us a chance to help you with feedback.

      • URLs for bugs or pull requests that you have filed. These can be related to any project, not only the Checker Framework.
      • Information about other projects you have done, or classes you have taken, that prepare you for your proposed summer task. This is optional. If something already appears in your resume, don't repeat it here; we will see it in your resume.
    3. A resume. A resume contains a brief description of your skills and your job or project experience. It will often list classes you have taken so far and your GPA. It should not be longer than one page.
    4. An unofficial transcript or grade report (don't spend money for an official one), if you are a student.

Advice

The best way to impress us is by doing a thoughtful job in the case study. The case study is even more important than the proposal text, because it shows us your abilities. The case study may result in you submitting issues against the issue tracker of the program you are annotating or of the Checker Framework. Pull requests against the Checker Framework GitHub project are a plus but are not required: good submitted bugs are just as valuable as bug fixes! You can also make a good impression by correctly answering questions from other students on the GSoC mailing list.

Some GSoC organizations have a requirement to fix an issue in the issue tracker or open a pull request. The Checker Framework does not have that requirement. For us, a pull request is a plus, but it is not necessary. It can be unproductive to try to fix an issue before you understand the Checker Framework from the user point of view. Understanding the Checker Framework requires using it, for example by doing a case study on an open-source program.

Get feedback

We want your application to be competitive, and we want you to succeed. We encourage you to ask us for feedback and other help. Historically, students who start early and get feedback are most successful.

For discussions related to GSoC, please send mail to checker-framework-gsoc@googlegroups.com.

Please do not violate the guidelines in How to get help and ask questions. If you violate them, you are disqualified from participating in GSoC, because it shows that you do not read instructions, and you haven't thought about the problem nor tried to solve it.

You can submit a draft proposal via the Google Summer of Code website, and we will review it. We do not receive any notification when you submit a draft proposal, so if you want feedback, please tell us that. Also, we can only see draft proposals. If you submit a final proposal, we cannot see it until after the application deadline has passed.