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.
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.
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?
Blocker and critical bugs are prioritized.
The other bugs that are not blocker or critical are not fixed in this. They will be fixed on an ongoing basis.
If the community feels there are too many major bugs in the system, we can prioritize them over doing new feature development.
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).
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:
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.
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)
OLMIS-4317
-
Getting issue details...STATUS
Short-term Options (after v3.3, not by v3.3)
The following are draft and need input from the community and development team.
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)
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
Allow implementers to configure the setting of NFS being online or offline
Allow end users to indicate if they want NFS selection supported offline
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
OpenLMIS 3.3 Demo has the presentation (work in progress) which allows people to comment.
Tenly 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