• SummerOfCodeStudentChecklist

Student Checklist for FreeBSD Summer of Code Students

This page collects ideas and best practices for students participating in Summer of Code 2010 with the FreeBSD project.

Applying

We get a lot of excellent proposals to work on FreeBSD during GSoC 2010. Although none of the following are required, they can help make your proposal stand out:

• Find a mentor. You'll need to work closely with a FreeBSD developer who is willing to act as your GSoC mentor. If you can find a developer who is willing to commit to helping you, that is a big boost. Every year, we have to reject a handful of proposals because we cannot locate a suitable mentor.

• Read the mailing lists. By reading the mailing lists, you'll learn a lot about how the FreeBSD project operates and what kind of people participate.

• Talk about your idea in public. The freebsd-hackers@freebsd.org mailing list, in particular, is an open forum where many people share ideas about how to improve FreeBSD. By discussing your idea there, you can get feedback that will help improve your proposal and demonstrate that there is interest in your idea.

• Contribute. Send us a patch! Even if it's not accepted, your patch will show us that you use FreeBSD, have the coding skills we need from GSoC students, and have looked at the source code. If you plan to work on the ports collection, port some software to get familiar with the infrastructure.

Community Bonding Period

After applications are accepted, there is a period of a few weeks before the official start of coding on May 24. We require our participants to take a few simple steps during this period in preparation.

• Talk to your mentor. You'll have to work out with your mentor how you'll communicate (email, IRC, etc), how often (some mentors require daily progress reports, for example), and how you'll work together.

• You'll be automatically added to the soc-students@ mailing list. You may also want to join either the freebsd-hackers@ or freebsd-current@ mailing lists to keep in touch with what the larger FreeBSD development community is doing. Your mentor may also want you to join one or more lists specific to the area of your project (net@, embedded@).

• Get a wiki account setup on wiki.freebsd.org so you can update links about your project on the main SummerOfCode2010 wiki page. Your mentor can help you set up access. If you would prefer to use another site to post updates about your progress, that is OK, but you should still update the wiki with a basic project description and provide links to any blogs or external websites where you will post updates.

• Familiarize yourself with the perforce revision control system. The SummerOfCodePerforce tutorial will walk you through setting up your account and committing your first file.

• If you use IRC, ask your mentor about relevant FreeBSD related IRC channels for your project (not a requirement, some mentors and some students find IRC very helpful, and others do not).

• If you would like to blog about your project, mail flz@freebsd.org to add your blog about your project to the Planet FreeBSD blog aggregator.

• Post milestones for your project, in consultation with your mentor, somewhere publicly available. The wiki is the preferred location. If you maintain this information somewhere else, please post a link from the wiki.
• Talk with your mentor about any background reading of code, papers, or book chapters that will help provide context for your project.
• Especially if you are new to FreeBSD, expect to spend some time before the official start of coding becoming more familiar with FreeBSD: Install it, use it, perform a full system upgrade from source code.

First Half of the Summer, before mid-term evaluations

• If your school schedule does not permit you to start on May 23, you should carefully negotiate this with your mentor. If necessary, you can raise any concerns with soc-admins@freebsd.org.

• Talk to your mentor regularly. Most mentors expect some interaction every day via email or IRC. Make sure your mentor knows what you are doing and what problems you are having.
• Find others in the community aside from your mentor that are working in similar areas or have a particular interest in your project. Send them a short introductory mail about yourself and your project.
• Submit code regularly to Perforce. You should commit early and often. You are working in an experimental summer of code branch of the tree and it is not expected that code in a revision control system is in a finished state. On days where you are actively working on your project it is hoped that you'll submit at least once a day. Many students will make hundreds of submissions to perforce over the course of the summer.

Second Half of the Summer, after mid-term evaluations

• Submit information about your project to a FreeBSD Developer Status Report to raise awareness of your work. Submissions are expected to be works in progress, so no matter where you are in the process if you passed the mid-term evaluation you are more than far enough along to warrant publicizing your project in the status reports.
• Update the wiki about the milestones for your project and which ones will be completed by the end of the summer.
• In consultation with your mentor, possibly send a mail to hackers@ or another FreeBSD mailing list to announce some details of what you have accomplished so far to a larger audience.
• Talk to your mentor about the eventual suitability for submission to Subversion of your project. Is the code on track to eventually be included in a future release of FreeBSD?
• Before the final evaluations are due, update the wiki with a final summary of what you accomplished over the summer.

After the summer

• You are encouraged to continue working on FreeBSD in any way you can. If you'd like to keep your perforce account active, mail p4@. Talk with your mentor and others in the community about follow up projects if you are interested in doing more work or becoming a full FreeBSD committer.
• If your project addressed an idea from the FreeBSD ideas list, mail your mentor and the maintainers about adding a link to your work and/or removing this idea completely if the project is completed and there would be no need for others to do this.