2016-10-25 Meeting notes

Date

25 Oct 2016

4pm-5pm PDT

Attendees

• Josh Zamor

• Elias Muluneh

• Brandon Bowersox-Johnson
• Darius Jazayeri (Unlicensed)

Meeting link

https://www.uberconference.com/richmagnuson

IP audio, or Dial-in:  1-716-293-9263, meeting PIN:  60307

Goals

• Discuss the Beta release - this is the last call before Beta is published
• Provide feedback on extensibility
• Discuss where 3.0 planning is and how this committee wants to be informed

Discussion items

Notes

A productive discussion on Extensiblity, Beta and our current plan for a useful extension example occurred.  Out of that discussion Elias shared a real scenario to ask how these mechanisms and the community would be utilized to avoid a fork.  The scenario:

There are two organizations supplying commodities in country:  MSL (ministry) and CHAZ (charity).  Of these most of the commodities in a requisition will be supplied through MSL.  However for a few of these commodities (5-6), and only at some facilities in the country, CHAZ will actually supply those commodities.  The requisitioning facility will fill out one Requisition and submit it and have it authorized.  When the district supervisor goes to approve it however, they will essentially be creating two orders:  1 for MSL which will fulfill the regular commodities, and 1 for CHAZ which will fulfill just a few of the commodities. 

This workflow introduces a number of important changes:

• • the concept of a Supplying Partner is introduced to distinguish MSL supply lines and commodities from CHAZ supply lines and commodities.

  • an Approver would want to see in the UI what quantities they we're approving based on the Supplying Partner that will fulfill them

  • an Approver is essentially creating not 1 order, but potentially many (or 2 in this case)

In briefly discussing how the mechanisms would apply, we thought:

• a new entity would need to be introduced
• the UI would need updating:  showing supplying partner for commodities (what gets fulfilled by whom), config, etc
• would need to use extra data on facility/product to indicate supplying partner responsibility
• convert to order would need to allow 1 requisition to end up as multiple orders

How this is actually addressed should be fleshed out and discussed in future meetings.

Action items

• Elias Muluneh to go over notes on the scenario and ensure the detail is enough and correct
• Josh Zamor to organize how the architecture would address the scenario and lead discussion on findings at next call - I've added a ticket for this:  OLMIS-1234 - Getting issue details... STATUS
• Josh Zamor to create a new calendar invite
• Josh Zamor to either amend existing ticket or create a new one that puts out documentation on timing
• Darius Jazayeri (Unlicensed) to talk to community members in China about participation, times and potential for including team in Poland