2017-05-09 Meeting note

Date

09 May 2017

7am PDT

Meeting Link

https://www.uberconference.com/villagereach-isg

Optional dial in:
Dial in: 401-283-5773
PIN: 66343

note the changed dial in number and pin

Attendees

Goals

Malawi - Batch Requisitions (and quick update on extension points)
Endpoint process
Doodle poll - how to paginate Ref Data

Discussion items

Time	Item	Who	Notes
5m	Start	Nick Reid (Deactivated)
30m	Malawi	Sebastian Brudziński	Updates Average Consumptions Extention point Requirements and use case isn't completley understood yet Will come back after immediate deadlines are met This will be an extention point, or use another method to calculate Confluence page will be updated, when we return to this issue Aggregate Requisitions RAML model has been delivered and approved by technical committee Main reason is to have a performant API in high-latency settings Point of contention is if the endpoint returns 400 or 200 when there is one requisition that errors Need to add contract tests for these endpoints Outcome: Discussion going to dev-forum, any changes UI changes are large, unsure if we want to merge into OpenLMIS-Requisition-UI See MW-84 for proposed UI changes
20m	Extension Point process	Josh Zamor	Goal: Need to be comfortable with proposed process AND have it publicly documented Focusing on extension points, which hopefully will extend to extra data process later See process details below Presumptions: There are active maintainers to manage PRs Next Steps: Josh Zamor will formalize this write up and share in next tech committee meeting
5m	Doodle poll	Josh Zamor	Question: In reference data, how do we want to handle adding pagination and extra data to resources in semantic versioning Answer: One big fat release Next Step: Josh Zamor will write a "stub" JIRA ticket

Notes

Malawi

Extension Pt Process

Communicate out to developer forum
1. describe use-case
2. describe proposed extension points - be detailed about method signatures, it's a Java interface
3. solicit feedback - process and need should be non-controversial so long as the service 1. doesn't become a jumble of things and 2. it doesn't break backwards compatibility
Develop extension point
1. Anyone could develop the extension point, either he or she whom proposed it, or someone that works on the Service
2. Extension point should be a Pull Request that's easy to merge in - conforms to Service style guide, consistency, etc and passes all tests.
3. The one that proposed the use-case, should implement the extension module
Implementation should expect to wait until next Release
1. Implementer should expect to need to wait at least a month (a couple sprints) - to give Service time to plan their release
2. Implementer can speed things along by submitting the extension point themself
3. If the request comes right before the next release, e.g. a week before it ships, implementer should expect to wait until the next release
4. Implementer could choose to take on more risk by submitting the PR, getting it merged, and then adopting the in-development Service. Risky and buyer-beware, but might feel faster.

Doodle poll

https://openlmis.atlassian.net/wiki/x/0-i3Bg

Next step: LOE exercise to determine if we can fit this much work into the next release - Reference Data would be under active development and all consumers of these search endpoints may also need to become active to adjust to these changes.

Action items

Sebastian Brudziński send email to dev-forum about how to handle batch errors as 200 or 400 status code
Josh Zamor write up extension point process
Josh Zamor create "stub" ticket for referencedata pagination/extra data