Hints for Successful Proposals

Historically, the majority of students who have been awarded projects for work on Boost engage the community (participate on the mailing list) prior to submitting an application and write good proposals.

Engage the Community

Join the mailing list. Talk about what you want to do. If we know you're willing to get involved, then we'll review your proposal more favorably. Also, if you're active on the mailing list, it might lead us to believe that you are willing to participate beyond the end of your summer project.

What Makes a Good Proposal?

Writing good proposals can be difficult and takes practice. Remember to be precise, concise, and professional in your proposal.

• Write Precisely - Be very specific about the project you are proposing. Don't be vague. Say what you're proposing to do early the text of your submission. Demonstrate that you understand the requirements, design space, and solution space of you proposal by seeing what others have done before. Including notes on related projects and their potential impact on your work will convince

• Write Concisely - Only write about the work you are proposing to do and work related to your proposal. Telling us that you placed highly in a programming competition doesn't necessarily demonstrate your qualifications with respect to your project.

• Write Professionally - Writing a GSoC proposal is no different than applying for a job. Emoticons do not belong in job applications.

Well-written proposals will demonstrate the student's understanding of the problem, in addition to describing what they are proposing to work on. Good proposal will generally do the following:

• Describe the problem being solved - Give some context to the proposal. If you're proposing to implement a generic tree container, give some background on trees and their applications in computer science or software development.
• Explain why the problem is important (to Boost) - Sell us on your idea. Why should we be interested in funding development on a Boost tree container? This should be pretty easy for trees.
• Give examples of similar or related projects (also in other languages) - Demonstrate that you have actually thought about the problem and looked for other solutions. This helps convinces us that you're actually interested in the problem, and have developed some insights on the project. What other C++ libraries have tree data structures? Java trees?
• Outline the work being proposed - Tell us what you're going to build. What classes? What algorithms? Are there any natural extensions to your work that might be included. Are you going to build a fixed-sized n-ary tree? A multi-way tree? Specializations for binary trees?

Other tips

A proposal is not just a statement of intent. A proposal that only says, "I will write a tree class" is not a good proposal, and will be ranked with the lowest possible score.

The following information is not considered when reviewing your proposals:

• Grades in classes
• Your rank in your university
• Faculty that you work with
• Success in programming contests
• Religious affiliations, gender, ethnicity, race or anything else which doesn't involve ability to work hard and write high quality code (note that Google exclude citizens of some countries from GSoC, but that has nothing to do with us).

We rank proposals based on the feasibility of proposed work and whether or not we believe the student is capable of accomplishing that work. From experience, we have observed a strong correlation between students who come early and self initiate contact with potential mentors and success. We suggest you be one of those, not a student who submits an application an hour before the deadline who we've never seen before. Indeed, as of 2015 we have taken measures to downrank such late applications, see below.

How the student proposal reviewing process works

Almost as soon as student applications begin, the Boost community including potential mentors begin to start ranking proposals. We have noticed that early submitted proposals tend to do better than later submitted proposals. Each community member will assign a score between 1 and 5 to each proposal, and may ask you questions. You should try to answer those promptly.

Boost community members will tag proposals they would like to mentor with their name. You the student doesn't see this part until the end. When student applications close, we assign each proposal into one of two categories:

A: The student has demonstrated their ability to write in C++.

B: The student has not demonstrated their ability to write in C++.

We take the highest scored proposals from Category A which have a mentor willing to mentor them and recommend those to Google, in order of scoring. Sometimes a mentor is attached to more than one proposal, in this case the highest ranked proposal is recommended to Google and the others are not as we try to avoid more than one mentor per student. After all the proposals from Category A have been recommended to Google, we then recommend those from Category B which have a mentor willing to mentor them. This is what we mean by "preferentially ranked" - no matter how good the written application, a student without evidence of ability to program is the least likely to be selected no matter what.

Google then review our list of recommendations, usually removing some students from our top picks, and return back to us how many students they will fund for Boost this year. We try to reassign mentors as appropriate to fit the loss of higher ranked students and however many slots Google gave us. We may try begging Google for more slots sometimes depending on the calibre of applicant we would lose otherwise. A few rounds between us and Google then occur, eventually settling on a ranking, and those students get to do a Boost GSoC that year.