January 12 2016

Attendance Information

1/12/2016

7AM PST - Seattle

10AM EST - New York, DC

5PM CEST - CEST, Geneva, Copenhagen, Joburg

6PM EAT - Dar

Link: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M0J70ISXIREJUUEYZKP26P8RPW-3O29&rnd=10428.504769

Meeting Number: 196 307 742

Host Key: 707674

Audio Connection: +1-415-655-0001

AGENDA

MINUTES

In attendance: Kevin Cussen, Tenly Snow, Gaurav Bhattacharya, Renee Orser, Brian Taliesin, Ashraf Islam, Lakshmi Balachandran

Tenly Snow (Deactivated) described her new role on OpenLMIS. Everyone else on the product committee introduced themselves as well.

Kevin Cussen (Deactivated) introduced feedback from the VR dev team on differing levels of effort in implementing a modular UI. All of these assume the UI has been modularized. The continuum is as follows (from least to most level of effort): 

• Simple UI changes done by forking UI module, rewriting code and deploying the unique module
• Simple UI changes done by hybrid change (i.e. modifying css, placing logo's in specified places in the directory structure, etc.)
• Simple UI changes done at run-time by an admin page 

Brian Taliesin asked about whether for any of these approaches you would have the ability to create hooks into back-end functionality. Kevin Cussen (Deactivated) believes that similar to present, a developer would be required to access any logic through the UI. Brian Taliesin described the possibility of running OpenLMIS headless (as a service) and how the idea of OpenLMIS as a service rather than a product is new. While this is a possibility, a reference UI module will be supplied for all distributions going forward by default. 

Renee Orser (Unlicensed) prefers the idea of a configuration file. Using this approach, implementers can then share their configuration files with others. Furthermore, she votes against the idea of an admin screen because in her experience it quickly grows clunky and outdated by trying to satisfy diverse users. Brian Taliesin agrees with this assessment.

Ashraf Islam (Unlicensed) asks which option would be closest to the idea of skinning in Salesforce?

Kevin Cussen (Deactivated) replied that this is likely option 2. By doing the majority of your simply UI configurations in a file, you are enabled to take the configuration file and image folder from another implementation and plop them down in your instance in order to copy their own look and feel. Based on this assessment, Ashraf Islam (Unlicensed) and Gaurav Bhattacharya (Unlicensed) agree with approach #2.

Gaurav Bhattacharya (Unlicensed) added "To the extent possible we should aim for something to minimize developer requirement on this. When you say UI, I actually hear "look and feel" and "look and feel" is what is most important to the Ministries we support."

Kevin Cussen (Deactivated) linked the current Re-Architecture guide to the group. Informed the committee that the next version (v2) should be available within the next week and that he will send out an email with it attached when it is. V2 is based on feedback internally, from funders, partners, and other HIS Open-source projects that have undergone similar re-architectures. 

Kevin Cussen (Deactivated) informed the group that the Stock Management sub-module has been incorporated into the "2.0" branch. Furthermore, the "2.0" branch is no longer auto-merging from VIMS. The code standards document is published on Github and very soon (likely within the week) these standards will begin to be enforced for pull requests to the "2.0" branch. 

No-one on the product committee had seen these standards, however there was interest. Kevin Cussen (Deactivated) sent out a link immediately after the call.

Feedback on migration path 2-pager.

Lakshmi Balachandran and Renee Orser (Unlicensed) believed the document encompassed their thinking and discussions on a migration path. No dissent. Ashraf Islam (Unlicensed) did not read document, so he agreed to read it after the call and provide feedback via Word - Review function to the Product Committee Google Group.

Gaurav Bhattacharya (Unlicensed) asked what happens if functionality is removed that is part of the core?

Kevin Cussen (Deactivated) replied that the definition of "core" is that functionality which fits within the domain of OpenLMIS and that is written in a globally applicable way. These features will stay in OpenLMIS. If one or the other is not true, then they will be cut in which case the implementer will need to rewrite the feature as a module. See the 2-pager (attached below) or re-arch guide for specifics. 

Kevin proposed that new features being built in OpenLMIS by specific partners should be demoed for the product committee when the features are complete / nearing completion. Examples of features that fit this are CCE in VIMS, ColdTrace integration in Moz (VR), and potentially Kits in Moz. (TW). This will help members be aware of features entering the system as well as fostering a sense of community. 

No dissent from committee. Specific support from Kevin Cussen (Deactivated), Gaurav Bhattacharya (Unlicensed), and Brian Taliesin.

Began socializing the idea of deprecation. In reaching "2.0", we'll be creating a central toggle file where certain features that fit the domain of OpenLMIS and are implemented in a global fashion are toggled on by default and those that do not meet this criteria are toggled off. If a feature is toggled off by default, this should be a signal that this feature will be cut in the future. Implementations or countries that depend on this feature and would like to migrate should take advantage of this signal to:
1) Investigate the LOE of re-writing this feature as a module

2) Request an extension point from the global team (if they choose to migrate and would like to rewrite the feature) - this request will be fast tracked to assist their re-write

No dissent on this approach. 

RECORDING

ADDITIONAL READING