Good point. My intent was not to use the cohort.date_changed (which would reflect when the Cohort resource metadata like name, definition, etc. was last changed), but introduce a new timestamp for when the list of people in the cohort (cohort membership) was last refreshed/changed/validated.
Something like date_last_evaluated would work for calculated cohorts, where the evaluation of the definition updates the membership. However, what about cohorts defined to be manually managed (e.g., directly by users or through triggered events), where the membership isn’t determined by evaluating the definition? I thought the equivalent for manually managed cohorts would be the timestamp the membership was last altered (manually or via event) or reviewed/validated (e.g., someone verifying a manually managed cohort is correct without changing it would be functionally equivalent to re-calculating a calculated cohort that doesn’t result in any changes).
So, I was trying to capture for all cases of definitions (calculated, manually managed, altered via events, etc.). Maybe date_members_updated or membership_valid_as_of?
OK so here’s where I think we are at with getting momentum on this.
Who needs this: Ampath, Mekom, & UCSF/OHRI
Dev time: Ampath has committed some of @corneliouzbett’s time to focus on working on the Cohort Module; he is just waiting for direction & tickets/clear tasks.
Architecture/Software Design time: @ibacher has graciously offered to provide direct support for @corneliouzbett, and @mksd will also provide input.
So what do we need next?
@burke@ibacher@corneliouzbett (and optionally, @mksd and @eudson) can you guys get together this coming week to assemble a proposal for how to wrangle Cohort Module, and then bring that to the TAC on Monday the following week? (I’d recommend posting the plan here as well)
@ibacher and @corneliouzbett, I’ve started to draft a Cohort Module Next Steps google doc. Let me know if you already have something like this and I can help merge documents. At the moment, I’ve just copied my prior Talk post and started to organize content. I’ll try to find time today & tomorrow to evolve it.
@burke looks like the document ends with creating tickets(Next Steps) . I would like to know how i can help in this sense , this also looks late for platform 2.5.0 Iam planning to release platform-2.5-alpha in two weeks .This may be knocked off the list and re-scheduled for 2.5.x or 2.6
@ibacher@corneliouzbett are we ready to harness tickets out of this , anything impeding us ? .
Am sure it’s the same thing @dkayiwa is waiting for .
We’ve created some tickets to do some of the refactoring. There’s also this one that I guess is open.
The idea of doing this work in a module is that it’s unbounded from the platform release cycle, so while this may be work for the “platform team”, it’s not really related to the 2.5 release. I’d anticipate it first being included in the 3.x RefApp.