GSoC Proposal Tips

[willgearty]

It is now too late to submit a proposal draft and get feedback. Here is some general feedback that is useful for all proposals (copied from Slack):

• Read the Contributor Guidelines document. There's even an application template in there!
• Applications should only be as long as they need to be to show that you understand the project scope, how it fits within the context of our codebase, and what a reasonable timeline would look like. Make sure it isn't too long to the point where the important information is lost among unimportant minutia. I hesitate to put a specific page limit, but I will say that we need to read a lot of these, so keep that in mind. 30 pages is definitely way to long.
• You are more than welcome to propose a project that is not in the Ideas List. It will be judged just like any other application.
• We only require 1 open or merged pull request for an application to be complete (closed PRs do not count). The quantity of pull requests made by an applicant will not be used as part of the review (except for cases where an applicant submitted a bunch of AI slop PRs which can certainly negatively impact an application).
• Don't shove giant blocks of code into your proposal. First of all, this takes up huge amounts of space and makes your proposal too long. Second, you can definitely explain what the code is doing much more succinctly and understandably in natural language.
• Make sure everything is legible (at a normal zoom level). If we can't read the text in a figure, it might as well not be in the proposal.
• We don't want a single PR at the end of the summer. Make sure to identify the best PR strategy for your proposal where reviewers aren't overwhelmed and ensure your PRs are atomic.
• Don't repeat yourself. This is another really easy way to save space. We don't need to read the same thing over and over. It artificially makes the proposal longer and often makes it more boring to read. AI has a really bad habit of doing this, especially for longer form documents.
• Good stretch goals are an easy way to wow us. But just linking to another issue that is vaguely related isn't creative or useful. We're looking for insight in identifying missing functionality and creativity in solving it. Ultimately, this is what demonstrates a deep understanding of the codebase and the project.