Tips for Making a Google Summer of Code Proposal | Developing a Software Project Plan

Today I was contacted by a student asking for help writing a Google Summer of Code proposal. With the deadline fast approaching in the next day or so, it's probably cutting it a bit late to start working on a proposal for this year's GSoC - but as every student will know, it's not a deadline if you're not waiting till the last minute to scramble up something, right ;)

 

While the advice below was written with the particular student's project in mind, I think the general concepts here are applicable to any software project, so I've decided to repost this info here in the hope that it may help others out there build better software in future.

> Thanks for reaching out. I'm not too familiar with the development culture and software architecture for LibreOffice, so your mileage may vary depending on how much they value different things. (Also, your own skill level + the complexity of the codebase you're dealing with will impact your progress). That said, here are some general tips for how I'd approach creating a proposal for this project (and for that matter, any software project):

1) Focus on the End User + Expected Use Cases/Outcomes

- Who is this functionality targeted for? (e.g. is this something that you expect any user to just pick up and drop into their presentation for some extra polish, or is this aimed more at a expert users who are driven+focussed on achieving some specific result - e.g. science teachers using this to make interactive demos as part of their lectures)

- What is it that the end user would get out of having Bullet available in LibreOffice?

- What can they not do with the current effects that having Bullet available would make easy/possible to do?

2) Think of what the workflow would be like in general terms, trying hard to not get bogged down in the details too much initially.

- For example, are you going to provide the user with a gallery of preset effects (e.g. similar to how Office previews its Styles/etc.), or will it involve more fiddling/setup within several different workspaces (e.g. a multi-window UI consisting of a connections editor, timeline, and parameters view)

Keeping both of the above in mind...

3) Try to come up with a bunch of different compelling use cases.

4) Now, rank that list in terms of most generally useful to least commonly useful, while remembering to consider the practicality of the user achieving that using the workflow you have in mind.

5) Take a look at the functionality that will need to be in place to support those use cases. 

* Try to break that down into chunks.  For example, you'll definitely end up needing at least the following:

   - LibreOffice Shapes -> Bullet object mapping,

   - Simulation engine loop + animation engine integration

   - UI/Properties/LibreOffice integration for defining the physical properties of the objects (and how those relate to the sim) - e.g. Things like the mass/friction/etc. of the objects and their surfaces

   - ... and depending on what you're doing, you may also have things like force field integrations, constraints, etc.

* Estimate how long it will take to do each of these things (using "days" as a measurement is probably a good starting point). Best case AND worst case.  As my current mentor and manager at work says - take the worst case time, and double it, then add those all up. That's roughly how long it probably take you to implement all of that functionality.

6) If the estimated time takes longer that the GSoC period, re-examine your assumptions about what's essential, nice to have, and strictly optional.  Start from step 1 again, and refine your assumptions. It may take several rounds of this to get to something that seems doable. 

7) Try to come up with a tentative schedule (remember, this will absolutely change as you start digging into the codebase + working with your mentor) that focusses on the following:

* Get a minimal functioning integration as soon as possible, then iterating on top of that to add fancier features

* Focus on maximising end-user-value + quality

* Factor in the fact that you're going to get stumped on some things. Maybe it's getting to grips with the LibreOffice build system + infrastructure, the Bullet library, a nasty bug that you get stumped on.

* Based on steps 4+5 - figure out what your deliverables are at the program checkpoints (midterm + final eval), and also on a week to week basis. Be prepared to put a lot of what you'd like to do as "stretch goals"

If all of that sounds like too much work, please at least do 1 and 2.  The technical stuff - i.e. the nitty gritty of how to implement the functionality, familiarity with tooling and languages, etc. - can all be learned and worked on as part of the development process. But, a project is doomed to failure if you do not define it properly from the outset.

Happy coding!