[Soc-2013-dev] Getting started!

[Ton Roosendaal]

Hi students,

Tomorrow 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

Four projects are missing on this page, please do this a.s.a.p.:
http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2013
- Alexander K
- Jason W
- Sergej R
- Walid S

2) Mentor - Student - Stakeholders

We already decided to add artists as co-owners of modules in Blender.
Several GSoC projects would work great with 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!

For example: Sebastian Koenig for motion tracking, Christian Krupa for VSE.

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

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 hardly didn't do anything last week". ;)

And 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

Whether you use git or not, the svn 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 trunk 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 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.

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