30 min | reference record upgrades | @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. 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
|