Release a “LibreHealth Toolkit 1.12” (or similar name), importantly, with “Long Term Support (LTS)”. Commit to supporting it for 2 years with security & some bug fixes, etc.
Announce availability of a “LibreHealth Toolkit 2.0 Beta” to be released by end of July with new features and cutting-edge development.
Commit (announced or unannounced) to updating bug/features tickets in OpenMRS JIRA with links to the “mirrored” issue in LibreHealth, and updating those OpenMRS tickets when they’re fixed/implemented in LibreHealth.
Developed in cooperation with a friend who understands the Health IT landscape. Your thoughts?
I agree with the first two and agree these should be part of our release strategy. But to be able to do the LTS correctly, we need to change the way the QA/bug tracking/triaging process is handled. I have never understood OpenMRS reluctance to do integration tests at the UI level. There were good contributions from Thoughtworks devs using Selenium that were never adopted. Nor were many performance testing processes followed. I think we should use saucelabs.com and make sure things work at the UI level.
I don’t quite understand how the 3. will be actualized. Should we update the OpenMRS JIRA directly, or create a copy of tickets we want to work on into LibreHealth issue tracker. The triaging process is broken because user interaction is missing and prioritization is difficult to do by a remote/offsite developer.