> +1 on more detail. Not just a little more, a lot more.
>
> You can see the amount of detail accepted in prior years on our wiki at
> http://brlcad.org/wiki/Google_Summer_of_Code
> <http://brlcad.org/wiki/Google_Summer_of_Code> and selecting one of our years
> at the bottom. In general, the more detail, the more prepared you will be,
> the more you demonstrate you understand the topic, and these are all good
> characteristics to have in any proposal.
>
> I’ve yet to see one too long. ;)
One more thing regarding detail, and this applies to everyone, is to provide a
detailed timeline. It’s best if you can account for every week of GSoC with a
specific objective, activity, or deliverable. Seeing things like “Weeks 2-4:
work on implementing XYZ” or “May 23 - June 7: research nurbs” in a timeline
are huge red flags. It usually means the person has no idea how hard that
problem is.
There are some genuine research aspects to some proposals that will span weeks
and you should talk about that, but you should still aim to identify a specific
real objective for every week of the 12 coding weeks. That is, break up big
tasks into smaller tangible steps or incorporate other tasks that will
demonstrate progress. Also with few exceptions, most research and reading and
familiarization should be happening before May 23 during the bonding period.
If your project could result in an academic journal publication, there is
definitely flexibility on this point.
Basically proposals should be specific and demonstrate weekly code progress in
some capacity.
Cheers!
Sean
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
