Changes between Initial Version and Version 1 of Developer/GSoC/ProjectManagement


Ignore:
Timestamp:
04/19/09 19:03:40 (15 years ago)
Author:
JoelSherrill
Comment:

New page

Legend:

Unmodified
Added
Removed
Modified

  • Developer/GSoC/ProjectManagement

    v1 v1  
     1= SoC Project Management =
     2
     3
     4
     5[[TOC(Developer/GSoC/ProjectManagement, depth=2)]]
     6
     7
     8Congratulations on being in the Summer of Code.  We hope this is a positive experience for you and the beginning of your involvement in our community.  Remember, we want your project to succeed.  Work with us and it will happen. We want to make this a fun and productive summer.
     9 
     10This page outlines some expectations on how we would prefer your project to be managed and interact with the community.  Hopefully this will make everything go smoothly and make your project visible to the entire community. 
     11
     12 *  Create a wiki page in the RTEMS Wiki dedicated to your project.
     13
     14 *  Create a project at http://code.google.com.  You have to make a final delivery to Google to trip the final payment so go ahead and be ready.
     15
     16 *  Create a public Google Calendar for your project so mentors and interested parties can track you.
     17
     18 *  Update the table in the SoC proposal section for now with links to the above so we can find them. [wiki:TBR/User/JoelSherrill JoelSherrill] will find a better place for them but this works for now.
     19
     20 *  Hopefully your effort will completely eliminate an Open Project.  Let's be hopeful and change the [wiki:Developer/OpenProjects Open Projects] entry for your project into a link to a dedicated Wiki page.  Move the current content to that new page.  Update the page as it moves from idea to reality.  At the end, your page may have howto, technical details, etc about the project.  But it won't be a wish anymore. :)
     21
     22 *  Be sure to communicate frequently and publicly.  Use the RTEMS Users Mailing List as much as possible.  This gives you access to more experts in more time zones.
     23
     24 *  Do NOT struggle or waste time.  If you have a blocking issue, ask for help.  There are no bonus points for suffering.
     25
     26 *  Do NOT disappear.  If you have a personal issue or go on vacation with no Net access, let us know.  We can spend the time reviewing code and give you advice on what you can do offline.  But critically if you don't tell us, we have to assume that you are dropping out.
     27
     28 *  IRC is good but currently it isn't logged and only a small part of the community is using it.
     29
     30 *  Avoid dumping large amounts of code on your mentor.  Submit incrementally.  For example, some projects involve implementing more POSIX APIs.  Those projects can submit a stub of the methods with "obvious" parameter checking per the standard, the associated .h files, additions to the "psxhdrs" test, a new test verifying the error cases, and user documentation.  This can all be done VERY early in the project while the design of the implementation is still being investigated.  Then subsequent patches can flesh out the implementation.  Similarly new BSPs can be submitted as soon as they run hello world.
     31
     32 *  Work from CVS as much as possible.  Assume your development computer could disappear and you would have to recreate your work from public sources.  This keeps you honest. 
     33
     34 *  Submit any needed patches to other projects.