7 tips for applying to Google Summer of Code
Advice for applicants from Wagtail Core Developer Sage Abdullah
This is the time of the year when a lot of students and other folks hoping to contribute to open source start thinking about how they can put together strong applications for the Google Summer of Code program. We still haven't officially announced whether Wagtail is participating in Google Summer of Code 2026 (have patience with us!), but we thought it might be helpful to share some advice that one of our core team members shared during an interview a while back.
Sage Abdullah participated in the Google Summer of Code program for Django and has successfully turned his experience into a career as a core developer for Wagtail CMS. Here are his tips for participating in Google Summer of Code:
1) Start early
If you're looking to participate, I'd recommend starting early. Learn how people communicate in open source. Learn how things move in the project you're interested in: how issues are triaged, how pull requests are reviewed, how decisions are made. You can learn a lot just by reading discussions and exploring the documentation for the project you're interested in. Most projects have contributor guides – Wagtail has one too. Definitely take time to read what the maintainers have to say in those guides. Maintainers really appreciate contributors who follow their instructions.
2) Start with just one issue, study it well and fix it if you can
It is never a good idea to start by spamming every single issue you find with "I want to work on this, please assign me this issue". It's often not how things work in open source, and it's not a good way to make a good first impression.
Instead, try to find an issue –not two, not three, but one– that you can understand. If it's a bug report, make sure that it is "confirmed". Open source projects get bug reports daily, and not all of them are valid. It's not uncommon for a bug report to be "unconfirmed", meaning that no one has confirmed that they can replicate the issue. That's where you could step in. Try to replicate the issue, and if you can, leave a comment saying that you can replicate it. Attach screenshots or other details if necessary. If you can't, leave a comment saying that you can't, and maybe ask for more details to the reporter.
Once you get a good understanding of the issue, you can start looking into the codebase. A simple code search on GitHub or your text editor can go a long way to help you find where the issue might be. Search for the error message, the function name, or the variable name, etc. If you're not sure where to start, you can ask for help. Don't expect people to give you the answer right away, but they might be able to give you some hints on where to look.
If you're feeling confident, you can leave a comment on the issue you chose, stating your intention to fix it. Depending on the issue, sometimes the fix can be straightforward, and you can just go ahead and submit a pull request. Sometimes the fix can be more complex, and you might want to discuss your approach first. In any case, make sure to follow the project's contributing guidelines. They're there for a reason, and not following them can make your contribution harder to review, and it certainly does not demonstrate a good reading comprehension. That last point is especially important, as it's a common issue that I see with new contributors.
3) Learn the basics of Git and GitHub before making your first pull request (PR)
Learn Git and GitHub (or the platform that the organization uses). Learn how to work with branches, how to write good commits and commit messages, how to rebase your changes, and how to resolve conflicts. Learn Markdown to make your written communication more effective. It's not uncommon for a pull request to have to go through several rounds of reviews, and you'll want to keep your changes up-to-date with the latest changes in the project so that they're easier to review.
This is very painful for me to say, but if you're still struggling with the basics of Git – which is a very common tool in open source – you might want to work on that first before getting into Google Summer of Code. Some maintainers might be willing to help you with that, but it's not something you can expect from everyone. If your PR contains unrelated code from your other PRs, or if you commit your entire virtual environment to your branch –which are all easy mistakes to make when you're a beginner– it's not a good look. GitHub and other platforms make it easy to review your changes before you submit them, so make sure to use that feature. Failure in doing so does not demonstrate that you know what you're doing. It's not the end of the world, but it's something you'll want to avoid, especially when there are other applicants who might be on their way to make their third or fourth PR.
4) Make your pull requests as thorough as possible
When making pull requests, don't think of a pull request as a one-time thing. Before you hit submit, don't forget to review your changes. GitHub will show you a list of changes you've made, and you will want to ensure that they are what you intended. An excellent pull request is not just about the code changes, but also about the context. Make sure to link to the issue that you are fixing, how you fixed it, and why you fixed it that way. A good thing to do is to put yourself in the shoes of the reviewer. What would you want to know if you were reviewing the pull request? Do the changes make sense?
As a reviewer, I want to see the contributor's own understanding of the issue, the reasoning behind the chosen approach, and any alternatives they've tried or considered. Written in their own words. I don't want an AI-generated summary of the PR in the description. If I wanted that, I'd ask an AI directly.
Also, it's important to note that we value quality over quantity. We'd much rather have one really good pull request than five low-quality ones. It's even worse if the author does not understand the changes they are submitting.
5) Think of ways to make your application stand out
Did I mention how competitive GSoC has become? With so many applicants, the project maintainers don't have the time to hold your hand through the whole process. To stand a chance against the other applicants, you need to stand out. From what I've seen, the best applicants tend to be ones who can work independently, understand the context of what they are working on, and communicate their thoughts and opinions in their own words. If you can show that you're capable of those things, you're already ahead of the game.
When you're writing your proposal, make sure to be clear and concise. Explain what you want to do, why you want to do it, and how you plan to do it. Show that you've done your homework, and that you're familiar with the project. If you're proposing your own project idea, explain why it's important, and how it fits into the project's goals. If you're proposing to work on an existing project idea, ensure you understand the project's goals, and demonstrate why you're the right person for the job.
Most importantly, use your own words. It does not have to be perfect. We can tell when you have put a lot of effort in communicating your own thoughts. On the flip side, AI-generated proposals will stand out, too. Like a sore thumb. And we'll just reject them.
6) Ask for feedback early and revise your proposal
Make a draft proposal, and ask for feedback as soon as you have something to show. People in the community will be able to give you feedback on your proposal, and you'll be able to iterate on it until it's ready to be submitted. You'll have a better chance of getting accepted this way, as opposed to submitting a half-baked proposal at the last minute.
7) Don't give up if you don't get accepted
Finally, it's not uncommon for a project to have more applicants than they can accept. If you're not accepted, don't be discouraged. By this point, you'll have learned a lot. There are many other ways to contribute to open source, and GSoC is just one of them. Check out other similar programs, like Outreachy and Djangonaut Space.
And if you still want to get into GSoC... your work this year didn't go to waste. You'll stand out next year!
If you want to keep track of Wagtail's plans for Google Summer of Code 2026, we recommend you follow the instructions in our Google Summer of Code repository on GitHub. Also, sign up for our newsletter so you can learn more about our software and community.
