Demo how Forks and PRs are going to work

[AlexanderPico]

PRs could be made against a draft branch. A mostly automated curation process could accept PRs into this branch, where they can be later curated by the admin team and merged into the release branch later.

Or new edits could be PRs against a draft repo. The repo could have it's own GitHub Pages site so they could be previewed and assessed in a more mature form (i.e., in images and other converted forms). The curation admin team would then copy/move them to the official repo for release.

[AlexanderPico]

Notes from our tests during 11/17 meeting:

• When a PR is made, maintainers of the parent repo (us) automatically have write access to the forked repo while the PR is active (it's a checkbox option; checked by default). When canceled or merged, then the access is revoked.
• While a PR is active, all subsequent commits to that forked repo are automatically added to the PR.
• In order to avoid complicated PRs including commits across multiple pathways, we want to either:
  1. Immediately check, process and merge PRs, or
  2. Create a new branch for every commit on the forked repo, or
  3. Explore "branchless" ways of combining and managing commits and PRs (Anders)

[AlexanderPico]

Notes from 7/19/24 meeting with Tina:

• Early version of PV3 plugin for pathway submission
• Initial edits to a new or existing pathway will be saved in a local cache by PV3
• Only at the time of "submit for review": \
  • PV3 will login to GH
  • Add GH account name to author list in GPML
  • update/create fork
  • commit and push GPML to fork
  • create pull request
  • GH actions are triggered
  • See notes on WPID management: https://github.com/wikipathways/sandbox-wp-db/issues/2