Summary

This page covers with some specificity and examples the expectations for Google Summer of Code students in regards to communication. This is useful for projects who haven't codified their expectations--they can point to this document and use it as is.

The Google Summer of Code coding period is very short. On top of that, most mentors and students are in different locations--so there's no face-to-face time. On top of that, most students haven't done a lot of real-world development/engineering work before. Because of this, it's vitally important to the success of the GSoC project for the expectations to be codified before the timeline starts and for the students and mentors to communicate often.

Additionally, the purpose of the GSoC is to introduce the student to real-world F/OSS development.

This document walks through various expectations as well as various ways to communicate.

FIXME - the above text needs some help.

40 hour work week

Students are expected to work at least 40 hours a week on their GSoC project. This is essentially a full-time job.

The benefits for the GSoC project are huge:

• income
• the chance to work with real developers on a real project
• the chance to become part of that project community over the long term--this can lead to involvement with other projects, social network, good friends, valuable resources, ...
• the end result of the student's project can be used for resume material that is available for all future employers to see

That's worth its weight in gold for a beginner developer. Students should come into GSoC and work to get as much as they possibly can.

Self-motivation and steady schedule

The student is expected to be self-motivated. The mentor may push the student to excel, but if the student is not self-motivated to work, then the student probably won't get much out of it.

The student should schedule time to work on the project each day and deviate as little from this schedule as possible. It's not acceptable to fiddle around for days on end and then pull an all-nighter just before deadlines.

Frequent communication with mentor

Frequent communication with your mentor is a must. Your mentor should have a good idea of:

• what you're currently working on
• how far you've gotten
• how you're implementing it
• what you plan on working on next
• what issues have come up
• what you did to get around them
• etc.

The mentor is one of the most valuable resources for GSoC projects. The mentor is frequently a solid developer and a solid engineer. The mentor has likely worked on the project for long enough to know the history of decisions, how things are architected, the other people involved, the process for doing things, ...

Before the GSoC project has started, the mentor and student should iron out answers to the following questions:

1. What is the communication schedule? Daily? Every two days? Mondays, Wednesdays, Fridays?
2. What is the best medium to use for regular scheduled communication? Email? IRC? Instant messenger? VOIP? Telephone call? Face-to-face?
3. What is the best medium to use for non-scheduled communication? Email? Instant messenger?

DO:

• keep your mentor up to date as much as possible--this forces you to be more organized and it gives your mentor the chance to correct your path when you're going astray
• let your mentor know what your schedule is--are you going on vacation? are you moving? are you writing papers for class? are you ill?

AVOID:

• going for more than a week without communicating with your mentor -- the project timeline is too short for that

Version control

Students should be using version control for their project.

DO:

• commit-early/commit-often -- this allows issues to be caught quickly and prevents the dreaded one-massive-commit-before-deadline

• use quality commit messages

  Bad example:

  Fixed a bug.

  Good examples:

  Fixed a memory leak where the thingamajig wasn't getting freed
  after the parent doohicky was freed.
  
  Fixed bug #902 by changing the comparison used for duplicate
  removal.
  
  Implemented Joe's good idea about rendering in a separate
  buffer and then swapping the buffer in after rending is complete.

• refer to specific bug numbers, links, and issues as much as possible -- the history in version control is frequently the best timeline log of what happened, why, and who did it

AVOID:

• checking in multiple non-related changes in one big commit -- if something is bad about one of the changes and someone needs to roll it back, it's more difficult to do so
• FIXME - other things to avoid?

Communication with project

Most F/OSS projects have mailing lists for project members and the community to communicate and/or have IRC channels. Keeping in touch with the other members of the project can be a valuable resource for the student. Other members of the project may be better versed in other parts of the project, they may provide a fallback if the mentor isn't available, and they may be a good sounding board for figuring out the specific behavior for features.

Shyness is a common problem for students who are new to open source development. The student is encouraged at the beginning to send a "Hello! I'm ... and I'm working on a GSoC project on ... and here's a link to the proposal." email to mailing lists and encouraged to log in and say "hi" on IRC. Break the ice early--it makes the rest of the project easier.

Design documents

FIXME - this section should either be nixed or re-written.

It's a good idea for the student to maintain design documents during the course of the GSoC project. These design documents should cover:

1. the project plan
2. deviations from the project plan and explanations for the deviations
3. any issues that could not be worked out or overcome
4. possible future directions
5. any resources used or relevant specifications

The student and mentor should work out what design documents should be maintained during the course of the GSoC.

One thing to note is that the student shouldn't spend all his/her time doing design documents. It's important to keep track of the design, but it's also important to get some code done.