Design Forum 2018-10-15: Resolving design inconsistencies in Cohort Membership (TRUNK-5379)

meetings
design-forum
Tags: #<Tag:0x00007efd1ed66f60> #<Tag:0x00007efd1ed66dd0>

(Jamie Thomas) #1

Monday’s design forum is from 4-5 pm UTC:

Resolving design inconsistencies in Cohort Membership

Description: There are various design inconsistencies in the CohortMembership model that need resolution as described in TRUNK-5379. We will use time in the design forum to walk through these inconsistencies and aim, by the end of the call, to create or identify ready-for-work tickets to resolve them

Notes: https://notes.openmrs.org/2018-10-15-Design-Forum

Attention: @mogoodrich, @burke, @wyclif and/or @dkayiwa, @darius. All others interested are welcome!

To join the call using Audio, Chat, & Screen Sharing please use a WebRTC-compatible browser (Chrome recommended) and join the OpenMRS UberConference call:


The next design forum on Wednesday, October 10 @ 6-7 pm UTC - OPEN FORUM

If you have a topic you would like to discuss during the call please post it at http://om.rs/designtime


(Burke Mamlin) #2

Thanks @darius and @mseaton for helping get TRUNK-5379 ready for work during today’s design forum. Darius & I started out disagreeing with most of @mogoodrich’s assertions until Mike joined, agreed with Mark’s assertions, and helped understand Mark’s brilliance. It came down to how one approaches Cohort: do you see it as a Java collection of memberships or do you see it as a clinical cohort of patients. The former expects methods to behave like any other collection regardless of whether or not memberships are active; the latter expects methods to take into account only active memberships. In the end, we realized (as Mark had) the default collection methods are better behaving as typical collection methods and new methods could be introduced to work only with active cohort memberships.

In short, rather than making standard collection methods (contains(Integer), size(), and isEmpty()) take active membership into account, we agreed these methods should behave as a Java programmer would expect a collection of CohortMemberships to behave (except, ignoring voided memberships). We would create new, non-ambiguous methods to get the same information for active memberships (hasActiveMembership(Integer), activeMembershipSize(), and hasNoActiveMemberships()).

By the end of the call, we were able to make TRUNK-5379 ready for work.


(Mark Goodrich) #3

Thanks! Apologies for missing the call… as for “brilliance”, this Cohort stuff was probably Mike’s idea to begin with, and, if not, I probably would have forgotten what I had been thinking, so better for Mike to be there than me… :slight_smile:


(Ellen Ball) #4

+1 Mark’s brilliance +1 Burke’s humour


(Fred Rue) #5

@jthomas (cc @burke @mseaton @mogoodrich ) Is the design decision clear now and the following ticket is ready to be worked on? https://issues.openmrs.org/browse/TRUNK-5379?filter=-1

Any documentation or decision I should know about if I want to start working on this?

Thank you!


Design time for Resolving design inconsistencies in Cohort Membership (TRUNK-5379)
(Burke Mamlin) #6

@fruether, thanks for offering to work on this (I’ve moved your comment from the topic discussing when to have the call to here.)

Just the summary above and the ticket’s description, which we updated to reflect consensus. Since there are several tasks described, please feel free to create subtask tickets for individual chunks of work (splitting it up into a few subtasks would, at a minimum help make reviewing the pull requests easier).

If you have any further questions about the ticket or lack privileges to make subtasks in JIRA, let us know here and we’ll try to help.