Changes between Version 68 and Version 69 of GSoC/2013

Timestamp:

08/26/13 02:32:32 (11 years ago)

Author:

C Rempel

Comment:

GSoC/2013

@@ -56 +56 @@
  *  [http://rtems.org/onlinedocs/doc-current/share/rtems/html/ RTEMS User Documentation (git daily)]
 
-Be sure to add yourself to the table below.
+Be sure to add yourself to the table below.==  Writing Proposals and Doing Projects  ==
+
+'''Problem:''' Over the years of participating in Summers of Code, the RTEMS project has noticed some recurring themes with Summer of Code projects: 
+# Projects would not meet the needs of the RTEMS project (and so would not be upstreamed).
+# 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.
+# 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.
+# 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.
+# Projects were not documented well enough for someone to verify it works.
+# Projects would be done over and over again (instead of being new)
+
+'''Solution:''' In the proposal the following MUST be included:
+# A paragraph explaining what the project is trying to accomplish
+## What is the core problem being solved?
+## Why is this better than what we have already done?
+# A sentence explaining how this project could be maintained (given developers have little time to maintain the code)
+# Make documenting how the next summer of code student will pick up with developing the project in later years a project deliverable
+# 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.
+# Make writing a tutorial to include a deliverable
+# email the first draft to rtems-devel@rtems.org for feedback, and make adjustments before submitting '''(THIS IS A CRITICAL REQUIREMENT!!!)'''
+
+Expect the following questions from the email list:
+# We really need ''something else specific'' done instead... could you do ''something else specific''?
+# What's the maintainence plan?
+# How will we test it?
+# We did this already... How is this an improvement?
+# This is too much for you to complete in a summer... please remove these pieces from your proposal
+
+In addition, the RTEMS project will furnish not only a mentor, but a co-mentor, and one or two additional people to help with keeping the project on a topic that is both meaningful for the student, and for RTEMS.
 = Project Ideas =