• Tom pushed Rhyddian's use cases to GitHub (action complete)
• CCLA agreements: Refinitiv is in progress, FactSet complete, GreenKey complete
• Re archiving, Tom noted that this should be actioned once full migration to GitHub and to the FDC3 website is complete. Use cases 1, 6 and 7 are already in GitHub. (action on hold)
• Tom to present approval process today (action complete)
• Rob waiting to hear back from Jamie on any possible Wiki to GitHub migration tools

Introduced basic definitions

• Git - This is essentially document control, where docs happen to be source code files. Provides change tracking, audit control and versioning
• GitHub - Company that has put a UI on top and centralized the work via a hub enabling collaboration
• Issues - Used to for many purposes including starting discussions, commenting and raising bug reports, tasks, etc. Choose New Issue button to create a new issue.
• Call attention - use @Name to trigger a notification to the named individual
• Close an Issue - Appropriate permissions are required and you do this with the Close Issues button once issues have been resolved (one way or another). Issues can be re-opened. You can always see the full list of closed issues. Permissions are separate, e.g. suggesting changes vs. permanent changes. The group will need to request changes for FINOS. PMCs have been given admin access (Saori, Kat, JT)
• PR - Request for changes to be merged (accepted and incorporated). 

Presented approval process for discussion

• Noted that there are different types of changes, e.g. ratifying a standard or making minor text (clerical) changes, that require approval.
• Recommended that the PMC chairs are the gate keepers and responsible for confirmation, e.g. a necessary vote to approve a use case happened. For example, if Tom fixes a typo the PMC can then check it and accept.
• Because different changes may (or may not) need specific approvals, it is then up to the PMC to determine whether correct protocol has been followed, and then approve or reject the change.
• Tom has implemented a process whereby every change requires PMC (code owner) approval.
• Espen notes that FDC3 is merging into a single repository. Tom replied that it is easy to make these changes at a very granular level so could still work.
  

Demo

• Tom presented a demo of how to make changes, including 1) creating a fork, 2) making changes on the forked version, 3) committing the changes, 4) reviewing the changes and 5) approving/rejecting, 6) changes being successfully merged (or not if not accepted) and visible in the branched version. Next stage is 7) creating a PR to merge the changes from the branch into FDC3 master, 8) PMC reviewing and approving the PR (or not)  9) completing the PR merge.

• Pointed out certain elements of the markdown file, e.g. heading, where each # changes the level and dashes represent bullets.

• Use the preview tab to see if it is correct.
• You can add specific reviewers (who will have an approval button)
• When adding new use cases (or other documentation) copy and paste can be helpful (if you are careful).
• When reviewing you can add a comment and approve or request changes. These will apply to everything in the PR, which can be multiple files.
• Also demo'd removing.

Riko shared the new doc site (https://rikoe.github.io/FDC3/) and provided a brief demo.

Discussion on whether it is necessary to have FDC3 Use Cases specific permissions (and other groups) in the new common central FDC3 repo to be raised at FDC3 PMC.