Summer of Code guidelines - rough draft

Justin C. Sherrill justin at shiningsilence.com
Tue Apr 22 20:47:13 PDT 2008


I'm listing here a skeletal list of guidelines for students and mentors. 
I'm looking for feedback whether you are a project participant or not -
I'll stick the results into an email to students/mentors within the next
day or two to make sure that everyone has the same base information:

1: Subscribe to the kernel at dragonflybsd.org mailing list, and use IRC

Discuss everything on kernel whenever possible, including student/mentor
interaction.  The rest of the DragonFly community can then offer feedback
and help.

There's a lot of DragonFly people on IRC, in the channel #dragonflybsd on
EFNet; it's a good way to get immediate feedback.

2: Keep code public

It can be in cvs, svn, git, or whatever.  The student code needs to be
publically accesible and in a form where changes can be seen.  If you need
someplace to store code or help with revision control system usage (or
both), ask on kernel at .

3: Use the wiki

Students, please describe your project on the DragonFly wiki
(wiki.dragonflybsd.org)  If it's initially a reprint of your project
proposal, that's fine.  Update parts like your timeline and your
methodology as it changes.

4: Be vocal

Students, keep your mentor up to date.  Don't let more than a few days
pass without mentioning something on the kernel@ mailing list.  Weekly
summaries of your work - just a paragraph, even if everything's going fine
- are the best idea.  Warn us if you're dropping off the net for a
vacation or trip.  (That applies to mentors too)

The biggest danger to a project here is having people just fade away; keep
everyone up to date so that we can tell when there's problems.

Students that stop communicating look like they've quit; students who quit
don't get paid, and we all feel bad.  So don't stop communicating!

5: Justin and Matthias are the backup coordinators

If you and the student or mentor you are paired with are having problems,
involve Justin or Matthias as soon as possible so the issue can get
resolved.

6: Enjoy this time

Getting paid to do open-source peer-reviewed work is still a relatively
rare thing for programmers; enjoy it!


This will be exciting.  The real benefit for DragonFly is not the cash or
the new code, though those certainly are nice.  What I'm really looking
forward to is more people becoming part of the DragonFly community.  We're
all volunteers working together on an abstract project, and having new
folks step up is the best.








More information about the Kernel mailing list