Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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 terms from Bedrock
    2. Daniel Hardman submitted terms from the Sovrin Glossary
    3. Rieks Joosten submitted terms from ESSIF Lab
    4. All of these use a baseline data model
    5. 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 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 Gisolfi proposed that there may be overlapping terms and 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 have reviewed the term for well-formedness, valid 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 <== requires review with the stakeholders
    3. We agreed that the same term can have:
      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., its definition is approved by one set of stakeholders (e.g., one WG) but not by another.
  3. Coordination with the Ops Team
    1. Drummond Reedsuggested 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 the CTWG and the Ops Team should collaborate to produce a tutorial covering the terminology development process
  4. Daniel Hardman asked to merge 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



  • No labels