More observations from the front line as I finish up my first pass:

1. Use formatting sparingly!
   Don’t make your entire proposal bold, it doesn’t help. Excessive font sizes for headings doesn’t help and all sorts of weird fonts through out also don’t help. Additionally some proposals seemed to have a fixed width set for them which whilst not being their major malfunction (they were junk proposals in reality) it would have detracted from a better proposal. Also using excessive tables doesn’t help as well. Excessive capitals is also just as bad as using too much bold text.
   The converse is true. If your proposal looks like a big chunk of text then this is a serious lack of formatting and should be resolved. Basic use of a paragraph (general rule: at least 3 sentences in a paragraph!) will help and for something like SoC you need at least three paragraphs: who you are, what you’re going to do and convincing me you can do this. The first and last can usually get away just one paragraph though the middle could easily fill out to be an A4 page or more of content (think around three, plus you’ve got to have a timeline in there somewhere).
2. It is Summer of Code
   This means you need to at some point write serious amounts of code. And I mean “serious”. Language packages don’t cut it and nor does sample content. Neither have code in them and neither are relevant to the program as a whole.

I’m starting to reduce my nag points which I think means I’m almost happy with things. I’ve read every proposal at this point and thrown out a whole heap more. Time to work through ranking the remainder slowly.

Edit: Updated to add more to the formatting heading. Not always is less more even though quite often more formatting is less.

Some more observations as I’m going:

1. If you have to put your CV in, put it at the bottom.
   I saw one proposal I didn’t mind and was structured nicely. They broke rule 2 and 3 from Part 1 (CV elsewhere and majority proposal) however they made up in some other areas. However as annoying as their CV being there was, it was done in a way where I mostly glazed over it because it was formatted well that I was happy I could ignore that section.
2. Work towards defining a timeline you expect stuff to be done in.
   If you haven’t got a timeline (or haven’t worked out from rules 6 and 7 in Part 1 that you need a timeline) then you need one now. Timelines are great for adding a bit of extra bulk to your application and you can then link it in with the ideas you’re talking about to provide a framework in which we can evaluate what you’re doing, when you’re going to do it and later evaluate if you’re on track or not. Without this then we’re not in a position to work out if you’re not going to finish something on time or keep you on track and we have to work it out again and that usually doesn’t go well. So we avoid that.
3. Be Different in being the same.
   So you’ve picked an idea from the ideas page and that itself isn’t such a bad thing to do. But personalise it and make it your own. Find something unique in the proposal that isn’t on the ideas page and you think might not be picked up by others. When I’m sitting reading through similar proposals having something unique helps me differentiate you from a pack of proposal that look very similar. It may be something really small but it will stand out.
4. When given the option to write, write.
   I’ve seen a few proposals where they are too short and wonder why they have so much space left. Use it. Write something useful and detailed about your proposal. You’ve got space for a reason. Don’t pad it out with something useless and irrelevant to your project (e.g. how many awards you’ve had, a copy of your academic transcript, a full listing of all of your previous positions) but make sure its something useful like maybe a thought out database schema, a minor class diagram or an interaction diagram of some variety. Basically put some thought into it if you think you’re horribly short. Mind you if you’re a brilliant writer some of this might apply but if you can throw in some extra detail demonstrate your skills that way not by how many positions you’ve had.

I’ve passed the 100 mark so now I’m into the final stretch of evaluating everything so it will be interesting to see how I go.

A few observations I have from applications so far this year (I’ve done around 40 so far):

1. Don’t copy and paste
   This includes two things: don’t copy from the ideas page because it just looks bad (plus it makes it look like you’re padding your content out) and don’t copy from your other proposals. I’ve seen a few where I’ve seen things copied and pasted between proposals and it just cheapens the proposals. Not the boring “who am I” crap but stuff like time lines and other stuff that could easily be unique.
2. The boring crap about you as a person can live else where.
   I don’t personally bother with referees or so much what you’ve done because at the end of the day if I think your proposal sucks then I’m not going to bother. Once I’ve gone through and found a proposal I like I’ll grill at that point, or even ones I don’t like but have a passing interest in.
3. Your proposal in your words should be the majority
   I’ve also seen a few proposals where the actually interesting bit of what you think you’re going to do is maybe a third of the proposal (or even half) with the rest of the space taken up with things that aren’t relevant like references and their CV. See point 3, this is stuff you can reference.
4. Don’t use Word
   The worst thing about this is that the rich text editor seems to not properly handle the Word crap, which is unfortunate. I’ve had proposals where the ‘font definitions’ from Microsoft Office (you can easily identify them by their ‘mso-‘ prefix for things) spams up the page and in one case was longer than the proposal. Please don’t use Word, use Notepad or some other text editor. Hopefully something with a spell checker or at least if you have to write it in Word copy it through Notepad and reapply your formatting.
5. Put emotion into your proposal and demonstrate understanding of the problem
   There were a number of proposals that seemed to miss the point of the idea and more that seemed to not understand the root problem the idea was trying to address. Try to understand the problem and perhaps have some form of emotional attachment and look at the problem and provide depth. Show you’ve at least done a cursory study of the problem instead of saying you’ll start solving the problem in week 4 of your SoC.
6. Community Bonding is when you learn stuff
   There are tonnes of proposals where they spend a month before they start writing code instead working on research, planning and learning how the system goes together. There is over a month of time _before_ SoC starts but _after_ you’ve been accepted where you can spend the time learning the system, setting goals and preparing to get started from day one. You can even start coding during this period to give you a head start though I’d personally understand if you didn’t want to do that. Eating a month into coding time trying to work out what you’re going to do with the other period of time isn’t good enough. SoC is already time limited without you creating even more work for yourself.
7. Put the slack at the end not at the start
   The other issue with number six is that the slack is pushed at the start when you think you have time. So you plan there but why would you have a timeline in your proposal if not to plan? So far I’ve only seen one, perhaps two, projects that had their slack time at the end of the project not at the start of the project. Slack time is where you catch up on the deadlines you know you reached. You need it. You really do. Even if you don’t think you do, you will. And if you waste it in the first month by ‘planning’ or ‘designing’ what you’re going to do in the next two months then you’re already behind the person who had it in part planned at proposal time, solidified their plans in the month after they were accepted and started from day one writing code.
8. Be different
   A carry on from number 5 is being different. Propose something relevant (check with the mentors first) that isn’t on the list but you’re passionate about or interested in. Doing something unique will set you aside from masses who just went for the publicised ideas. Also try to keep your own idea to yourself to minimise your competition: SoC is still after all a competition so you want to maximise your changes. Doing something new and different is a breathe of fresh air. Already I have two categories so far with 9 proposals and 6 proposals respectively vying for attention. This doesn’t mean you just apply for one and you can’t apply for ones from the ideas page, but it does mean that you should try something that isn’t necessarily on the ideas page – something you can be passionate about.

I’m sure I’ll have more to come but that is a good start for me so far.