Contribution guidelines

Code of Conduct

openIMIS Initiative has adopted the Contributor Covenant as its Code of Conduct, and we are asking project participants to adhere to it. Please read the full text here.

Issue Tracker

Please ensure that we got enough information to make

Open Development

All work on openIMIS happens directly on GitHub. Both core team members and external contributors send pull requests which go through the same review process.

Semantic Versioning

React follows semantic versioning. We release patch versions for critical bug fixes, minor versions for new features or non-essential changes, and major versions for any breaking changes. When we make breaking changes, we also introduce deprecation warnings in a minor version so that our users learn about the upcoming changes and migrate their code in advance. Learn more about our commitment to stability and incremental migration in our versioning policy.

Every significant change is documented in the change log of the repository of each component in

Branch Organization

Submit all changes to the develop branch. We use separate branches for development (develop branch) or for upcoming releases. We do our best to keep master in good shape, with all tests passing.

Code that lands in develop must be compatible with the latest stable release. It may contain additional features, but no breaking changes. We should be able to release a new minor version from the tip of develop at any time.

Architectures to follow to design modules

Code convention  


All variables must be named using UK English language (except for FHIR module because US English terminology). Wherever possible, use Glossary names: If you find different uses of a word, feel free to correct or comment the glossary.

JSON (mirror the guidelines for naming JavaScript identifiers)

  • Property names should be meaningful names 

  • Property names must be camel-cased, ASCII strings

  • The first character must be a letter

  • Subsequent characters can be a letter, a digit, an underscore

  • Reserved JavaScript keywords should be avoided 


Translations are managed through Lokalized.

Coding standard used


Django contribution:

Python Style Guide:


ReactJS contribution:

Material Design:

JavaScript Standard Style Guide:

Mobile app

Google Java Style Guide:

Google JavaScript Style Guide:

Getting started

Front end module are required to change the interface, it doesn’t mean that you need a matching backend module; e.g a portal for some user

a template module can be found here

Backend is required to manage a group of entity; e.g. claim and claim item (item part of the claim).

No template is available because the Django “create module” is enough to start.

Document your architecture

if possible, user and other developers will appreciate such documentation in your code repository

  • database diagram: database.txt/database.png

    • any kind of documentation helps, a free and simple way is to use plantuml

    • Please don’t call your tables with a generic name like “Item“ or “flags“ …

    • Please add your module name as a prefix of you table.

  • workflows / use case covered by your module: workflows.txt

    • AS a <role> I <do_action> so I get<result>


Global openIMIS guidelines or per programming language?

  • Better have per language, but define overlaps/interactions

FHIR is already guiding, GRAPH-QL is more open


Did you encounter a problem or do you have a suggestion?

Please contact our Service Desk

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.