Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

05-26-2021

Attendees

Discussion items

Time

Item

Who

Notes

30 minreference record upgrades
  • Wayne Schneider: Is leaving the audience technical wise here? ref-data has grown organically. Do we need a system-librarian type resource to help elucidate the needs of this community.
  • Ian Walls: nothing should break; customizations that were made must remain and not need to be re-applied. 
    • VBar: Challenge! Customizations (can handle this) vs enhancements (should be allowed to ignore this). Impact/difference between these proposals affects devs, not end-users. 
      • separating data allows data module to be more flexible; don't have to put isCustomizable flags all over the place
      • default data remains clean and automatable; handle customization manually later.
      • this makes expectations very clear for external devs and provides them more flexibility.
      • md331 (Deactivated): this is compelling, but concrete examples would be helpful.
    • VBar: the question is do we have two boxes, or one box with two compartments? Currently we only have one box, one compartment, and it's a mess.
    • Tod Olson: the one-box proposal means we only have to look for data in once place. 
  • When do we care about these discrepancies? Only at upgrade time. The rest of the time, we think of these lists as a single list.
  • Vote is for a preference, not necessarily a vote to approve, but provides direction for a POC. 
    • one-box; two compartments: 3
    • two-boxes: 5
  • Next steps
    • create a feature ticket with a spike under it; outcomes: documentation, tooling
    • POC must exercise the model through an upgrade, at least for one dataset 
    • who can do this work?
    • ... and who gets to decide about this? It's effectively a feature, and therefore the purview 
      • Mark Veksler : bounce to working group to define params of POC?
        • recommend a module
        • recommend scope
        • recommend how to test the feature work (i.e. on #master vs on a dev branch)
        • define acceptance criteria
        • send FYI to sysops-SIG to keep folks in the loop
        • bounce to cap-planning to be prioritized against other features, assigned to a team
5 minfuture agenda items
  • Tentatively canceling 2021-06-02

...