June 9, 2017

Google Summer of Code: the Application

I recently received news that my Google Summer of Code 2017 proposal has been accepted. So I thought I should write a series of posts as this summer passes to chronicle my experience with the program. This first post is an outline of the process I followed in creating a successful proposal; I hope future applicants - or those just curious - find these tips helpful.

My project this summer will be to develop a content management and presentation suite utilizing Physical Web technology. The novel concept behind the Physical Web project is to utilize web Bluetooth to allow interactions with inexpensive physical beacons from the browser - in other words, IOT without the hassle of apps. My task is to develop an Android app (and an accompanying web app) to enable exhibitors, museums and the like to organize galleries that use these beacons. Visitors will then receive a notification when they unlock their phones, which will lead them to the webapp that displays media relevant to the exhibit piece they are looking at. Find the official description here. You can find the final text of my proposal here.

Before we get any further, I would like to extend my thanks to Andreu Ibáñez and Julio Bondia (from the Physical Web team) for their thorough proposal feedback and their patience with my questions. None of this would have been possible without their help!

Checklist for Applicants

  • Choose selectively and early
    • This year, 201 organizations participated in GSoC. Starting out, the sheer number of possibilities is overwhelming — make sure you have enough time to browse through all the organizations that interest you and decide.
    • Google allows you to apply to up to 5 organizations. However, I strongly suggest that you apply to one, or at most two organizations. There are many applicants for GSoC, so the key to standing out to an organization is a high quality proposal. Five ordinary proposals are likely to get lost in noise. Personally, I only wrote one proposal.
  • Get feedback early and often
    • This step is not optional. It is my firm believe that it is almost impossible to get accepted in GSoC if you have not had at least one round of feedback. Feedback allows you to address issues before your proposal is more strictly reviewed.
    • Communicating with the community also helps you understand the expectations in term of work quality, application tone, etc.
    • I think a key reason my proposal was successful was the ~1000 words of feedback exchanged between me and the organization members over the course of a week or so.
  • Set concrete deliverables
    • Outline a set of measurable goals for your proposal, so that what you want accomplish is clear. For example: Using the Google Drive API, the Android app will allow the user to authorize their Google account so the app can upload content.”
    • It might be helpful to have two separate lists, one for technical/code deliverables and one for non-technical deliverables, like documentation or tutorials
  • Polish your proposal
    • Participating organizations and the Google team will spend time combing through your proposal. Show them that you respect their time by writing clearly and professionally.
    • You can test clarity by asking someone technically inclined to read your proposal and explain it back to you. Rewrite the parts they get wrong.
    • Have others proofread your proposal. Here you’ll want someone who’s good with English, technical understanding isn’t necessary. Many universities will have a writing center which can help you.
  • Highlight your experience - or create experience
    • Prove to the reviewing team that you can accomplish the deliverables you set out in step three.
    • Linking to open source code is the best way to do this. For example, in the deliverable above I mentioned using the Google Drive API. To prove I can do this, I linked to some toy Python code I wrote a while ago that used the Drive API.
    • Another good way to do this is find the issue tracker the organization uses and fix some small bugs listed there. Mention this in your application.
    • Some organizations will have a coding test. Mine did: here is the prompt, and you can find my solution here. Note how the code is both documented and has tests implemented.
  • Throw a penny in a wishing fountain
    • In the end of the day, getting selected involves some amount of luck. Work hard on the proposal and hope for the best!

Previous post
Open letter to the Paul G. Allen School of Computer Science A few days ago, I was surprised when my friends taking University of Washington’s introductory programming course - CSE 142 - described an
Next post
Google Summer of Code: Wrapping Up Today marks the end of the coding period of Google Summer of Code 2017. As part of this program, I have worked with the Physical Web team to design