Contents¶
Writing Project Proposals¶
If you're thinking about writing a proposal for one of the Google Summer of Code projects, you might be uncertain about a few things. How big of a task should you propose? What should you include in your proposal? How can you make it more acceptable?
Of course, you will have to decide the answers to these questions with your own judgment, but on this page are some suggestions that may give you some inspiration.
Get Feedback Before Submitting¶
Without question, the best proposals come from students who take the time to share their proposal on our forums and on IRC to solicit feedback. This ensures their proposals match up better to what the NeL community wishes, and it also gives the community a chance to get to know the student. Both of these will result in much higher scoring than proposals that come in anonymously.
Don't Bite Off More Than You Can Chew¶
Remember that this effort is date-scoped. This is a little unusual for Open Source projects, but is common for contract work. But don't panic, there are some techniques to ensure you will succeed at achieving this.
First, be very careful about what you commit to delivering. If possible, try to pick things that you already know how to do pretty well and won't need to do a lot of learning and research. This way, you'll be less likely to find yourself halfway done and realizing you've bitten off WAY more than you can chew. Of course, you can probably list some "optional" delivery items for things you're less certain about.
Second, try to weight your schedule to get the key portion of the project done as early as possible. In other words, try to do 80% of the coding in the first 20% of the time. The reason for this is that the last 20% of the project often seems to take 80% of the time (no one really knows why, it just always works out that way.) So try to set your schedule up so that you "should be done" within 2-3 weeks; that way when reality sets in and it takes 2-3 months, you're not totally screwed.
Indeed, we will be expecting to see a "mostly done" code delivery at the midterm. Students who don't deliver something that mostly works at this point risk being dropped.
If things go well, for the second half of the summer you should be focusing on fixing bugs, making improvements requested by users, fixing bugs, documenting, fixing bugs, and filling out GSoC paperwork.
There's More to Open Source Than Coding¶
It's very common to assume that most of the work of implementing a new feature is just writing code. Sometimes that is in fact the case, but it's much more common that the coding is just a small part of the effort.
Since the purpose of Google's sponsorship is to increase your knowledge of Open Source, make sure your project includes these other kinds of activities:
- Survey the Open Source world to see if anyone else has done something like your feature; if so, analyze what they did, and borrow ideas and algorithms from it
- Create good code documentation for code affected by the change
- Create a tutorial that shows users how to use the new feature
- Solicit users to test out your new feature, and encourage them to submit bug reports and feature requests. Triage which of these you can do, and do them.
- Write a short article for an online publication about your work
Include Mockups¶
If your feature will involve GUI dialogs or configuration settings be certain to sketch up some examples. Not only is this helpful during review, but it will help you out greatly later when you're deep into the coding.
Unit Test¶
Early in your development, perhaps after initial proof of concept stuff, but prior to the midterm, write a unit test, that will exercise the functions in your feature. The unit test should feed in dummy test data, and verify that correct output or data structure changes are performed. The NeL project is an advocate of test driven development and will require tests for completion of a project