Enhancements to the guidelines

[James Youngman]

I've enhanced the guidelines a bit to indicate things we'd like to see
in proposals (and a bit about why).   The actual change I made is in
the patch below.  Comments?

Index: guidelines.html
===================================================================
RCS file: /webcvs/soc-projects/soc-projects/guidelines.html,v
retrieving revision 1.14
diff -u -p -r1.14 guidelines.html
--- guidelines.html     4 Mar 2008 14:58:23 -0000       1.14
+++ guidelines.html     9 Mar 2008 13:45:38 -0000
@@ -70,14 +70,18 @@ encourage them to submit a proposal.
 and note the projects you are interested in.  You, as the student
 programmer, then submit a proposal to Google, as described in the following.

-<p>First, please submit your application early.  By doing so, it will be
-given a much greater share of attention than is physically possible for
-applications submitted at the last minute.  Last year, the majority of
-applications were submitted in the last couple of days.  We'd like to
+<p>First, please submit your application early.  By doing so, it will
+be given a much greater share of attention than is physically possible for
+applications submitted at the last minute.  Last year, the majority of
+applications were submitted in the last couple of days.
+That meant that there was no time for us to to give the last-minute
+student submitters feedback on how to improve their proposal, and that
+generally reduced their chances of success.   We'd like to
 see that change.

-<p>You might submit the proposal unchanged, or you might adapt it, for
-example:
+<p>You might submit the proposal unchanged (though you will need to
+include additional information, as described below), or you might
+adapt it.  Changes to the proposal might be:

 <ul>
 <li> You think the project as suggested is too large and you can only
@@ -127,35 +131,76 @@ information:
 <dt>Your name
 <dd>If we include your work in the GNU Project, a copyright assignment
 will be required, so we will need to know your name.
+<p>
 <dt>Your email address
 <dd>We need to be able to communicate with you!
+<p>
 <dt>The name of the project.
 <dd>If your project is from the ideas list,
 please use the same title, except for prepending the package name,
 unless a change is needed to reflect the fact that your propsal is not
 quite the same as the suggestion.
+<p>
 <dt>Summary
 <dd>Please include this, rather than just referring to the suggestion,
 to help avoid misunderstanding.
+<p>
 <dt>Benefits
 <dd>Please explain how users will benefit from your project.  How will
 the GNU project itself benefit?
+<p>
 <dt>Deliverables
 <dd>What software will be added or changed?   What parts of the
 project's code will be affected?  Which documentation will you update?
+<p>
+When we read this section of your proposal, we will be trying to figure
+out how well you understand what needs to be done.  We're more likely
+to accept proposals from students who show us that they know what
+needs to be done.
+<p>
 <dt>Plan
 <dd>Please indicate how you and your mentor will track your progress
 as you work on the project, and how the <a
 href="http://code.google.com/soc/studentfaq.html#46";>mid-term
-evaluation</a> of your project will be made.  What will you be working
+evaluation</a> of your project will be made.  An important part of the
+mid-term evaluation is that it's the point where everybody has to make
+a judgement about whether the project is going to be completed in
+time.  It's important to have specific ctiteria for both the mid-term
+evaluation point and the for the fully-completed project (that is: how
+will you know where you're half-way, and how will you know when you're
+done?)
+<p>
+What will you be working
 on, and how long will each part of the work take?  What objective results
 will be visible at each stage?  How will you know if you are ahead or
 behind schedule?   If you are unable to complete the project, are the
-results from part-way through still useful?   How?
+results from part-way through still useful?   How?
+<p>
+How will everybody know whether things are on-track at the half-way
+evaluation point?
+<p>
+Remember to mention any periods during the summer when you won't
+actually be available to work on the project (though remember,
+<a href="http://code.google.com/soc/2008/faqs.html#0.1_student_time";>
+the Summer of Code project is expected to be your main activity</a>).
+<p>
+<dt>Communication
+<dd>Our experience with earlier Summer of Code projects is that good
+communication is essential to students' success.  Students
+who communicate clearly and frequently with their mentor are more
+likely to be successful.   Please indicate the ways in which you will
+contact your mentor (and a schedule for doing it) to ensure that
+they're always aware of your progress.   While email is useful,
+real-time forms of contact help a lot.  Also, how will your mentor be
+able to see your code as it progresses?
+<p>
 <dt>Qualification
 <dd>Why did this project appeal to you?  How will you benefit from it?
 Why are you particularly suited to work on this?  What will you do
 once the project is "finished"?  Have you worked on any Free Software before?
+
+Of the skills that you will need to complete the project, which do you
+already have?   What will you need to lean?
 </dl>