40 | | '''Problem:''' Over the years of participating in Summers of Code, the RTEMS project has noticed some recurring themes with Summer of Code projects: |
41 | | # Projects would not meet the needs of the RTEMS project (and so would not be upstreamed). |
42 | | # Projects would be completed in such a way as they were not maintainable (external projects would make use of the RTEMS build system [http://home.gwu.edu/~cssmith/LuaRtems/ see:LUA], as opposed to using the external software's own build system [http://git.rtems.org/rtems-addon-packages/ see:rtems-addon-packages]), or projects would be hardcoded based on the RTEMS tree at one point in time see:[wiki:Building/MingwTools BuildingMingwTools] the NSIS installer. |
43 | | # Projects would be partially done without enough information for the next summer of code (or google code in) student to continue the work. For example: a change would be made for one architecture, but the way to generalize for the others was not documented. |
44 | | # Projects would be submitted as one giant patch at the end of summer, if rtems-devel reviewed the patch, the student would be busy with schoolwork when it was time to make changes. |
45 | | # Projects were not documented well enough for someone to verify it works. |
46 | | # Projects would be done over and over again (instead of being new) |
| 39 | '''Problem:''' |
| 40 | Over the years of participating in Summers of Code, the RTEMS project has noticed some recurring themes with Summer of Code projects: |
| 41 | 1. Projects would not meet the needs of the RTEMS project (and so would not be upstreamed). |
| 42 | 1. Projects would be completed in such a way as they were not maintainable (external projects would make use of the RTEMS build system [http://home.gwu.edu/~cssmith/LuaRtems/ see:LUA], as opposed to using the external software's own build system [http://git.rtems.org/rtems-addon-packages/ see:rtems-addon-packages]), or projects would be hardcoded based on the RTEMS tree at one point in time see:[wiki:Building/MingwTools BuildingMingwTools] the NSIS installer. |
| 43 | 1. Projects would be partially done without enough information for the next summer of code (or google code in) student to continue the work. For example: a change would be made for one architecture, but the way to generalize for the others was not documented. |
| 44 | 1. Projects would be submitted as one giant patch at the end of summer, if rtems-devel reviewed the patch, the student would be busy with schoolwork when it was time to make changes. |
| 45 | 1. Projects were not documented well enough for someone to verify it works. |
| 46 | 1. Projects would be done over and over again (instead of being new) |
48 | | '''Solution:''' In the proposal the following MUST be included: |
49 | | # A paragraph explaining what the project is trying to accomplish |
50 | | ## What is the core problem being solved? |
51 | | ## Why is this better than what we have already done? |
52 | | # A sentence explaining how this project could be maintained (given developers have little time to maintain the code) |
53 | | # Make documenting how the next summer of code student will pick up with developing the project in later years a project deliverable |
54 | | # Break the project up into increments, so that if time runs out, each increment could be upstreamed, or at least written up on a wiki page so the next year's student could get farther faster. |
55 | | # Make writing a tutorial to include a deliverable |
56 | | # email the first draft to rtems-devel@rtems.org for feedback, and make adjustments before submitting '''(THIS IS A CRITICAL REQUIREMENT!!!)''' |
| 48 | '''Solution:''' |
| 49 | In the proposal the following MUST be included: |
| 50 | |
| 51 | 1. A paragraph explaining what the project is trying to accomplish |
| 52 | a. What is the core problem being solved? |
| 53 | a. Why is this better than what we have already done? |
| 54 | 1. A sentence explaining how this project could be maintained (given developers have little time to maintain the code) |
| 55 | 1. Make documenting how the next summer of code student will pick up with developing the project in later years a project deliverable |
| 56 | 1. Break the project up into increments, so that if time runs out, each increment could be upstreamed, or at least written up on a wiki page so the next year's student could get farther faster. |
| 57 | 1. Make writing a tutorial to include a deliverable |
| 58 | 1. Email the first draft to rtems-devel@rtems.org for feedback, and make adjustments before submitting '''(THIS IS A CRITICAL REQUIREMENT!!!)''' |
59 | | # We really need ''something else specific'' done instead... could you do ''something else specific''? |
60 | | # What's the maintainence plan? |
61 | | # How will we test it? |
62 | | # We did this already... How is this an improvement? |
63 | | # This is too much for you to complete in a summer... please remove these pieces from your proposal |
| 61 | 1. We really need ''something else specific'' done instead... could you do ''something else specific''? |
| 62 | 1. What's the maintainence plan? |
| 63 | 1. How will we test it? |
| 64 | 1. We did this already... How is this an improvement? |
| 65 | 1. This is too much for you to complete in a summer... please remove these pieces from your proposal |