Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to webmaster@scons.org. Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).

How To Write a Good Proposal

This page outlines what is needed in a proposal that will be acceptable to SCons. For a source of potential tasks, look at the ideas page. You can also look at the mentors page for information about the people who will be doing the evaluations.

The Process

You don't necessarily have to do all these steps in exactly the order that they are given here, but some parts need to be done before others, so this is a reasonable sequence to do it.

Don't be intimidated. First and foremost, don't let the apparent complexity of this process scare you away. Preparing a proposal may look like a lot of unnecessary hard work, but if you want to be accepted (by any organization, not just SCons), you'll have to do it eventually in one way or another, so you may as well get it done and have it out of the way. Moreover, you'll find that it's not as difficult as you might think; if you know in your mind what you want to do, this process is just a matter of filling in the blanks. (And if it isn't clear in your mind, this process will help clarify it.)

Check the requirements. Make sure you meet the requirements below. If you can't meet the requirements, you will eventually be disqualified, no matter how good the proposal is. And look at the ground rules below as well to see if any of those might cause problems for your project.

Float your idea. If you aren't already subscribed, sign up to receive the dev@scons mailing list. Write a short note to the mailing list and tell us what you're thinking about doing. Or you can try contacting one of the mentors who you think might be interested in the topic, but realize that you'll probably need to discuss your proposal on the mailing list eventually, so you can save some time by starting there. If the response is favorable, go ahead and start preparing the proposal.

Prepare your proposal. If you don't already have one, you will need a wiki account to submit a proposal. To create your project page, you must be logged in. Place a WikiName (a good choice is your account name, for example, YourName) in the box and press the button:

This will create an empty proposal outline in GSoC2008/YourName. Edit the page and put your proposal in it. Use the proposal guidelines below to help you in determining what to put under each topic.

Get feedback. Once the proposal has enough information in it to make discussion feasible, drop a note to the dev@scons mailing list and tell us about it. Again, you can contact a mentor directly, but you will certainly want feedback from more than one mentor and they will be found on the mailing list. We believe in a lot of interaction to get the best proposal possible, so be prepared to defend your proposal, but expect that a number of changes, potentially major, will probably be needed.

Apply at Google. Make sure you apply in time. Although we will continue to work with you and your proposal through the evaluation period, you will need to submit a formal application to Google prior to the end of the application period. Hopefully, the proposal will be in good shape by then, but even if it isn't, go with what you have.

If you don't already have one, you will need a Google account (depending upon the type of account you want, this can take a day or two, so don't wait until the last minute to get one). To apply as a student, follow the steps in Google's introductory page for sudents. Finally, fill in the application as directed by the template, using the abstract and the detailed description from the wiki application. (Note that Google limits these fields to 7500 characters, so you may need to edit them down to fit.) Be sure to include a link to the full proposal.

Keep working until the end. Don't stop working on your proposal in the wiki until the evaluations are in and the rankings are set. In other words, you can keep enhancing your proposal almost up to the end of the evaluation phase. Take advantage of this opportunity to sharpen and clarify your proposal; it may make a difference in your ranking, and thus whether or not you make the cut.

Requirements

As a student, you must be willing to meet the following requirements, in addition to the Google eligibility requirements:

  1. You must not overbook yourself. Working on your SCons project should be your main activity for the entire summer.

  2. You must be prepared to stay in regular contact with your mentor via email, IRC, or other mutually-agreed method.
  3. You must already know Python and you should have at least cracked open the code and taken a look inside so that you have an understanding of the codebase with which you will be working.
  4. You will be expected to learn how to use the needed developer tools if you don't already know them, including Subversion and QMTest.

  5. You must be willing to discuss what you are doing on the SCons mailing lists. You will be expected to submit a status report to the developers' mailing list at least weekly. At a minimum, the status report should contain these three points:
    • What did you do this week?
    • What problems are you having (if any)?
    • What do you plan to do next?

By far the most important item is the first. Google pays for twelve weeks, five days a week, eight hours a day. We can be flexible to some extent to allow for vacations and the like, but if you can't provide us with 480 hours before the completion deadline, save us both some time and don't apply.

Ground Rules

You can submit more than one proposal, but it's better to pick something where you feel that you can do a great job, and concentrate on writing one outstanding proposal, with lots of detail about what you plan to accomplish.

The results must be maintainable and clean. If you submit a quick hack or something we would have to rewrite from scratch, we will not accept the project as completed, even if the code works as advertised. We would rather have a maintainable, clean, and incomplete piece of code that we could extend than a complete but unmaintainable piece of code.

Do your own work. On the one hand, don't hesitate to ask the community for assistance, but on the other hand, don't expect us to debug your code for you.

The results must be released under the terms of the X/MIT Open Source License. If you are planning to incorporate material from any other source (including translations and transliterations), the source must have a compatible license.

Proposal Template

Don't underestimate the value of a good proposal. Be prepared to spend quite a bit of time on it as it is a major element by which you are judged. Take the time to dot your i's and cross your t's and use the correct terminology because you can be sure that you're competing against others who will do so. And if the proposal is interesting but not complete in some way, be prepared to spend even more time with the mentors to expand and refine the proposal into something we can sponsor.

The more thoroughly you demonstrate an understanding of SCons and the work entailed by your proposal, the greater the chance that we'll accept it. Your proposal needs to convince us that you understand what needs to be done and that you have the skills to do it. Don't just repeat what we already have on the ideas page; show some insight into the why and how of the problem.

Proofread and spellcheck your proposal, then have someone else check it. Yes, this isn't an English contest and not everyone is a native speaker, but if the application is misspelled, uses incorrect syntax or semantics, or just is hard to understand, the mentors are less likely to look upon it kindly. We're primarily an English-speaking team and will expect you to be able to write good code comments, documentation, email messages, and IRC chat in English. Plus, communication skills are important in distributed development such as you see in open source projects, and this is one of the few chances the mentors will have to evaluate that. Moreover, it's not uncommon for a better-written proposal to trump a better proposal even in the commercial world, so it's worth making sure that your proposal is the best you can make it.

A strong proposal will cover the relevant portions of this information:

Suggestions

The following tips, although not required, will give you the best chance of having your proposal accepted. Note that the first six points are effectively identical to the advice in the Writing Your Application section of Google's Advice for Students page (we both started with the same source material).

  1. Promote your idea - Describe your idea in detail. What is its ultimate goal? What components will it have? How does it benefit the project itself and the SCons community? How do you plan to achieve completion of your project? If a specification already exists, what will you do that will go above and beyond expectations?

  2. Promote yourself - Convey your passion for the project. Talk about what makes you stand out from the rest of the crowd. Talk about your past experiences, what makes you tick. Why are you interested in open source software, and SCons in particular? What interests do you have, and how do these interests relate to SCons? There is a basic assumption that people applying for Summer of Code have at least some programming skills already, so rather than a lot of time elaborating on these (though by all means, do tell us what you know), spend time talking about you.

  3. Show enthusiasm - Summer of Code is a very exciting opportunity, and SCons is an extremely exciting project to work on. We're not looking for people who want a summer job to pass the time; we're looking for devoted people who are excited about SCons and about open source, who will remain part of our community even after the project is done.

  4. Tailor your application to the project - Some people may send applications to more than one project, and copy/paste large parts (or even the entirety) from one application to the next. It is painfully obvious when this is done, and it is a sure-fire way for your application not to be taken seriously. Each application you send should be targeted and tailored for the specific mentoring organization and project to which you are applying.

  5. Get feedback from the community - Discussing your idea with some established SCons folks is highly recommended. Try to have your application reviewed by someone before you submit it, whether that be the mentor for a particular project or a person with expertise in a certain area. If your idea duplicates existing efforts or code (and does not provide a very convincing reason for doing so), it will be rejected. Don't be afraid to ask the community for help; we want you to succeed just as much as you do.

  6. Don't wait until the last minute - Applications received in the beginning of the submission process will generally be reviewed more thoroughly than those received in the last hours before the interface closes. Mentors are also more eager to read applications in the beginning and suggest revisions to make your proposal more acceptable. Start preparing your proposal when you first hear of Summer of Code, not a day or two before the deadline. Start planning your application as soon as possible! Even start working on the project; if you can offer some preliminary results to show that your project will succeed, your chances of being accepted are improved.

  7. Be bold - Do you have a brilliant idea that's not on the ideas page? Great! Don't be afraid to suggest innovative and ambitious approaches to solve hard problems. Ultimately, we're looking for new major contributors for our projects and a bold proposal makes us think you might be a candidate. If you know enough about SCons to suggest an interesting project, that lets us know you're serious about us, and in turn, makes us more likely to pick you.

  8. Be realistic - Google requires you to complete a project by the deadline; don't be so bold that your proposal can't be finished. If you think the project as suggested is too large and you can only feasibly complete part of it, make sure your proposal covers a reasonable subset of the functionality (that is, something which is useful without the rest of the project being implemented). Or consider proposing a prototype that can be extended as time permits. In general, we'd rather you had time left over at the end that you could spend on polishing (or working on some other task) rather than running out of time.

  9. Be original - Many students submit nearly-identical proposals based on recent "hot" papers from academic publications. Such a proposal is a reasonable thing to suggest (we do want to stay current in our implementation techniques), but if you do make a proposal based on a current hot area, make sure to make another application in an unrelated area, because you'll have plenty of competitors. It seems counter-intuitive, but the best applications we've received haven't remotely resembled any of the ideas on the ideas page. Since SCons is a general-purpose tool, it's applicable in many areas, so we tend not to have the same limited list of objectives that a single-purpose GSoC project might have.

  10. Be sooner - If you are already a contributor to SCons, your odds improve tremendously. Contribute in any way you can, but if you can, submit a few patches. Having a proven track record of code is a great indication that you will deliver some value in a GSoC project. That way, by the time the selection rolls around, you'll be a known quantity.

  11. Do your homework - Browse accepted applications from previous years. Google maintains links for accepted proposals from past years (look in the about page for each organization); feel free to look at these to get a feel for things your application should cover.

Acknowledgments

Some of the material above is adapted from writings by the fine folks at Drupal and Adium, by Josh Berkus of the PostgreSQL Project, and by Thiago Macieira of KDE. We thank them for allowing us to use it.

GSoC2008/Proposal (last edited 2008-03-12 14:29:19 by ip68-7-76-16)