[Soc-2014-dev] Google Summer of Code 2014 started!

[Ton Roosendaal]

Hi students,

Today is the official start for GSoC!
The whole period is 3 months this time, I already know some people still have university duties to handle, or others don't even have holidays. Just make sure your mentor is informed about your scheduling & time.

Here's an important checklist to go over carefully!

1) Wiki documentation

We'll keep this page as main dashboard to check on projects:
http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2014

We expect you to also add more pages in wiki now, for documentation, rewritten proposals, planning and progress. 

2) Mentor - Student - Stakeholders

For Blender we decided lomg ago to add artists as co-owners of modules in Blender. These artists are supposed to be available daily for review or tests.
Several GSoC projects would work great with such an artist buddy (or several) to help reviewing the proposal and work. With some luck they'll do documentation, tutorial vids and artwork examples too!

Both mentors and students should actively look for connecting well with them or select people. Make sure this is known, for example by notifying it in your weekly reports.

3) The very first job: docs & plans

I know it's totally boring, but it's an essential first step to go over your proposal again, and turn it into a final design document with an updated planning.

The design doc should be both technical (code, architecture, flow diagrams) as understandable for users (include clear usability description of result).

The planning should at least include a clear description of the deliverable for midterm evaluation. That deliverable then will be used to define if you can finish the GSoC project.

Your design/plan document should get the formal approval from your mentor and from the module owners as listed on blender.org. You will be responsible for making sure they are well informed, and that they reserved time for you to review it.

http://wiki.blender.org/index.php/Template:ModulesOwners

When module owners don't respond, or are not defined, just connect with me or Campbell for a  decision.

4) Weekly reporting

Every friday - once per week - we expect you to sit down (an hour) to write a short report for this list.

To make reports easy to find for everyone, use a fixed title for it, for example:

Weekly Report #1 Motion Tracking 
Weekly Report #2 Motion Tracking 
etc.

The week counting starts this week. If you don't start right away, or have a week holidays, keep the weekly numbering to match others, that way it's easier to track progress for everyone. (And to see if there's missing reports :).

The report should at least mention:
- Description of work done, and results completed in past week
- If needed, explain why you did something else than announced in the weekly report before.
- Mentioning what you will work on, and deliver the week after.

For me a report like "I've been busy all week reading papers and trying to understand Blender code" is as good as "I didn't do anything last week". Seriously!

Even if you really didn't do much, be fair and honest about it. We're all human, and can understand well that it's not always possible to be productive.

5) Commits & logs

You will be using blender.org git, these logs will be checked and kept for history here. Commit often, and write clear logs about the work. Always make sure Blender keeps compiling (and working) for each commit.

Merging with bf-blender master should best be done every week. Do it as friday job or so, before you write the report!

6) Scheduling work

The best coding schedules are the one that always give "working" code. Basically anyone should be able to checkout your code anytime, and immediately see what you've made sofar. The level of working you can define yourself by making a good planning. Things can work on any level, for as long you make sure you provide the means for someone else to verify that state.

When it's not possible - for big refactors - try at least to divide the work in chunks small enough that there's at least weekly visible progress to monitor.

It's also essential to keep your docs up to date any time. No new feature should ever be committed without having a wiki counterpart describing it. 

7) Communication & meetings

I expect everyone to connect well, at least with the mentor but also with other developers. Use irc.freenode.net #blendercoders as often as possible, it's a great resource to get help there.

We also will put GSoC as fixed topic on our weekly IRC developers meeting. That's a great moment to report progress, or to notify you need help or decisions on topics.

Attending this irc meeting is not mandatory. Being in IRC at least some hours every week is - especially to connect with your mentor and stakeholders.

In due course we also expect you to write a report on code.blender.org blog to show the first results. That could be on a level also websites like blendernation can copy it.

8) Have fun!

:)

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands


-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands