You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Intent is to establish a design document for the HTAN 2.0 data model that consults internal stakeholders, aligns with ongoing product enhancement (i.e. Schematic), and infrastructure design considerations. Once established, bring this to external stakeholders among members of the HTAN DCC.
Considerations: Need to understand THE way we at Sage want to handle these data models and how we approach this with an established, mature model. This could include what opportunities that exist to simplify the model and adapt this based on valid valid usage and cleanup. Are there simple/standard ways to implement Boolean values? Can we start with establishing minimal attribute list?
Target output for Fall 2024 (24-9/10 sprint): Design doc that outlines key considerations and decision points, as well as nice to have/wishlist features. 1) Define architecture, and pull out minimal layer that addresses issues and emerging pain points, 2) establish how will we set this up and the overall infrastructure (i.e. csv or YAML formal as input for JSON - AD using CSV with modularization; NF and Gray using YAML. csv may be better from visualization, which we see in MC2); 3) integration across end to end process (up front docs and downstream release infrastructure.
Emerges from the RENEWAL PLANNING stage of #389
Intent is to establish a design document for the HTAN 2.0 data model that consults internal stakeholders, aligns with ongoing product enhancement (i.e. Schematic), and infrastructure design considerations. Once established, bring this to external stakeholders among members of the HTAN DCC.
Considerations: Need to understand THE way we at Sage want to handle these data models and how we approach this with an established, mature model. This could include what opportunities that exist to simplify the model and adapt this based on valid valid usage and cleanup. Are there simple/standard ways to implement Boolean values? Can we start with establishing minimal attribute list?
Target output for Fall 2024 (24-9/10 sprint): Design doc that outlines key considerations and decision points, as well as nice to have/wishlist features. 1) Define architecture, and pull out minimal layer that addresses issues and emerging pain points, 2) establish how will we set this up and the overall infrastructure (i.e. csv or YAML formal as input for JSON - AD using CSV with modularization; NF and Gray using YAML. csv may be better from visualization, which we see in MC2); 3) integration across end to end process (up front docs and downstream release infrastructure.
Take into consideration all issues with the renewal_planning_early label: https://github.com/orgs/ncihtan/projects/4/views/2?filterQuery=label%3A+renewal_planning_early
Also take into considerations key discussion points, actions, and overall data flow discussions in NYC:
The text was updated successfully, but these errors were encountered: