Versions Compared


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

Call Information

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

Last Meeting NotesPC: July 2 2019



Lead (Time)

Notes and Updates

Software Development Update

RoadmapLiving Product Roadmap 

Current sprintBacklog Grooming Sprint 131

Upcoming sprintBacklog Grooming Sprint 132

Version 3.7: 

Team stats


Version 3.7 Update

Development Budget Changes

Living Product Roadmap Updated

Product Committee Call ChangesWesley Brown (5 min)

Change from bi-monthly calls to two, monthly calls:

  1. Implementer-focused call on the first Tuesday of the month at 8am UTC
  2. Global Committee call on the third Tuesday of the month at 3pm UTC (this call)

Members are welcome to join either or both of the calls. Please note that trusted partners should have at least one person attend at least one of the call each month.

Rebecca: Have an agenda item to update the other meeting

OpenLMIS Community MeetingRebecca Alban (Unlicensed) (5 min)

Please fill out your availability/interest on this page: Community Meeting 2019

OpenLMIS in Emergency ContextsJosh Zamor (10 min)

We are looking for feedback on on this Discourse post by Josh:

  • Context: OpenLMIS could be well-suited for emergency situations - would need to work on making it easier to configure (a few days max, rather than several weeks)
  • this is an idea we are exploring for future potential funding opportunities; it would be a separately funded workstream
  • Do people think this is a good idea for us to pursue? If so, what features would be a priority to include?
  • suggestions; Partner coordination, quick startup time, we would need to partner with a humanitarian org to get more context about what the needs on the ground on
  • please share your ideas in the Discourse post!

Planning for version 3.8

Wesley Brown (10 min)

Feature Backlog: Feature Backlog

Please fill out the ranking poll here:

Rebecca & Josh: demo data

Josh: Add feature for reports utilizing maps

Christine: Admin screen wizards and Offline Stock Management

 Josh: What level of offline support?

 Christine: Thinking about it holistically, support users being able to do stock management functions offline (realtime data entry while offline). Airtime, if required to be online, could become a considerable expense given that the system would be used more regularly

Sebastian- Admin screen feature: people understand it differently; info in the epic might not represent what people understand of it. Epic is focused on facility based products. Improving to the admin screen in general should be reflected in a separate epic. Christine was referring to the more 'general' interpretation

With our current development budget, we will only be able to tackle 1 or 2 features

Christine suggestion: to be more responsive to mobile browsers/adding mobile to QA) so that the system could be used on a tabletfeedback

Product Committee RoleWesley Brown (10 min)

What is (or should be) the role of this committee?

Rebecca: What we're doing now is one aspect of our role. Perhaps because our dev budget is smaller there will also be less to discuss related to the ongoing product work. Sharing experiences from implementations

Sebastian: Should focus more on long-term plans for OLMIS. Sprint showcase may be a better place to give feedback on ongoing feature development. We should focus on what we should be working on in the next release.

Christine: Discussing how to implement/design features with feedback from implementations and partners. ← An existing function.

Make sure implementation stories are being shared across both PC meetings

Josh: Get through priorities and then make some mock ups, those can be useful. have something concrete to give feedback on, and get to the design. This would be particularly helpful to do one release ahead of time. think more about the 'how'

Sebastian: would mock ups be done beforehand? sometimes people don't understand the features well enough. mock ups could only be a few hours of work and help people understand what the feature should bring

What can we do to more effectively fulfill that role?

Josh: Get through the priorities and get into mockups. Get more into the design.

Sebastian: Mockups only once we've decided to prioritize a feature or to help figure out the prioritization of features? Having the mockups as part of the overall prioritization discussion shouldn't take too long and could be very helpful.

Next PC meeting: Topic ideas??

Confirm Version 3.8 Planning, Project Casper Update (Demo?)

Additional Requests and Information:


Josh ZamorParambir S Gill (Unlicensed)Rebecca Alban (Unlicensed)Christine LenihanWesley BrownSebastian Brudziński, Momad


View file