Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

Changes between Version 7 and Version 8 of Developer/GSoC/ProjectManagement


Ignore:
Timestamp:
02/26/14 00:13:50 (10 years ago)
Author:
Gedare
Comment:

/* update content to make current */

Legend:

Unmodified
Added
Removed
Modified

  • Developer/GSoC/ProjectManagement

    v7 v8  
    22
    33
    4 {{Outdated}}
    54
    65[[TOC(Developer/GSoC/ProjectManagement, depth=2)]]
    76
    87
    9 Congratulations 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.
     8Congratulations on being accepted to the Summer of Code! We hope this is a positive experience for you and we want to help you have fun and for your project to succeed.
    109
    11 NOTE: Melange will allow editing of projects once they are announced.  There will be other capabilities.  Once we see that, we can evaluate how best to leverage it.
     10This page outlines expectations for how you will manage your project and interact with the community. Hopefully these processes will make your project visible to the entire community and keep you on track for a successful completion.
    1211
    13 This 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. 
     12 *  Create a wiki page in the RTEMS Wiki dedicated to your project if none exists, and change the [wiki:Developer/OpenProjects Open Projects] entry for your project into a link to your project's Wiki 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.
    1413
    15  *  Create a wiki page in the RTEMS Wiki dedicated to your project.
     14 *  Create a code repository at [http://github.com] for your project. If your project is modifying one of the RTEMS repositories, you should fork that repository from [http://github.com/RTEMS]. You will use github to keep your work publicly available all summer long. You should commit and push all of your work to github on a '''daily basis''' any time that you make changes to your code.
    1615
    17  *  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.
     16 *  Create a public Google Calendar for your project so mentors and interested parties can track your schedule. Add deliverables and other deadlines from your proposal to your calendar.
    1817
    19  *  Create a public Google Calendar for your project so mentors and interested parties can track you.
     18 *  Update the table in the SoC proposal section for now with links to the above.
    2019
    21  *  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.
     20 *  Continue to communicate frequently and publicly.  Use the RTEMS Development Mailing List as much as possible.  This gives you access to more experts in more time zones than direct connections with your mentors or on IRC.
    2221
    23  *  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. :)
     22 *  Do NOT struggle needlessly.  If you have a blocking issue, ask for help.  There are no bonus points for suffering.
    2423
    25  *  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.
     24 *  Do NOT disappear.  If you need a leave of absence let us know.  We can spend time to give you advice on what you can do offline.  If you disappear and don't tell us, we have to assume that you are dropping out.
    2625
    27  *  Do NOT struggle or waste time.  If you have a blocking issue, ask for help.  There are no bonus points for suffering.
     26 *  Avoid dumping large amounts of code on your mentor.  and you should submit patches incrementally to the rtems-devel mailing list for a broader audience.
    2827
    29  *  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.
    30 
    31  *  IRC is good but currently it isn't logged and only a small part of the community is using it.
    32 
    33  *  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.
    34 
    35  *  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. 
    36 
    37  *  Submit any needed patches to other projects.
     28 *  If your project involves projects other than RTEMS, submit patches to those projects according to how their community manages patches. If your project needs to submit patches to an FSF project, you need to get your FSF paperwork ready. Talk to your mentor about this possibility.
    3829
    3930----
    … …  
    4637When Melange supports it, we will assign each project a backup or secondary mentor. 
    4738
    48 If you have any difficulty contacting your mentor, email [wiki:TBR/User/JoelSherrill  Joel Sherrill] and [wiki:ChrisJohns  Chris Johns].  If you do not get a response in a reasonable level of time 48-72 hours to allow for holidays and weekends, then bring the issue up on the RTEMS Users Mailing List.
     39If you have any difficulty contacting your mentor, email [wiki:TBR/User/JoelSherrill  Joel Sherrill], [wiki:ChrisJohns  Chris Johns], and [wiki:GedareBloom_  Gedare Bloom].  If you do not get a response in a reasonable time, say 48-72 hours to allow for holidays and weekends, then bring the issue up on the RTEMS Development (rtems-devel) Mailing List.
    4940</blockquote>