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

Issue tracking

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 Sources.

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

Backend (API) Target Architecture

Frontend(s) Target Architecture

Data Target Architecture

Code convention  

Variables

All variables must be named using UK English language (except for FHIR module because US English terminology). Wherever possible, use Glossary names: Glossary. 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

Translations are managed through Lokalized. Translation Management platform

Coding standard used

backend

Django contribution: https://docs.djangoproject.com/en/dev/internals/contributing/

Python Style Guide: https://www.python.org/doc/essays/styleguide/

frontend

ReactJS contribution: https://reactjs.org/docs/how-to-contribute.html

Material Design: https://material.io/develop/android/docs/contributing/

JavaScript Standard Style Guide: https://github.com/standard/standard

Mobile app

Google Java Style Guide: https://google.github.io/styleguide/javaguide.html

Google JavaScript Style Guide: https://google.github.io/styleguide/jsguide.html

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

https://github.com/openimis/openimis-fe_js/blob/master/README.md

a template module can be found here https://github.com/openimis/openimis-fe-template_js

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

https://github.com/openimis/openimis-be_py/blob/master/README.md

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 https://www.planttext.com/

    • 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>

Questions

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. https://creativecommons.org/licenses/by-sa/4.0/