Development Process

This wiki topic is meant to help people identify how their needs might be made to "fit" inside GNUMed

There are a few stages to what we would like to do:

1. develop use cases & decide how we want the functions to "work"
2. get the software written (refer to DevelopmentGuidelines)
3. try it out and feed back into the process

In deciding how we want functions to work we probably need to identify what most people would feel to be

1. very useful
2. useful in some situations, without impeding general usability
3. useful to some people but the implementation would give grief to others

"a" items should, & probably will, be implemented, but not all at once

• anyone is welcome & encouraged to implement any & all parts
• guiding "how the functions should work" are Richard's design documents
• these parts would all eventually go into the main trunk
• consensus on the most desirable path forward is desirable to better enable the 'active" people to collaborate
• develop in test_area, announce and keep pushing!

"b" items: anyone who really wants to get these done, is welcome to do so

• it may just be their passion of theirs, or vital to their use case
• it may not help others until later, if ever, but it is up to the developer
• if it does not interfere with anything, just extends it, it will be welcome into the main trunk

"c" like "b" can be developed in test-area, but should not go into the main trunk or should only go into some clearly identified subfolder in which optional widgets can be kept, and activated at the level of an individual gnumed installation, perhaps to replace default widgets. Kind of like the {richard-space, horst-space} choice. If it can be made to not interfere with a) or b) it will likely be accepted into the main trunk, too.

-- JamesBusser - 31 Dec 2005 (assisted by Karsten)