Wordsmith the microproject intro.

Author: mhagger

SoC-2014-Microprojects.md

@@ -6,8 +6,8 @@ title: SoC 2014 Applicant Microprojects
 ## Introduction
 
 It is strongly recommended that students who want to apply to the Git
-project for the Summer of Code 2014 should submit a small code-related
-patch to the Git project as part of their application. Think of these
+project for the Summer of Code 2014 submit a small code-related patch
+to the Git project as part of their application. Think of these
 microprojects as the "Hello, world" of getting involved with the Git
 project; the coding aspect of the change can be almost trivial, but to
 make the change the student has to become familiar with many of the
@@ -26,7 +26,8 @@ practical aspects of working on the Git project:
 * Read about the process for submitting patches to Git: this is
  described in `Documentation/SubmittingPatches`.
 
-* Making the actual change.
+***Making the actual change.** (Funny, this is the only part they
+ teach you about in college.)
 
 * Run the test suite: this is described in the file `t/README`. (If
  you have added new functionality, you should also add tests, but
@@ -36,8 +37,10 @@ practical aspects of working on the Git project:
  to gain at least
 [a basic familiarity](http://git-scm.com/documentation) with using
  Git. Make sure to write a good commit message that explains the
- reason for the change and any ramifications. Remember to add a
- Signed-off-by line (see the coding guidelines for more information).
+ reason for the change and any ramifications. Remember to make sure
+ that you agree with our "Developer's Certificate of Origin" (whose
+ text is contained in `Documentation/SubmittingPatches`), and to
+ signify your agreement by adding a `Signed-off-by` line.
 
 * Submit your change to the Git mailing list. For this step you
  probably want to use the commands `git format-patch` and `git
@@ -48,8 +51,8 @@ practical aspects of working on the Git project:
 *Respond to it!* and follow up with improved versions of your
  change. Even for a trivial patch you shouldn't be surprised if it
  takes two or more iterations before your patch is accepted. *This
- is the best part of the Git community; it is your chance to get
- personalized instruction from very experienced peers!*
+ is the best part of participating in the Git community; it is your
+chance to get personalized instruction from very experienced peers!*
 
 The coding part of the microproject should be very small (say, 10-30
 minutes). We don't require that your patch be accepted into master by
@@ -65,8 +68,8 @@ your application among the large pile of others.
 
 The following are just ideas. Any small code-related change would be
 suitable. Just remember to keep the change small! It is much better
-to finish a small but complete patch than to try something too
-ambitious and not get it done.
+for you to finish a small but complete change than to try something
+too ambitious and not get it done.
 
 1. Rewrite `git-compat-util.h:skip_prefix()` as a loop, so that it
  doesn't have to scan through the `prefix` string twice.