Note to students

The goal of Summer of Code is to get your project written, reviewed, and
ultimately merged back into Django's trunk. We want your project to
succeed, and we approved it because we think you've got a good chance of
pulling it off.

However, this is easier said than done. You'll need to work hard,
communicate effectively with the community, and pass a rigorous peer
review. Your mentor -- and Django's committer team in general -- will give
you as much support as possible, but ultimately the onus is on your
shoulders to get this done.

We've been doing this for a few years now, and we've started to figure out
some patterns of successful projects. The main thing we've noticed is that
being strict with our rules makes for less stress and more success overall.
Thus, this year we've got some explicit rules and guidelines that we're
going to expect you to follow.

Please read through the following and make sure you understand it; now's
the time to ask questions and get things all worked out.

Weekly check-in
---------------

Throughout the summer, starting *this week*, you need to post weekly
updates to django-dev and/or your personal blog detailing your progress to
date, issues you've run into, problems you've solved, etc.

Whenever possible, these weekly check-ins should help people try out your
branch: provide links to documentation, example code, etc.

For a good example, check out this update from Nicolas Lara last summer:

http://groups.google.com/group/django-developers/browse_thread/thread/ba002919ad116fb4/df1d6d524704e957

It's not hugely long, but it has a status update with a list of what's
working, not working, and unknown, and also has some example code showing
off some new features. Notice also that this generated quite a bit of
discussion. This is good: it feeds back into the project, and helps make
the code more robust.

These updates are *mandatory*, and we're going to be sticklers about them.
Missing a *single* update without prior warning is enough to put your
project in jeopardy.

Some weeks -- especially at the beginning -- you probably won't have this
much to report. That's OK: just be honest about what you've done and where
you are. A short report saying you slacked off and didn't get much done
won't worry us if it happens once or twice, but, again, you *must* file
something.

Your first check-in
-------------------

Acceptance will be officially announced Monday, April 20. Again, these
required check-ins begin *that week*, so your first check-in should be
posted to django-dev by Friday, April 24. 

I don't expect anyone to have gotten any work done just yet, so this first
check-in really just needs to be your final proposal, modified according to
any comments you got during the submission process.

Interim period
--------------

In fact, you probably shouldn't start work right off the bat. Work is
technically not scheduled to begin until May 23; the interim is a
"community bonding period" that you should use to get more feedback from
the community, figure out Django's process, etc.

What you do during this time is mostly up to you and your mentor. However,
this interim period is *also* a time to prove to use that we've made a good
choice, so there are a few requirements during this period:

    * First, weekly status updates. Yes, you won't be doing a whole lot
      during this period. That's fine -- if you don't do anything between
      the last week of April, just file a report saying so. We're less
      concerned about the content of your updates during this period than
      the simple fact that you can produce 'em.
      
    * If you haven't had a substantial patch accepted into Django yet, you
      need to also use this time to get familiar with Django's coding
      submission process. 
      
      With your mentor, you need to pick a ticket, produce a patch (with
      the requisite tests and documentation), and walk that patch through
      the submission process until it's committed. Ideally, you should be
      able to find a ticket that roughly relates to your project or area of
      choice. However, the important part is just to get you familiar with
      writing code, tests, documentation, and walking the patch through
      review and getting it committed, so any ticket you and your mentor
      agree upon is fine.
      
      Each SoC project has a committer associated as either a primary or
      backup mentor; this committer will prioritize review of this
      particular ticket so that all the onus of getting this work done is
      on you.
      
      You'll be expected to have this patch completely ready for commit --
      good code, test coverage, and clear docs -- by the end of the interim
      period (May 23). The 1.1 release timeline might mean that actual
      *commit* of your ticket is delayed until later, but you still need to
      have it completely done by the end of the period.
      
    * By the end of the interim period you need to have a final draft of
      your "marching orders" -- your project outline and work timeline,
      week by week. The idea is that come May 23 -- or earlier, if you're
      itching to get started -- you should be able to bust out of the gate
      with a firm to-do list.
      
Obviously you should expect your mentor to give you whatever guidance you
need during this period.

Communication with your mentor
------------------------------

The biggest predictor of success is the quality of communication between
you and your mentor. You both need to communicate early, often, and well.
Exactly how this works is up to the two of you, but here are some
guidelines:

    * You need to be in touch with your mentor even more regularly than
      your weekly check-in. I'd suggest that the two of you try to talk
      every day, if only very briefly.
      
      Ultimately the parameters of your communication is up to you and your
      mentor; if you both choose to be in touch less frequently that's
      acceptable. Still, we *highly* suggest you figure out a way to talk
      briefly every day over email, IM, Skype, or whathaveyou.
      
    * If you plan any vacations or other away-from-keyboard time make sure
      your mentor knows that you haven't just dropped off the face of the
      earth.

    * You need to respond to email from your mentor ASAP. If he asks you a
      question you're not sure of it's fine to say "I don't know but I'll
      get back to you," but do respond right away. Again, if we think
      you've disappeared, that's bad.
      
    * Likewise, your mentor needs to respond to email and other
      communication from you right away, and needs to keep *you* posted
      about any of *his* AFK time.
      
      If you can't get in touch with your mentor, you've got a backup
      mentor. If *that* fails -- and sheesh it better not -- you can get in
      touch with me or Jannis, and we'll kick some ass on your behalf.
      
Code
----

You'll be given a branch in Django's SVN repository; use it. If you're a
DVCS user that's fine, as is use of Bitbucket, Github, etc. However, you'll
need to check back into your SVN branch regularly -- weekly at the very
least, though really you should be checking back into SVN pretty much every
time you push upstream. Part of this process is getting comfortable coding
in public.

You also need to merge with trunk at least weekly. It's probably a good
idea to do this just before your weekly check-in so that users can
conveniently switch branches at that point.

Review
------

Your mentor should review all your code as you commit it to your branch and
give you feedback at that point. You should *also*, however, expected to
get feedback from the community as you work. This might come in the form of
replies to your weekly updates, questions in IRC, or tickets and/or patches
filed against your branch.

You'll need to handle this review yourself. Again, your mentor's here to
help you out, but one of the purposes of Summer of Code is helping you
learn the skills you need to participate in open source projects. Anyone
using your branch will expect to be able to give you feedback and to report
bugs, so you need to be receptive to that stuff.

You might get some pretty harsh feedback at moments. Remember that everyone
here has the same goal: make Django as awesome as possible. If someone
disses your code, it's a criticism of the *code*, not *you*, and goal is to
make things better.

Be bold
-------

Finally, the best thing you can do this summer, to steal a line from
Wikipedia, is to "be bold."

If you need help, ask. If you need feedback from the community, post on
django-dev. If you get some code done, check it in.

Don't spend too much time asking permission or seeking approval. In the
end, your code will speak for itself, so do whatever you need to do to make
that code awesome.

We're here to help, and we'll do whatever we can to make you successful.