Dashboard > DHIS-2 > ... > DHIS 2 development > Standards for coordination of development
  DHIS-2 Log In | Sign Up   View a printable version of the current page.  
  Standards for coordination of development
Added by Ola Hodne Titlestad, last edited by Lars Helge Ă˜verland on Feb 06, 2008  (view change)
Labels: 
(None)

These standards were defined at the Dehli workshop in January 2008.

Core development

Core development means development that affects the data model, the database, or core functionality, in general functionality that affects other parts of the system significantly. One example is the multi-dimensional data element model.

  1. Set global release dates: We need to plan ahead and identify global release dates, which are dates when production ready versions with specified functionality needs to be released to satisfy the requirements of an employer.
  2. Meet global release dates: Core development and testing needs to take place between global release dates. Core development cannot take place over a global release date as the system will be inconsistent.

Module development

Module development means development of functionality that extends the system and doesn't affect the existing code. One example is the data validation module.

  1. Put your code in the repository: Put your code in the repository in order to avoid losing it, e.g. if your computer is broken or stolen.
  2. Develop new modules in branches: Don't develop modules directly in trunk as we don't want to include unfinished functionality in releases.
  3. Communicate what you do: It is necessary that the project management and core developers are updated on the current development and are able to evaluate your work. It is also helpful to let other developers have a look and comment on your work. Communication can take place on the developer's mailing list, mails directly to core developers, and through CVS log messages.
  4. Develop general functionality: If possible, develop general solutions to local requirements. If a requirement appears in your country, it is likely to appear in other countries as well. By making general solutions you contribute to improving the global system. Also, you avoid the hassle of maintaining and merging local branches.
  5. Merge completed functionality intro trunk: When the general functionality has been completed and approved by the project management, it should be merged into trunk. This way it can benefit and improve the global system.

Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.6 Build:#812 Aug 06, 2007) - Bug/feature request - Contact Administrators