How to brew an effective GSoC proposal!
I recently got selected for GSoC 2022 and here is how you can approach writing an effective GSoC proposal.
Photo by Mitchell Luo on Unsplash
Table of contents
I got selected for GSoC 2022 in the Python Software Foundation in the EOS Design System. A good proposal carries as much weight as your contributions to the project in getting selected for most of the reputed open-source programs. Programs like Google Summer of Code require active engagement in the project, which requires you to demonstrate your ability and communicate a clear plan for achieving the listed project's objectives.
Your proposal should show that you are familiar with the project and the tech stack being used. It should provide a clear picture of your project strategy and a well-defined timeline of events from project development to testing.
Here are some things to keep in mind while writing a proposal.
Writing excellent proposals is similar to writing excellent documentation. Good documentation lists all of the features and possible solutions for every problem, and we should aim to create any proposal in the same way, by listing possible answers to all of the reader's questions. This isn't precisely a proposal writing tutorial, but here are some of the things that helped me write a strong proposal.
The following 8 points will help you understand the process of writing a strong proposal. So follow along 👇
1. Come up with new ideas.
Suggesting new ideas requires a comprehensive technical understanding of the project. You must also grasp the project's goals as a product to ensure that the proposed ideas do not fall outside of the project's scope. It is quite beneficial in projecting a positive image within the organization. Ideas must be feasible and improve the project in some way.
Just be careful when presenting new ideas, and always have a strategy in place to execute them.
2. Follow the given proposal structure.
Google suggests a custom proposal structure for GSoC proposals, which may be found here. Make sure to check if your organization already has a proposal writing framework in place. At the very least, a basic proposal should have fields like Title, Synopsis, Deliverables, and Timeline. You can use the proposals of past contributors as a reference while writing your own.
3. Be specific about project requirements.
Make sure you understand your project's requirements before you start writing your proposal. A few points to think about would be -
- What frameworks or dependencies are you intending to use and why?
- How would the testing be carried out?
- How do you intend to maintain consistency and long-term support?
I was asked why was I choosing a certain framework despite there being more popular alternatives for achieving similar results. Be prepared for such questions, and it would be even better if you addressed all these kinds of questions in your proposal itself.
4. Use illustrations, flowchart animations, DFD, etc.
You should use flowcharts to exhibit SDLC and workflow diagrams in a proposal to give a basic concept of the entire development lifecycle. Use timelines to indicate the sequence of stages that must be completed in order for the task to be completed and broken down in a timely manner. Use code snippets to demonstrate file structure, function hierarchy, state management, and API endpoints, among other things.
If you're planning any UI/UX improvements, make sure to discuss them with your mentor ahead of time and provide examples of UI/UX sketches, wireframes, prototypes, and so on.
5. Organize and plan your work.
Every proposal should include a weekly breakdown of the work you'll be doing over the coding period. Break the project down into a series of milestones, with the goal of completing significant milestones every quarter. Include that in your timeline because your evaluations will most likely take place by the end of the first half of the coding period. Explain how you intend to carry out your plans and provide enough room to correct any new errors or bugs.
6. Take help!
Most people are eager to help, but make sure to cause as little inconvenience as possible to the other person. Be polite and don't ask to ask; just ask! It will save both parties time. Request guidance from those who have already prepared proposals for open-source programs such as GSoC, LFX Mentorship, MLH Fellowship, and so forth.
To acquire new insights into your project, seek the help of those who are specialists in the project's tech stack. My project is about React to Next.js and TypeScript migration. I saw a talk by Yogini Bende on youtube linked here where she was explaining how she migrated Peerlist to use Next.js for better SEO and faster response time using SSR (Server Side Rendering). The video contains a lot of caveats that they faced in migrating Peerlist. This was especially useful as it allowed me to address how I would handle these issues in the proposal itself.
Take help in getting your proposal reviewed. You can ask previously selected GSoC contributors or your seniors and peers to review the proposal. When I got my proposal reviewed, I got some really valuable insights from Vinayak Sharma and Abhinandan Sharma.
7. Mention all relevant contributions and links.
Your proposal should follow the standard format and should contain all the links related to your profile, like Github, Gitlab, Twitter, LinkedIn, etc. Maintainers of the organization want to see proof of work and working knowledge. You should list all of your major contributions in a properly structured way. List the issue/ticket number, the PR solving the issue, and the status of the PR in a neat way. It helps the mentors easily access all your code contributions.
8. Be nice and humble.
Last but not least, be kind and humble:) When asking for help from mentors, peers, or anyone on the internet, be courteous and gentle. Also, in your proposal, keep the tone of your narration positive. If you want to improve some poorly executed UI or some sections of code that are not optimized or well managed, then make sure that you are the one providing solutions and not pointing the organization out. Rather than pointing out the flaws, try to concentrate on the positive aspects and suggest areas for improvement.
I really hope this blog can help someone, and I want to thank everyone who helped me in the process. If you wanna discuss anything about tech or music, then let's connect! You can find all about me on my Peerlist profile. I will soon share my proposal on my Github and also write a series of blogs and Twitter threads about my project as it moves ahead. You can follow me on Twitter here. Thanks for reading!