Skip to end of metadata
Go to start of metadata

Thursday, July 2, 2020, 10 AM US Eastern Time

Connection Info

To join the online meeting:

Attendees

Resources

Ontology Interest Group Google Folder https://drive.google.com/drive/u/0/folders/1RGBh4fDZdzpJdwyiUMO8OPWwkcmVYrI0

Google Doc for meeting notes:  https://bit.ly/2YPPBwq

Attendees

Agenda

  1. Github for Ontology work
    1. Where?
    2. How/process: issues/forks/pull requests
    3. Useful background/training/help guides
    4. Questions, comments
    5. What's next?

Notes

  1. Github for Ontology work
    1. VIVO Processes: https://github.com/vivo-project/VIVO/wiki/Git---GitHub-Processes
    2. General idea:  It’s just a bunch of files
    3. We work in the open
    4. Folder structure will be needed (ontology group can develop).  ODK was too complex.
    5. Where?
      1. ADO in mconlon17/ado on Github
      2. AEON in TIBonto/aeon on Github
      3. LANG in vivo-community/language-ontology on Github
      4. VIVO.owl (single file) in vivo-project/vivo on  GitHub
      5. Github vivo-ontology-lab (organization) unused
    6. How/process: issues/forks/branches/pull requests
      1. Fork to personal Github
      2. Clone personal fork to local
      3. Edit the local clone
      4. The remote is a connection from the local clone to github.  You typically have a connection to your fork.  You can create a remote to the canonical source.
      5. A branch creates a snapshot and is a safe place to work.  Code is isolated.
      6. Changes can be in three states:
        1. Local only
        2. Git add -- “plan to commit; staging”
        3. Git commit -- creates a bundle of changes to the fork
        4. Git pull request from the fork to the remote
      7. Principles
        1. Never work in master
        2. Always work in a branch
        3. Clean work:  Issue -> branch -> push to fork -> pull request to remote; One issue at a time.
          1. Github desktop makes this easier.
        4. A pull might have 8 commits -- fixing typos, making changes request by reviewers, etc.  A single commit (squash merge produces a single commit to the master branch) keeps the master branch commit history clean -- each commit is associated with a unit of work.
    7. Useful background/training/help guides
      1. A comparison of branching and forking: https://support.atlassian.com/bitbucket-cloud/docs/branch-or-fork-your-repository/ 
    8. Some suggestions
      1. If you are not using GitHub desktop, it might be helpful
      2. Recommend to review in detail the VIVO repo wiki document: https://github.com/vivo-project/VIVO/wiki/Git---GitHub-Processes
      3. We’re going to need to practice
  • No labels