2017-05-09 Meeting note

Date

7am PDT

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

TimeItemWhoNotes
5mStartNick Reid (Deactivated)
30m Malawi

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
20mExtension Point process
  • 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
5mDoodle poll
  • 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

  1. 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
  2. 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
  3. 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

OpenLMIS: the global initiative for powerful LMIS software