| 30 min | reference 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
|