130 likes | 259 Views
Dictionary Stewards. Summary for MC Anne Raugh, 5 April 2018. Dictionary Stewards Meeting. Lots of good discussions, agreements reached, goals set, plans made. Thank you!. Highlights.
E N D
Dictionary Stewards Summary for MC Anne Raugh, 5 April 2018
Dictionary Stewards Meeting Lots of good discussions, agreements reached, goals set, plans made. Thank you!
Highlights • Documentation site for development of all types of documentation related to dictionary creation, validation, use with a tentative plan to populate it. • Identification of major issues for dictionary stewards at all levels. • Goal: Make LDDTool the required portal for all dictionary development • Near-term planning to move all currently identified dictionary-related issues forward • Identified major configuration control issue needing addressing • Long-term planning for the IM 2.0.0.0 boundary
Documentation Site • Collaborative development site (hosted initially at SBN) • All aspects of documentation • Requirements • Best practices • Tutorials • How-tos • Links to software • Plan for dividing and conquering document creation
Major Issues for Dictionary Writers • Streamlining Ingest_LDD creation and LDDTool processing • Collaborating across institutions • Internationalization for IPDA partners • Support for dictionary stewards of widely varying tech backgrounds • Options in choosing solutions
LDDTool as the Required Portal General agreement that this should happen and would be a good thing, but: • User interface needs polish • Requirements enforcement needs to be more robust (in progress) • Ingest_LDD needs streamlining to remove capabilities that appear to be redundancy to >80% of users • Discipline dictionary building MUST be automated • Documentation, documentation, documentation • Defining and developing validation and regression tests for existing (discipline) dictionaries is hard
Let Me Repeat Defining and developing validation and regression tests for existing (discipline) dictionaries is hard. Developing validation and regression tests in parallel with developing a new dictionary is fairly easy - once a method is defined.
Near-Term Planning • Existing CCB issues were parsed into CCB issues, SW issues, and “Other” issues (explanation to follow) • Issues raised but not yet documented were also parsed into those categories • Follow-up will include JIRA editing as needed for CCB and SW issues Now, about “Other”...
Configuration Control Issue • CCB addresses changes to the IM itself, and Standards Reference, DPH, and Concepts documents only • SW addresses changes to EN software tools and utilities only There is no configuration control at all for discipline dictionaries (or system documents, or user support documents, or web sites, …).
Configuration Control Issue (cont’d) This is a problem because: • To users, discipline dictionaries look like they are part of the “PDS system”, which raises expectations. • For discipline stewards, “validation” and “testing” are largely undefined concepts, and build procedures could rapidly become onerous • To everyone outside PDS (and many inside), discipline dictionary development and releases generally are a completely opaque process
Configuration Control Issue (cont’d) • A separate JIRA project would help with internal reporting, tracking, documentation; BUT • There is a math issue with attempting to establish another authority, working group, or standing committee. We’re jury-rigging for DD issues, but this needs a long-term, sustainable solution.
Long-term Planning for IM 2.0.0.0 • Must-Haves: • Confidence that there are no more major data format “surprises” • Examine discipline dictionaries for classes that should be in core • Examine core for classes that should be removed to discipline • Public reporting, configuration management for discipline dictionaries • Schema release packages for each build • Streamlined and automated (as far as possible) system build process • Complete, stand-alone, maintainable sample data sets • Establish practice of design reviews for large pipelines/projects • Need basic info for new users to any and all systems, tools, or environments used by PDS nodes (GitHub, e.g.) • Substantially complete PDS3->PDS4 migration of legacy data • Demonstrable, long-term, consistent drop-off in non-backwards-compatible changes
Long-Term Planning for IM 2.0.0.0 (cont’d) • Recommendations: • The reasons for going to 2.0.0.0 should be clearly and publicly enumerated. • The Mars2020 mission should be the “final run” for the pre-2.0 IM. That is, if Mars2020 can design its archive and have its initial deliveries accepted and archived without substantive changes to the IM they started with, we will have strong evidence that IM 1.x is fully mature, with its discipline dictionaries, and ready for 2.0.0.0.