...

1. We spent most of the meeting discussing the workflow for managing ontology terms and issues raised against them, especially in the context of which workflows and activities should be tracked and potentially automated in Jira or GitHub. There may be some outliers among us but I believe the general consensus is as follows (and I’m dividing the discussion into the “pre-” and “post-candidate” phases of a term’s evolution):

   1. Let’s first define the phrase “candidate term definition” as the state a term reaches when its analysis phase completes – meaning the term (a class or object property) has been formalized in the applicable IOF ontology or module, is conformant to the IOF Technical Principles and Annotation Property Rules, and that the underlying ontology file has been “Serialized” and committed to GitHub in the applicable “development branch” for the ontology. Question: Does someone have a good narrative for managing an ontology in GitHub from other efforts?

   2. Concerning pre-candidate term definition activities – including all the activities shown in the Term Analysis Procedure – the consensus is to allow the working groups to continue using whatever methods and tools they currently use (Slack, GitHub, etc.), provided the minutes from working group and the collaboration history show evidence the term analysis procedure is being followed. While most of us felt it was either premature or “over-the-top” for the IOF to manage such pre-candidate term definition activities in Jira, it might make sense to configure a basic workflow and prototype this in Jira for one of the working groups. MTConnect is currently doing so to manage its terms. Will indicated he might expand the Jira workflow to align more closely with the analysis procedure, but that this was lower priority. Net-net, we will track MTConnect’s progress on this before we commit to automation.

   3. Concerning post-candidate term activities – including voting on a candidate term definition, and raising and resolving issues raised for a term – the consensus was to use Jira. Will has setup a basic workflow for managing tasks and issues alike, which is being prototyped by several of the working groups. Some assumptions and questions that come to mind as I document our minutes on this are:

      1. It wasn’t clear from our discussions whether voting would happen during the pre- or post-candidate definitional phase. I made the assumption that the voting process happens as one of the post-candidate definition activities, since we want to keep records of who participated in the vote and manage any issues raised, resolved, or outstanding, as one of the metric to drive a release schedule.

      2. Do we keep the minutes, issues, and collaborations of post-candidate definition activities “private” or make these visible to the public? There’s obviously implications either way we go.

      3. How many people and what types of experts must be involved in the voting process, what constitutes a “quorum,” and what constitute a successful outcome of the process? We talked a bit about this in the TOB.

   4. We’ll have to detail the above points further in our next meeting.

2. Relative to holding meetings in general, and in this instance in reference to the up-coming Architecture meeting that was to be held the next day, Evan mentioned the importance of knowing what the Agenda topics are in advance of a meeting. I believe we are addressing Evan’s concerns for this meeting, and if not, please do let me know. Certainly, we should open up our next release management meeting by reviewing open action items from our prior meetings and dispatching them in the Jira portal. And then we can detail the above workflows (the post-candidate definition workflow) as one of the next agenda topics.

31 Mar 2021 Meeting Minutes

Participants

Elisa Kendall Farhad Ameri William Sobel tschneider

...