Versions Compared

Key

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

Date

Attendees

Goals

  • Determine concrete next steps for establishing the glossary entry process

Discussion items

TimeItemWhoNotes
5 minWelcome & IntroductionsChairs
5 minsInserting terms into GitHubDan Gisolfi
 10 minUpdate on ESSIF-Labs C&T Project  Rieks
  • Rieks could only attend the end of the meeting due to time change
10 minPossibility of using Glossarist?Drummond
20 minGitHub strategy & coordination with
Operations Team
Chairs & Dave
10 minAny other businessAll
5 minsNext meetingAll

Notes

  1. Dan Gisolfi reported that there are three pull requests against our Concepts and Terminology repo.
    1. Dan Gisolfisubmitted the terms from Bedrock
    2. Daniel Hardman submitted the terms from the Sovrin Glossary
    3. Rieks Joosten submitted one for the terms from ESSIF Lab terms
    4. Both All of these use a baseline data model
    5. Now this This now gives us a set of raw terms
    6. The open questions are
      1. What additional metadata is needed in addition to these terms?
      2. What is our process for accepting these terms?
  2. Process questions
    1. How do we want to work through a process for approving terms?
      1. Dan proposes Gisolfi  proposed that any submission that's valid can become part of the corpus
      2. Daniel Hardman wants to make sure the process is lightweight and low friction
      3. Dan proposes Gisolfi proposed that there may be overlapping terms and let it is okay to us deal with this later on
      4. Scott Whitmire proposed that the source can come from any WG or TF within the Foundation and should not require "everyone to vote on everything"
      5. Paul Knowles wants the Semantic Domain WG to be able to prepare a glossary document
      6. RJ Reiser said he wants to do the same thing with the Technical Stack WG glossary, which he has volunteered to lead
      7. Dan Gisolfi proposed the lightest weight process that submitters can use
    2. Possible states for a submitted term (long discussion on this)
      1. Proposed
        1. A term someone in the community has suggested that has not had review by the CTWG yet
        2. All proposed terms are under review until the CTWG marks them as reviewed
      2. Reviewed
        1. Members of the CTWG had have reviewed the term for well-formedness, that the tags are validvalid tags, sanity-check, etc.
      3. Approved
        1. The CTWG members have agreed that the term, definition, and tags are complete
        2. The stakeholders who will be using this term have agreed to the content This stage involves feedback with <== requires review with the stakeholders
    3. Same We agreed that the same term can have multiple meanings:
      1. Multiple labels (words used for the term in specific languages)
      2. Multiple meanings (especially in different scopes/contexts)
    4. Daniel Hardman brought up the scenario of different stakeholders disagreeing on the status of a term, i.e., it is approvedPaul Knowles asked about multiple definitionsits definition is approved by one set of stakeholders (e.g., one WG) but not by another.
  3. Coordination with the Ops Team
    1. Drummond Reedsaid suggested that the process for submitting, reviewing, approving terms—and for publishing a glossary—is something that we should collaborate on with the Ops Team, and that the Ops Team should then take to the other WGs.
    2. David Luchuk said that this would be a "tutorial" that the CTWG and the Ops Team would produceshould collaborate to produce a tutorial covering the terminology development process
  4. Daniel Hardman asked to merge his and Rieks PRs—APPROVED BY CONSENSUSDaniel Hardman asked to proceed with the ___________the PRs that he and Rieks Joostenhave submitted
    1. THIS WAS APPROVED BY CONSENSUS
  5. Paul Knowles asked about what the SDWG needs to get started with development of their glossary.
    1. This should be covered by the tutorial (see 3b above)

Action items