|
| 1 | +--- |
| 2 | +layout: default |
| 3 | +title: SoC 2014 Applicant Microprojects |
| 4 | +--- |
| 5 | + |
| 6 | +## Introduction |
| 7 | + |
| 8 | +It is strongly recommended that students who want to apply to the Git |
| 9 | +project for the Summer of Code 2014 should submit a small code-related |
| 10 | +patch to the Git project as part of their application. Think of these |
| 11 | +microprojects as the "Hello, world" of getting involved with the Git |
| 12 | +project; the coding aspect of the change can be almost trivial, but to |
| 13 | +make the change the student has to become familiar with many of the |
| 14 | +practical aspects of working on the Git project: |
| 15 | + |
| 16 | +* Downloading the source code: clone the repository using the |
| 17 | + [Git via Git](http://git-scm.com/downloads) instructions and read |
| 18 | + the `README` file. |
| 19 | + |
| 20 | +* Build the source code: this is described in the file `INSTALL`. |
| 21 | + |
| 22 | +* Glance over our coding guidelines in the file |
| 23 | + `Documentation/CodingGuidelines`. We take things like proper code |
| 24 | + formatting very seriously. |
| 25 | + |
| 26 | +* Read about the process for submitting patches to Git: this is |
| 27 | + described in `Documentation/SubmittingPatches`. |
| 28 | + |
| 29 | +* Making the actual change. |
| 30 | + |
| 31 | +* Run the test suite: this is described in the file `t/README`. (If |
| 32 | + you have added new functionality, you should also add tests, but |
| 33 | + most microprojects will not add new functionality.) |
| 34 | + |
| 35 | +* Commit your change. Surprise: we use Git for that, so you will need |
| 36 | + to gain at least |
| 37 | + [a basic familiarity](http://git-scm.com/documentation) with using |
| 38 | + Git. Make sure to write a good commit message that explains the |
| 39 | + reason for the change and any ramifications. Remember to add a |
| 40 | + Signed-off-by line (see the coding guidelines for more information). |
| 41 | + |
| 42 | +* Submit your change to the Git mailing list. For this step you |
| 43 | + probably want to use the commands `git format-patch` and `git |
| 44 | + send-email`. |
| 45 | + |
| 46 | +* Expect feedback, criticism, suggestions, etc. from the mailing list. |
| 47 | + |
| 48 | + *Respond to it!* and follow up with improved versions of your |
| 49 | + change. Even for a trivial patch you shouldn't be surprised if it |
| 50 | + takes two or more iterations before your patch is accepted. *This |
| 51 | + is the best part of the Git community; it is your chance to get |
| 52 | + personalized instruction from very experienced peers!* |
| 53 | + |
| 54 | +The coding part of the microproject should be very small (say, 10-30 |
| 55 | +minutes). We don't require that your patch be accepted into master by |
| 56 | +the time of your formal application; we mostly want to see that you |
| 57 | +have a basic level of competence and especially the ability to |
| 58 | +interact with the other Git developers. |
| 59 | + |
| 60 | +When you submit your patch, please mention that you plan to apply for |
| 61 | +the GSoC. This will ensure that we take special care not to overlook |
| 62 | +your application among the large pile of others. |
| 63 | + |
| 64 | +## Ideas for microprojects |
| 65 | + |
| 66 | +The following are just ideas. Any small code-related change would be |
| 67 | +suitable. Just remember to keep the change small! It is much better |
| 68 | +to finish a small but complete patch than to try something too |
| 69 | +ambitious and not get it done. |
| 70 | + |
0 commit comments