Submitting your application
While there’s no specific required format for the proposals, the student admission process is likely to be highly selective, so we strongly encourage you to submit proposals with the following information:
-
Pointers to work you have done (code, projects, videos, Github or other repository, etc …) demonstrating your programming experience. Having built Ardupilot SITL after a fork of the code base, and having sent a pull request via Github will also be a great plus. (A simple Ardupilot pull request can be done like adding your name to GIT_Success.txt. You can find more information about Ardupilot and Git pull requests here)
-
A description summarizing how you plan to go about implementing the project you have selected. This should include a clear statement about your project objective, and a high level description of how you plan to achieve it. You should strive to be as precise as possible, describing the basic building blocks, algorithms and code you plan to write, and how you would integrate them with the existing code base. What Ardupilot libraries would you modify? How will your code interact with existing features? What sort of testing procedures do you plan to use? While you can’t have exact answers now, your application should show that you have given some thought to these questions and that you have a general idea as to their answers.
-
A resume, and any description of relevant previous work.
Submitting more than one proposal
You are welcome to submit more than one proposal if you are interested by more than one idea. Google allows submitting up to five proposals, although we’d recommend two, maybe three at most. This is because both Google and Ardupilot believe, in a nutshell, that quality is more important than quantity.
Hardware requirements, if any
Include in your application any hardware you believe will be required that you do not have. While simulation can be used for most ideas, some projects will benefit from specialized hardware, and Ardupilot will contribute to hardware acquisition on a case by case basis. Be sure to indicate whether you believe obtaining such hardware would be “nice to have”, vs “absolutely required”.
Additional information and links
While this is dated and not Ardupilot related, this post provides good advice. It also has links to past accepted proposals: 5 Tips to get your Google Summer of Code proposal accepted
See also: Google Summer of Code in 10 Minutes: A Crash Course
From one of the links above, this particular post provides excellent advice: How to write a good GSoC proposal?. Quoted below for emphasis, written by Lalith Suresh, GSoC organisation admin and mentor with the ns-3 project.:
"Your proposal should convince the mentors that you’re the right person for the task, and that you’re a worthy time investment.
The best way to convey this is to demonstrate technical prowess through your application. Be clear, be technically accurate, and provide as much useful details as you can.
Here are some very general guidelines, although the specifics would vary between organisations and the type of project being proposed.
• Start with describing the high-level goal of the proposed project. What is it solving? What would be the short description of the proposed feature? What would it allow users to do? Describe some use cases.
• Describe where in the architecture of the code base your changes/extensions etc would go in. What information do you plan on exchanging between the different components in the code base? Do you envision any architectural limitations early on? If yes, how do you plan to overcome them?
• Now start talking at the level of code. Which source files, classes, methods, functions, etc do you plan on hacking? Will you be adding a fresh module as opposed to modifying some existing components? In terms of code, what’s going through your interfaces? Describe pseudo code if you can as well.
• What will your tests look like? At the end of developing each component, what would a test of its correctness look like?
• Break up all of the above into individual phases. If these phases can be merged independently of each other, then that’s even better. This will end up being your deliverables.
• Provide a detailed plan through the summer of how you’ll allocate time towards completing each deliverable. When presenting the plan, break it up into coding tasks rather than high level architectural components. For instance, “Days 1-7: Implement and test interface X” is better than “Days 1-20: Implement feature A”.
Other pieces of advice:
• Every application usually has a part where the student has to describe her experience that makes her well suited for taking on the project. In my opinion, avoid writing anything here that would apply to just about anyone else. For instance, avoid statements like “I’ve been fascinated by computers ever since I was 2 years old” and “I am greatly inspired by Linus Torvalds”. Instead, state things that make you stand out from the crowd. If you’ve contributed already to the project you’re applying to (or other open-source projects), point us to the commit ids. Show us your github page.
• Have a realistic plan. It’s better to have a lighter proposal that can deliver a polished and mergeable piece of code than a heavy proposal that is half done by the end of the summer. This is best achieved by constantly communicating with the mentoring team through the application phase. Do not be afraid of sharing or discussing your proposal on the mailing lists or IRC.
• Do not regurgitate what you see on the Ideas page in your proposal.
• All rules of scientific plagiarism apply. Make sure you’ve authored the article yourself, and reference your sources of information."