2018-08-09 uc-wg meeting notes

Discuss and review the Process Proposal and Use Case Acceptance Guidelines governance proposal 

• Kat walked through the process proposal for use case approval
  • 3 Phases: Proposal, Accepted, Technical 
  • Process of approval
    • by consensus preferred (e.g., motion → second → "any objections? none heard the proposal is approved")
    • by majority vote if consensus can't be reached (good faith effort)
      • during meeting roll call voice vote or by email between meetings
  • Important to note why a rejected use case is rejected; Ratified use cases should be clearly marked and published on confluence
  • Leslie: We also need to get some response from downstream customers of the use cases (i.e., the other WGs in the program) to help us know if we're done.
    
    
• Kat led discussion had on proposal to continue use confluence to document use cases
  • Kat asked is there were any objections to use confluence to document use cases; none being raised the motion passed
    
    
• Leslie then walked though the process to review use cases leading up to approval (or rejection)
  • Leslie: We also need to think through role of technical use cases (note: this was as subsequent agenda item)
  • Leslie: We could have use cases that are valid but are not needed; we need to be careful to focus on those are needed. General agreement from floor that validity and usefulness are important considerations.
  • Leslie: Use case proposals are best discussed by comments in Confluence

• Discussion ensued on whether we should delineate technical roles in use cases (e.g., in house, product, vendor) or whether we can abstract that role in use cases to "technologist"
  • Kat: I do like the technical detail as it helps frame the use case
  • Tosha asked if the technologist role would also summarize roles like business analysts and CTO
    • Saori answered yes it would
  • Tom: less specificity here is better - we should abstract
  • Consensus of meeting participants was to abstract into a single "technologist" role and this was the adopted decision of the group.

• Group discussed that when we say "technical use cases" that can mean a couple different things, including
  • The amount of implementation details or technical specification included in an use cases
    • Example was "Seek a counter-party for a trade" vs. "Open a chat app to find a counter-party"; the discussion consensus was that the "open an chat app" was an implementation detail 
    • A use case for which the actor is a developer (i.e., not a financial desktop user such as a trader, but rather a developer of financial desktop software)
    • Group agreed that the discussion of inclusion or exclusion of "technical use cases" referred to the latter definition – use cases for which the developer is the actor
  • Tom

    • Tactically since we have not produced anything for downstream, we should limit our scope and do not controversial first

    • I do believe in separation of concerns … thinking about technical distracts from our business/product discussion
      

  • Leslie
    • Technical use cases are important (to include in our scope). Two reasons
      • The working groups are quite technical; the whole of the FDC3 work is quite standard
      • Use cases are being used in the WG to define the scope of the APIs and how they should be implemented.
        
  • Saori
    • We need to be careful to not use the phrase “technical use case” too loosely. We are not talking about the mechanics of how it’s getting done -- we are talking about a business that a technologist has -- this is not a functional requirements.
    • Believes that non technical uses cases can still fulfill the need to shape the standards in downstream working groups (without necessarily introducing developer-actor-specific use cases).
• Group agreed to do a vote by email to decide among the 3 proposals below:
  • Technical Use Case (Technical Participant is the actor) Out - for now
    Technical Use Case In but less priority
    Technical Use Case In with same priority