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.
Please ensure that we got enough information to make
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.
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.
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.
Backend (API) Target Architecture
https://openimis.atlassian.net/wiki/spaces/OP/pages/586448901/Frontend+s+Target+Architecture
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.
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. Translation Management platform
Django contribution: https://docs.djangoproject.com/en/dev/internals/contributing/
Python Style Guide: https://www.python.org/doc/essays/styleguide/
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
Google Java Style Guide: https://google.github.io/styleguide/javaguide.html
Google JavaScript Style Guide: https://google.github.io/styleguide/jsguide.html
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.
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>
Global openIMIS guidelines or per programming language?
Better have per language, but define overlaps/interactions
FHIR is already guiding, GRAPH-QL is more open