-
read the documentation below about the GitHub Workflow
-
find a source you'd like to ingest here (or make a new issue with the data source)
-
following the guidelines here to write a PR for the new ingest
Basic principles of the GitHub Workflow
- Prior to adopting the workflow, perform a one-time setup to create a personal Fork
of the appropriate shared repo (e.g.,
kg-covid-19
) and will subsequently perform their development and testing on a task-specific branch within their forked repo. This forked repo will be associated with that developer's GitHub account, and is distinct from the shared repo managed by the Monarch Initiative.
- Changes will never be committed directly to the master branch on the shared repo. Rather, they will be composed as branches within the developer's forked repo, where the developer can iterate and refine their code prior to submitting it for review.
- Each set of changes will be developed as a task-specific branch in the developer's forked repo, and then a pull request will be created to develop and propose changes to the shared repo. This mechanism provides a way for developers to discuss, revise and ultimately merge changes from the forked repo into the shared Monarch repo.
- Once a pull request has been merged, the task-specific branch is no longer needed and may be deleted or ignored. It is bad practice to reuse an existing branch once it has been merged. Instead, a subsequent branch and pull-request cycle should begin when a developer switches to a different coding task.
- You may create a pull request in order to get feedback, but if you wish to continue working on the branch, so state with "DO NOT MERGE YET".