Drummond Reed Rieks Joosten Judith Fleenor 

We had no less than ten volunteers respond to the call for volunteers above. Plus one ToIP member who had issues with the content of the paper.

However our own Nicky Hickman went beyond volunteering and actually did the conversion of the paper!

We discussed that there was some feedback on the paper. Rieks said would like to go ahead and publish the paper with the 2022 approval date. That would indicate that the paper was current as of that date.

Rieks then suggested that we could invite people to begin to work on a V3. It was agreed that would best be done via a blog post that announced the availability of the paper as t ToIP deliverable.

ACTION: Rieks Joosten, Nicky Hickman, and Drummond Reed to draft a ToIP blog post to announce the paper, explain the late publication, and invite others to contribute to further work on the paper. Nicky Hickman will start the post using the standard ToIP blog post template that Judith has already created.

ACTION: Drummond Reed to thank all the volunteers.

Judith Fleenor Brian Richter 

Brian reported that the EasyCLA workflow still requires manual intervention. He did coach Henk van Cann on how to do this to accomplish a glossary generation. He also shared that one solution is that a bot could create the PR and a human (who is EasyCLA authorized) could approve it.

We agreed that we have the TEv2 workflow in place, it might be easier for a bot to also merge the request, but we can tackle that when we get there.

Rieks was in favor of moving forward as quickly as possible to finish the TEv2 work.

Rieks Joosten Brian Richter 

Brian Richter has hired another person that will help him out on the work.

@chadha is still having some trouble with integration, but the TRRT seems to work.

We have labeled MRG issues with prio=high that need to be done first, prio=medium that need to be done next. There are some feature requests that have not been prioritized. Overall prio is to get the long-term tools up and running, so minimal effort will be spent on fixing stuff that will be phased out (dhh's tools). After MRGT, Brian will work on HRGT, and we expect TRRT will be ready when HRGT Is. 

Drummond Reed Neil Thomson 

In our last meeting, Rieks suggested the following steps in the development of a mental model:

1. Start writing the spec and mark every term that needs a definition.
2. Document each noted term by supplying a first criterion by which the members of the task force can determine if an instance is an example of the term. For example, throw a number of use cases at it, and see if the criterion works. If it doesn't, find the criterion that does.
3. Document these discussions so you end up with a little document for each term that not only provides a definition, but gives readers an understanding of the criterion that were used and why.
4. Once you have agreement, you return to the specification document and revise it to incorporate the terms based on the the new definitions and criteria.
5. When you find that the terms all relate to each other in a clear way, then you have a mental model you can draw and document.

Drummond and Neil are wondering about the best way to go about this process prior to starting to draft the specification. In other words, how can we at least start building a mental model during stages 1 thru 6 of the development stages in this table before we get to the spec drafting stage (recognizing that the mental model will be further improved during the Working Draft stage)?

Rieks Joosten shared that he's been doing some work on mental model development for Qualified Data Exchange. He shared the following PDF and walked us through it.

Rieks explained an example of a full QDX ecosystem (screenshot #1 below) and the basic model behind it (screenshot #2). He pointed out that this model works regardless of whether it is offline or online, manual or automated. The whole point is to mitigate the risks in collecting and processing data in order to achieve an objective by validating the data.

ACTION: Drummond Reed and Neil Thomson to work out a process to start the Trust Registry TF and Trust Spanning Protocol TF on the process of creating a mental model for the terms needed in their respective specifications.