Versions Compared

Old Version 3

changes.mady.by.user Chris Will

Saved on

compared with

New Version 4

changes.mady.by.user Chris Will

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Meeting Minutes

...

Participants

Elisa Kendall Farhad Ameri William Sobel tschneider

Agenda/Minutes

As I had not prepared an agenda in advance, we began the discussion somewhat informally by reviewing minutes from the last meeting that I had published to Confluence the day before. We then agreed to discuss the following topics: (1) Review the structuring of projects in Jira and proposed workflows for managing issues and action items or tasks that Will had prepared using MTConnect WG by example. (2) Discuss further the workflows and tooling for ontology development. And (3) review the action items from last meeting.

  1. Being on the call for the first time, Todd grabbed the stage to talk about our Term Analysis Procedure and the importance of the linguistic analysis step – referencing the recent analysis discussion of term Agent from the prior IOF Core meeting. Todd reiterated the importance of arriving at a suitable natural language before starting or mixing in terms and relations from BFO and IOF. We agreed the analysis workflow might need to be revisited to ensure Todd’s concerns are reflected in the procedure. Chris took on the action item to move the content for this procedure from Google Docs to Confluence. Check it out here: Term Analysis Procedure. One concerns after moving this content is that Confluence is more of a content management system and not a file management system from what I can tell. So where to put the PowerPoint presentation of this procedure since PowerPoint, at least for now, will remain the tool for managing updates to it? And the general question would be for any other content authored and managed in tools outside of Confluence?

  2. Managing Projects, Issues and Tasks in Jira. Will gave the group an overview of the project and workflows he had setup in Jira for the MTConnect WG. The only requirement coming out of this discussion is that we want to be able to easily search and find things on Confluence & Jira (GitHub for that matter too). It is not clear yet whether the search features in the Atlassian tools are sufficient. E.g., how do you do a focused search for the term “stasis” and target just the MTConnect project and Confluence content? Will is playing around a bit with this and will provide some guidance.

  3. Workflows and Tooling for Ontology Development and Release. Highlights of our discussions are as follows:

    1. We discussed first the “term review and approval” steps of the workflow Will had configured in Jira in relationship to making changes to terms in an ontology (master or branch in GitHub of an ontology). E.g., what validation tools need to be run before submitting a term for review, and which later on in the process? We decided that before committing any changes to GitHub, the Serializer should be run. The Hygiene and other tests can be run much later before ontology revisions reach the release status.

    2. We then discussed whether the IOF GitHubs would be public or private. Didn’t get a group consensus or conclusion on this so to be revisited next time..

    3. Elisa mentioned FIBO and other efforts she’s done have a formal “checklist” to be filled out by a term author/editor and will provide a sample checklist from FIBO to share with us.

    4. We discussed the need to draft a more detailed description of the workflows related to the above – an action item to be assigned in our next meeting as we discuss this topic further.

  4. Review action items from last meeting. We ran over on the above items and since we had only a limited number of attendees, we pushed the discussion for this to the next meeting.

Meeting Minutes

Participants

Jim Wilson Serm Kulvatunyou Elisa Kendall Farhad Ameri William Sobel Evan Wallace Mike Bennet Dusan Sormaz

Agenda/Minutes

  1. Elisa spent the first 30 minutes giving the group an overview and demonstration of the key release artifacts, process and tooling used by FIBO.

  2. We spent a bit of time talking about the Elisa’s IRI recommendations, and agreed to discuss this further in the Architecture Task Group.

  3. We then proceeded to discuss some of the tools we will likely use in managing the development and release process – as in Jira, Confluence and GitHub, which are provided at no charge to IOF by OAGi, or are open source. Key discussion points were:

    1. I believe general consensus was reached on utilizing Jira as the tool to manage the development and release efforts of the various IOF working groups, and utilize GitHub to manage WG outputs – reference ontologies and supporting artifacts, including the versioning thereof. William Sobel agreed to setup a basic workflow and project structure in Jira and apply that to the MT Connect WG as a prototype.

    2. For raising, tracking and resolving issues, our choices from the FIBO discussion were that this can be done either in GitHub or Jira, or both. FIBO has some automation in place that synchronizes issues content between Jira and GitHub in both directions. Elisa mentioned making this available for the IOF and possibly improving some of its capabilities if the IOF gets some funding to streamline its processes. Elisa also mentioned that some members of FIBO don’t allow access to the public/cloud GitHub instance and that we might need to eventually stand up a private GitHub instance for IOF. We had no further discussion regarding next steps on this point but I think the requirements are: (1) we will utilize both GitHub and Jira. (2) Issues raised against terms and artifacts managed in GitHub should be visible in GitHub. (3) duplication and synchronization of issue content between GitHub and Jira, including the assignment of tracking identifiers and cross-referencing, must be automated. And (4) Jira should serve as the master “system of record” for all issues since some project issues lie beyond GitHub. Additional action item: We should poll our corporate members to see what sort of GitHub policies they have in place and understand if we have an immediate need to stand up a private GitHub instance, or not. Serm is volunteering for this?!?!?

    3. The discussion then moved on to some of the release tools FIBO can make available to IOF.

      1. The first tool discussed was the “RDF Serializer,” which standardizes the formatting of content in ontology files (eliminates white space, orders content in a consistent and repeatable manner).

      2. Ontology term glossary generation tool. We talked a bit about “SourceTree” from Atlassian and certainly other tools currently in use by the WGs to generate such glossaries.

      3. “Jenkins” job/automation supports various dimensions of the ontology publishing process: “hygiene test,” ontology viewer content generator, versioned IRI generation. Follow-on questions: does it automate versioned folder generation, redirect the virtual paths to the new versioned files and take care of deploy documents to the correct target folders?

      4. The likely action items on the above is for some of the working groups to test out these tools and report back on their findings – from which we might glean some requirements on what we might need/require. Elisa has already run the Serializer against the annotation properties file (see here separate email and findings on this). Action item for Evan to update the annotation file and publish a new version.

      5. Many of the above to be revisited and discussed in our next meeting.

  4. We then discussed more general requirements for releases/release process:

    1. What artifacts constitute a release (i.e., release products as FIBO calls them)?

      1. Ontology files (including the additional IOF-authored & imported meta files)

      2. Data files/data dictionary

      3. Vocabulary (glossary as mentioned above)

      4. Release notes

      5. Other supporting documentation (version independent and both tool- and ontology-centric)

      6. Use cases (likely not something we are ready to publish externally, but to be considered downstream)

    2. For source (ontology files and related artifacts) workflows:

      1. The review and approval step before a change is committed back into GitHub must include at least 2 approvers. Question: Who should these approvers be (as in perhaps 1 ontologist + 1 subject matter expert)?

    3. Ontology publishing tools (in current use by FIBO and available to the IOF):

      1. Hygene testing tool

      2. Ontology Viewer/content generation tool

      3. Jenkins job for automating Ontology content deployment

      4. Authoring of release notes is currently a manual process.

    4. Key questions:

      1. Do we version ontologies at the domain level or at a more granular level (module/file level)?

      2. What frequency of releases are we looking at (yearly vs quarterly)?

      3. Do we synchronize releases across the domains, modules and core, or allow each to release on their own, potentially separate, schedule?

...