Copy of 2021-05-26 Meeting Notes

Craig McNally

• 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