How I Prepared for My First Summer of Code

The acceptance email is the part everyone remembers. The part that made the acceptance possible was much less photogenic: reading project lists, joining mailing lists, asking careful questions, and sending small patches to a codebase I had never touched.

This is how I approached Google Summer of Code in 2020. It is not a formula. It is a record of the steps that worked for me.

Start with the work, not the label

It is easy to treat a program like a prize to win. The better frame is a project you want to work on, with a program attached. The project is what you will talk about every week. The label is temporary.

That shift changes the questions you ask. Instead of "what do I need to say to get in?", you ask "what does this project need, and can I help with it?"

Shortlist organizations

I read through the project list with a narrow set of interests in mind: systems, testing, containers, machine learning, and the web. That filter made the list smaller and the choice clearer. Wikimedia Foundation stood out because the project touched browser automation, an area I had already been exploring on my own.

A shortlist is not a commitment. It is a way to spend your attention on a few places instead of skimming all of them.

Join the room before you speak

Every open source community has a room where the work happens: a mailing list, a chat channel, an issue tracker. Join it and read. You will learn the vocabulary, the current problems, and the tone of the conversation. You will also learn who is patient and who is busy.

When you are ready to speak, make it easy for someone to help you. Say who you are, what you have read, what you are trying to do, and what you have already tried.

Write a useful introduction

A good introduction is short. It includes your name, your background, the project you are interested in, and why. It does not need a life story. It needs enough context for a maintainer to place you.

I also read the mentor's public work before writing. Not to flatter, but to avoid asking a question that was already answered in the documentation.

Do the assessment tasks

The assessment is where the conversation becomes concrete. Pick a small task, read the surrounding code, and ask for feedback early. A patch that is easy to review is more valuable than a large patch that arrives without context.

Each round of feedback is information about how the project works. Treat it that way. The goal is not to prove that you already know everything. The goal is to show that you can learn in the open.

Draft the proposal as a plan

A proposal is a plan for work, not a essay about enthusiasm. I described the problem, the approach, the alternatives I considered, the milestones, and the risks. I included pseudocode for the parts that were still uncertain and a short explanation of the system design.

The most useful sections were the ones that admitted uncertainty. A plan that names its risks is easier to trust than a plan that pretends there are none.

Submit one strong proposal

You can often submit more than one proposal. I submitted one because I was more interested in doing that project well than in spreading a thin layer of attention across several. That was the right trade for me.

After acceptance

The work starts again after the email. Community bonding, a public timeline, weekly updates, and small patches that keep the project moving. The habits that got you accepted are the same habits that make the summer useful: communicate early, keep changes reviewable, and write down what you learn.