Changes between Version 20 and Version 21 of Developer/Contributing

Jan 16, 2014, 4:11:33 PM (6 years ago)

Make a start on suggestions for those wanting to contribute to RTEMS generally


  • Developer/Contributing

    v20 v21  
    1010There are certain legal requirements and [wiki:Developer/Coding/Conventions Coding Conventions] which all contributions must meet.  For in-source documentation please have a look at the [wiki:Developer/Coding/Doxygen Doxygen recommendations].
     12If you'd like to contribute in general but aren't sure how you might best do that, see [wiki:#How_can_I_help? How can I help?]
    1113= Legal Requirements =
    5456Everything listed here still applies if you can check in the patch without further approval under the RTEMS write access policies.
     57= How can I help? =
     60Firstly, thanks for your interest in contributing! There's plenty you can do to help - and you don't need to be an expert coder, either.
     62Don't be afraid to announce your interest on the [wiki:RTEMSMailingLists_  rtems-users mailing list] or to ask questions to help you along!
     64Here're some ideas for work that'd be really useful to RTEMS users. It's non-exhaustive, and largely cobbled together from what's been suggested over time (in fact, one way you might contribute is to update this list with ideas that (for example) have been raised on the mailing lists).
     65= Non-coding =
     68 *  Documentation - there can (almost) never be too much documentation! Coding types are often accused of neglecting it, but it can be the most important part of a piece of work, particularly for assisting new users, either of RTEMS generally or of a particular feature
     69  *  Read documentation and Wiki articles and try to ensure they're
     70   *  Still relevant and up-to-date
     71   *  Clear, concise and phrased as well as possible
     72  *  Translate documentation
     73  *  Migrate documentation, "where appropriate", from a Wiki article to more formal documents, such as the [ RTEMS Getting Started] guide
     74  *  Update the RTEMS Wiki, which can be a relatively accessible way to have a significant impact on the RTEMS community, particularly assisting new users. First, [wiki:Special:RequestAccount_  Request a Wiki account], then, for instance:
     75   *  Add "How To" articles on:
     76   * * Application build systems (might be easier with some coding knowledge) - [ Make] and [ WAF] templates, examples and walkthroughs, for instance, can really help new users find their feet and develop the foundation for the application afresh
     77   *  Correct spelling errors, broken links and so on
     78   *  Unify BSP articles - which at the moment differ substantially from article to article - for example, to list RTEMS features available / not available
     79   *  Peruse the [ rtems-users mailing list archives] for areas in need of clarification
     80  *  The [ RTEMS Getting Started] guide
     81   *  Doesn't mention the (very helpful) [wiki:RTEMS_Source_Builder_  RTEMS Source Builder]
     82   *  Is generally a bit thin in the post-RTEMS-setup stages, perhaps where it matters most!
     83   *  Doesn't explain that RTEMS is a library that an application is linked against to create a single binary - this can be confusing for users of other RTOSs that operate differently
     84 *  [ Problem Reports]
     85  *  Problem Reports, or ''PRs'' are submitted by users to raise attention to a deficiency. Sometimes they're out-of-date and the problem has since been fixed - it can be very helpful to confirm this, perhaps by attempting to reproduce it. Sometimes PRs may have been mis-filed (for example, an RTEMS Source Builder-related problem might be filed under RTEMS, hindering the appropriate people from being alerted)
     86 *  Web site - suggest and/or prototype improvements to the [ RTEMS Web site]
     87= Coding =
     90 *  User assistance
     91  *  Hang out on the [wiki:RTEMS_IRC_  RTEMS IRC channel], subscribe to the [wiki:RTEMSMailingLists_  rtems-users mailing list] and assist others where you can
     92 *  Fix build warnings - build RTEMS, note, address any submit patches for warnings that are generated
     93 *  Larger, longer-term projects:
     94  *  Remote GDB support for BSPs that lack it (e.g., ''mvme3100'')
     95  *  CFI-standard flash device interface