2018-08-23 uc-wg meeting notes

There are 15 use case that are now ready for review and (potentially) approval. The group discussed and confirmed the process and timelines for the use case review as follows.

Use Case Acceptance Guidelines 

• Leslie noted that there was a recent change to the guidelines making the persona more straightforward with detail being moved to a separate page.
• It was also noted that 1 or 2 tech use cases will be reviewed in this first review process and this experience will be used to discuss/review inclusion of technical use cases in the future.
• Saori raised a motion to approve the guidelines. There were no objections and the motion was passed to approve the Use Case Acceptance Guidelines.

Use Case voting logistics

Dates

• 23rd Aug (today) - cutoff for adding new use cases for review

• 6th Sept - deadline to review and comment on use cases, which will also be discussed at the working group meeting.

Review

• Saori and Jonathan proposed that where there are minor issues likely to cause rejection these could be changed by the use case owner during the review cycle. The group agreed that this "in review" status was appropriate. This should me managed through comments in the use case.
• All comments and feedback on the use cases will be tracked through Confluence in the use cases themselves or, if necessary, in meeting notes. 
• As participants review the use cases they should provide comments indicating their voting inclination and reason. For example (guidance only),
  • "I have these concerns..."
  • "This is how I will vote because..."
  • "I will likely reject because this doesn't seem like a valid persona."
• Review cycles will be ongoing, e.g. after this review cycle has closed (voting completed) a new cycle will be established. Rejected use cases can be re-submitted after being amended and new use cases can also be submitted. Re-submitted rejected use cases will take priority over new ones.

Rejection

• A use case may be rejected if it is similar to another use case.
• A reason must be provided for all rejected use cases.
• Rejected use cases can be refined and re-submitted for approval (for minor changes this may be possible during the review as noted above, for larger changes re-submission into next use case review cycle will be possible).
• Rejected use cases will be kept as guidance for the working group to use in the future.

Voting

• Use Case acceptance voting will be completed via email Google Groups (confirmed that all existing participants can access Confluence, i.e no corporate blocks).
• Leslie queried whether each individual in the working group gets a vote or each organisation gets a vote (e.g. do Adam and Leslie from Tick42 both get to vote or is it one vote between them). (Added after the meeting: Current FINOS guidance is here, indicating each individual gets a vote. However, it is the right of the group to agree their own procedures.) 
• It was agreed that Jonathan would send the email(s) for the vote, including stating the date by which votes must be received to be counted. This will be sent following the meeting on the 6th. He also queried whether there should be some enforcement on who can vote, which the group discussed.
• Saori raised the motion that only those individuals who have made comments on the use cases are able to vote. There were no objections and the motion was passed.
• This voting model will remain in place unless/until the group chooses to revisit it following updated FINOS guidance.