2022-01-12 MITI Governance Board Meeting

Meeting attendees

Sarah Arena (minute taker), Markus Hermann, Jeremy Muhlich, Sandro Santagata, Denis Schapiro, Artem Sokolov, Clarence Yapp

Agenda

Governance Board (“Board”) meeting frequency and structure Responding to user comments and building community engagement Addressing issue 12 raised by Jimmy Mathews: How do we make the standard sustainable to maintain? How should this be represented in a human- and machine-readable way?

Discussion and Decisions

Governance Board meetings

  • Meeting notes will be posted to GitHub and to the MITI website.
  • The Board will have a meeting within 30 days of a pull request being initiated. If there are no community-driven action items the Board will convene quarterly.
  • Affirmative vote to make Board meetings publicly available and open to the public. Meeting announcements will be posted on the MITI website. The Board will continue to hold closed Board meetings periodically.
  • The next meeting will be scheduled for March 2022.

User engagement

  • Board members will monitor and respond to user comments on an ad hoc basis. Specific questions may be routed to other Board members as appropriate.
  • The Board encourages users to initiate a pull request with suggested schema modifications. These users may be invited to a Board meeting to discuss the suggestion and implementation details. Meetings should occur within 30 days of the pull request to allow for timely discussion and voting. The Board will explore and create templates to allow users to propose changes, and a document will be added to GitHub to outline this process.
    Standard Maintenance
  • Changes to the standard will be made manually in the “core” representation, and all other representations will be populated automatically from the “core”.
  • Announcements regarding changes to the standard will be made via a changelog, which will document specific changes from accepted pull requests. Changes will also be announced on the forum.
  • Which representation of the standard should be treated as the “core” representation, enabling manual update by the Board and others in the imaging community?
  • Issue 12 suggests representing the “core” as a flat table. The pull request initiated by this user converts YAML to frictionless data using a flat table
  • YAML was initially chosen for both human and machine readability and to accommodate ragged nested lists. As we get into more complex data types, with different depth levels at every entry, this becomes difficult to represent in a table.
  • The Board will revisit this question based on multiple user experiences and our own experiences with implementation. A mititools repository will be added to store scripts that can convert representations of the MITI schema. YAML, flat tables and frictionless data will live as top-level directories in the primary MITI repository. In the future, Jeremy or Artem will set up a GitHub action to automatically build other representations from the “core”. This will automate this process and ensure synchronization by making representations available as a release package.
  • Affirmative vote to continue using YAML as the “core” representation. The Board fully supports automatic conversion to other representations and will implement a repository to house converters.

Items for future discussion

Continue exploring relevant ontologies to incorporate as suggested or controlled values