Proposed handing over topics

verify list from last calls:

• https://openimis.atlassian.net/wiki/spaces/OP/pages/4448714757

• https://openimis.atlassian.net/wiki/spaces/OP/pages/4452286858

Source management

• git teams

• git flow

• CI

• base concept

  • Versioned model / historyModel

  • ORM

  • cache

  • settings and security 

  • FE/BE interaction

  • FHIR facades and IG

  •  

business process ? (theoretically it should be done by someone else)

Other platforms

• Communication Platforms - openIMIS - openIMIS Wiki

• Lokalise Translation Management platform - openIMIS - openIMIS Wiki

• TestLink

• Discord

• Confluence Docs

•  

Support

• Service Desk process

• Jira Project and ticket

  •  

Handover notes for the discussion held on 18th July 2025:

https://github.com/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft+org%3Aopenimis+NOT+%22Bump%22+in%3Atitle+

Notes

• On Releases: We want to have the release done by the end of October

  • CI/CD puts everything together and the freeze works at that level not specific to modules

  • We still have an issue where we don’t have a good metric on what is a major change or minor change - it’s not always clear and needs good judgment

  • First two weeks during the freeze are for alpha testing

    • if that shows that some of the PRs are difficult, we don’t add them into the release

  • The release should have a good round of UAT

  • Sometimes there are features which are in beta but not impacting anything else

  • Priority is having something ready and quality by end of October

  • Link to active PRs excludes automated version bumps from bots: https://github.com/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft+org%3Aopenimis+NOT+%22Bump%22+in%3Atitle+

• On managing PRs

  • GitFlow workflow: Extended GitHub workflow - openIMIS - openIMIS Wiki

  • Question on whether there is a label on PRs that should be considered for the release or frozen - currently there isn’t

    • Before freeze we try to merge all the PRs, and test ahead of the time

  • Some contributors don’t add tests to their PRs despite recommendations

    • Sometimes maintainers do add the tests to the PRs - mostly for the backend at the moment as the frontend testing is still not in-place

  • Some PRs receive comments but don’t get addressed in time

  • Wait for week or end of week for changes to PRs to create new images for Docker images - to give room for updates/responses to comments

• Recommendation is to use conventional commits for the description

  • Nobody has used conventional commit for breaking changes, yet

• ON Github access to the openIMIS org.

  • Patrick will create the team on GitHub and assign person as owner of GitHub account

  • There are two high-level teams on the org, the main team is `product-team`

    • Teams are managed in a hierarchical manner

    • Child-teams are created under the main `product-team` 

    • There are teams for Developers and Students

      • There is a hierarchy for the teams under these

    • A new team has been created for SpeedyKom and Jembi under Developers

• On CI/CD

  • Use GitHub Actions for CI

  • There is a ci_assembly.yml workflow

    • Installs dependencies

    • Runs database migrations

    • Runs Django tests `—keepdb` flag specified to prevent running migrations for all the tests

    • 800 - 900 tests excited via the CI assembly action

    • Each module has a CI process that calls the CI module from the assembly and executes the CI

  • Separate ci_module.yaml workflow for module 

  • There is a sonarcloud scan pipeline that we may consider removing because it shows false positives - it was added by partners at SolDevelop

  • The GitHub action for docker-manual has option to give a custom openimis.json file that can be used to different images for docker but by default uses the openimis.json in the repo.

  • openimis-be_py is the repo that contains the CI workflows for the backend.

  • No fixtures yet in the testing process - there are helper functions for creating test data which help in the tests and this works well as it’s programmatic

  • Use Django migrations for migrations

    • Check that migrations are created ahead of the release

    • Django migrations should have dependencies specified where necessary

  • We use npm for frontend CI

    • Not yarn because it doesn’t work on gh action

    • Linter is setup on module level not at the frontend CI level

    • We use babel-eslint for the linting 

    • Node versions need to be checked to prevent issues in development

    • We use rollup for building the frontend

    • Each frontend module needs to have a “prepare” script in package.json with “npm run build” as the content