Versions Compared

Old Version 21

changes.mady.by.user Craig Appl (Unlicensed)

Saved on

compared with

New Version Current

changes.mady.by.user Mary Jo Kochendorfer (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Call Information

  • 09:00 PDT - Seattle
  • 12:00 EDT - New York, DC
  • 18:00 CAT - Zambia/Malawi (UTC+2)
  • 19:00 EAT - Tanzania/Kenya (UTC+3)


Last Meeting Notes: PC: Feb 27 2018

AGENDA

Item

Lead (Time)

Notes

Software Development Update

  • Roadmap: Living Product Roadmap
  • Current sprint: Backlog Grooming Sprint 48
  • Upcoming sprint: Backlog Grooming Sprint 49
    • Fixing blocker and critical bugs (see bug reporting process and prioritization criteria here)
    • Full regression testing
  • Release: Aiming for  but will depend on if there are blocker bugs found in the Release Candidate process. Please review the documentation on an overview of the release process.
    • Test Plan (3.3 Regression & Release Candidate Test Plan): Community members are welcome to join the Release Candidate testing process.
    • Reminder: Batch Approval will continued to be released in its beta form and not accessible via UI given the performance and design issues. 
  • Reporting: Showcases will be every two weeks an hour before this call. Showcases are recorded here. Updated documentation on Reporting and Analytics on what has been completed and login information to superset.


Mary Jo Kochendorfer (Deactivated)

  • This release will also have a release candidate process. Please sign up for slack and let us know when the release candidate is available for testing. The QA channel on slack is the location to be notified of testing.
  • Reviewed the 3.3 Regression & Release Candidate Test Plan link
  • Question:
    • Are only blockers and critical bugs fixed between Phase 1 and 2 tests?
    • Has response criteria for bug levels been defined as a community?
      • This is the conversation for today (smile)
      • In the future, we should have a product committee discussion around this.


Review priority of 

Jira Legacy
serverSystem JIRA
serverId448ba138-230b-3f91-a83e-16e7db1deed1
keyOLMIS-3147


Nuran Idris (Unlicensed)
  • Nuran communicated the work around email notifications.
  • This work was originally funded by the GAP project, so it was not prioritized in 3.3
  • The gap process is currently in a holding pattern
  • Matt Kumbuyo shared the problem:
    • At the warehouse level, users are getting 1000 emails per day every time a button is clicked.
    • The emails aren't serving the intended purpose because there are too many emails. Instead, the user opens the system.
    • There is one user receiving all of the notifications
  • Ashraf:
    • eLMIS includes a user profile option that allows users to determine their email preferences.
    • We should determine if the user is part of many supervisory groups.
  • This will be a key discussion after the 3.3 release, especially in the GAP deliverable project.

Intersection of non-functional requirements and desired features. Recently we discovered a arbitrary constraint on number of lineItems which highlights the need of clearly stating the non-functional targets around performance and how implementers use certain features may degrade performance. Discuss how feature requirements can come into conflict. For example, offline and performance trade-off.

Background Context

There is a request for a new non-functional requirement to support larger data sets.

  • There was previously an arbitrary limit of 2000 products. This was never intentional. It was a bug identified and fixed when the Malawi implementation loaded in a larger product list. However, loading in larger product lists demonstrated that performance degrades as the lists grow longer. Large product lists linearly impact load times (3x the list, 3x the loading wait).
  • Patch Release   - 
    Jira Legacy
    serverSystem JIRA
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-4192
  • With the increase in products, combined with the desire for offline access to all these products, there are performance concerns.

To discuss:

  • Question: In TZ, what is the current scope of Non-Full Supply products? Is there a limit on the number which are available? When does the server call happen for NFS?
  • What size of product lists do we, OpenLMIS, want to optimize for? 
  • How important is it to support very large product lists offline?

Given the time constraints, there aren't really any options to make major changes prior to 3.3. Next steps:

  1. Document the performance metrics, inline with what we did for 3.2.1. We are doing a performance testing round as part of the v3.3 release process. If any areas degraded from v3.2.1 to v.3.3, we will be fixing them and addressing so performance is on par or better than before. Based on results, we may recommend that Malawi doesn't load in 4000 products due to linear performance degradation of increasing initial data loads.
  2. Publish performance metrics for different user levels and data volumes 
    (so that implementers have official guidance on what size of product list is recommended and what levels of bandwidth are recommended) 
    Jira Legacy
    serverSystem JIRA
    serverId448ba138-230b-3f91-a83e-16e7db1deed1
    keyOLMIS-4317

Short-term Options (after v3.3, not by v3.3)

The following are draft and need input from the community and development team.

  1. Require internet for the NFS modal
    (Pro: solves major performance issues of loading everything upfront. Con: invalidates our ability to say the entire requisition process data entry is offline)
  2. Make targeted performance improvements to meet non-functional requirements with product lists over certain levels (say 4,000). The community would need to clarify what requirements are the goal and understand the level of investment needed (and trade-offs) to reach them. (Pro: make incremental performance improvements to community goal around non-functional requirements, Con: might not benefit many community members if the high threshold isn't needed elsewhere.

Long-term Options

  1. Allow implementers to configure the setting of NFS being online or offline
  2. Allow end users to indicate if they want NFS selection supported offline
  3. Others
Discussion
  • This discussion was started because of performance degradation based on large product lists as described on the left.
  • Ashraf:
    • We need to understand how many users are using these features and determine if this is an edge case.
    • Some of these issues are system performance issues, but others directly affect users.
      • For example, looping through all products could take a very long time to complete. We need to think through multiple ways of resolving these end user performance issues
    • Josh:
      • Consider the network capacity and devices as well
      • We can also consider using programming to change what data is exchanged over the wire.
    • We need to publish configurations that and recommendations that require a particular specification for different striations in the health system.
      • i.e. we would have a minimum supported browser versions
      • If there is outdated hardware at a facility, this requires an upgrade at the end user.
      • When we do a site readiness assessment, we need to understand the existing systems that are deployed and compare that against a known list of supported features.
        • Also:
          • What would you get with a really bad internet connection?
          • What is the optimal configuration of hardware and internet that is required for the end user.
    • Brandon Question: Do we know from the other 7-8 country implementations the length of product lists and whether any country uses Offline with non-full-supply list?
    • Summary:
      • We need the product committee to review the scope and setting priorities for the 3.4 release
      • We need to determine performance goals in striations and non-functional requirements.

Overview of the 3.3 Gavi demo

Mary Jo Kochendorfer (Deactivated)Didn't have time to go over verbally, please review and let Mary Jo Kochendorfer (Deactivated) know if you have suggestions/questions.
OpenLMIS Community Meeting in June, please fill out this form by  to help us decide on a theme, understand your availability and determine a location! Voting
  • Who would be interested in attending?
    • Please review the topics in the wiki link
Implementer toolkit release and updateTenly Snow (Deactivated)
  • For the 3.3 release, we are developing an implementer toolkit
  • This is just an initial phase that we want to release with 3.3
  • We request input from product committee members who have 
Reminder for input and comments on the Mobile StrategyReminder
DHIS2 Symposium  -  in DCReminderTenly will be going to present the DHIS2 integration with OpenLMIS as demonstrated at the Global Digital Health Forum
Next PC meeting: Is anyone willing to lead the discussion? I will be traveling from Geneva to CPH for meetings with UNICEF and unable to facilitate. It will also be the same week of the release.Discussion
  • Date: 27th March 2018
  • Mary Jo and Parambir will sync to see if he can run the meeting

ATTENDANCE:

RECORDING:

Video:  

View file
nameGMT20180313-160407_OpenLMIS-P_1440x900.mp4
height250

ADDITIONAL READING: