Covered below in detail are the expectations for Google Summer of Code (GSoC) students that are accepted to participate. In addition to the acceptance criteria that all students are required to abide by, there are participation and behavior expectations.
The GSoC timeframe is very short. There's not much time to get up to speed, so there is a need to be clear of what is expected. Also, many students haven't done a lot of real-world development work previously. On top of that, most mentors and students are in different locations so coordinated interaction can be difficult at times. Because of this, it's vitally important to the success of each student's GSoC project for all expectations to be specified and understood before students begin coding on May 26th. This should be the first step in a long series of frequent communication between student and their mentor(s).
This document walks through various expectations for students and mentors, as well as addressing various ways to communicate effectively.
One of the primary purposes of the program is to introduce students to real-world open source development where there are social, collaboration, and other pragmatic concerns in addition to technical implementation issues. It is our goal to integrate all participants as full-fledged new developers on the project not just for the duration of summer but thereafter too. The projects are a very important part of GSoC, but they're certainly not the most important part. The point is to have new developers join in the project's development.
Unless otherwise discussed, students are expected to work about 40 hours a week on their GSoC project. This is essentially a full-time job. If students can't work this much or if there are periods of time when a student will be away on vacation, then that needs to be discussed beforehand with the mentors or project administrator. The mentors shouldn't have to hunt you down to keep tabs on your activity either (see Version control below).
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 participating. The mentors are there to help, but they're not supposed to be a crutch or substitute for research and hard work.
The student should schedule time to work on the project each day and keep to a regular schedule. It's not acceptable to fiddle around for days on end and then pull an all-nighter just before deadlines. It will show in code and in the evaluation.
Students are treated like any other contributor to the project. That means that in order to get commit access, students need to be actively involved and making small succinct patches at first and engender trust with the existing developers. Once the student shows technical competency, demonstrates respect for the developer guidelines, and is known to work well with the other developers, commit access will be granted. This should happen before GSoC coding begins.
This also means that students should be working with the other developers on the mainline code, not on a branch. There are very few situations that warrant isolated branch development. Particularly for GSoC projects, the desired intent is integrated development where the student intentionally has to deal with the on-going developments of others (both good and bad) just like any other developer and is conscious of making changes that break protocol or compatibility.
Once a developer has commit access, they have a responsibility to work cooperatively with the other developers. Particularly for open source projects, the manner in which everyone commits conveys a lot of information about the status, purpose, and directions of development.
Frequent communication with your mentor is a must. The student should make sure the mentor has a good idea of:
The mentor is one of the most valuable resources for GSoC projects. The mentor is generally already a solid contributor with a long track record of involvement with the project. The mentor likely has 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, and all other cultural lore that will help the student be most successful.
Before the GSoC project has started, the mentor and student should iron out answers to the following questions:
Students should not discuss development in private. This includes refraining from private IRC discussions as well as private e-mails even with your mentor unless the discussion involves personal information. Other developers need to be aware of the progress, discussions, and decisions being made even if they're not a part of that process. It also affords other developers the opportunity to get involved if they have an interest. Don't be shy, speak up publicly.
Student can call upon any mentor or other developer, they don't have to limit their interactions to just their mentor. They shouldn't limit their interactions to just one mentor. Students having difficulties communicating with any mentor should contact the GSoC administrator for the project.
It's a good idea for the student to maintain design documents during the course of the GSoC project. These design documents should cover:
The student and mentor should work out what design document(s) should be maintained during the course of the GSoC. The design documents should be added to the wiki.
-- Thanks --
Thank you to each student for doing your best to follow through with these expectations. Students should consult with any mentor if there are any questions or concerns regarding these expectations.
Many thanks to the Python foundation for their initial write-up document on GSoC participant expectations: http://wiki.python.org/moin/SummerOfCode/Expectations