Canonical Repositories
GeoEpi subproject repositories will normally be located in the GeoEpi GitHub organization, but the operating model also permits repositories in individual GitHub accounts, forks, external upstreams, and collaborator-owned organizations.
Every subproject should identify one canonical working repository. The future Hub points to that repository. It does not need to catalog every fork, mirror, or temporary branch.
Minimum subproject repository
A GeoEpi subproject repository should normally contain:
README.md;.gitignore;.geoepi.yml;- scientific code or workflow appropriate to the workstream;
- enough environment or dependency information to reproduce consequential work;
- a clear workflow or execution entry point;
- documented principal data inputs;
- controlled-data IDs when controlled project data are used;
- documented public or external analytical sources;
- clear output locations;
- known limitations or current issues where consequential.
This is a minimum adoption standard, not a universal folder tree. Do not require directories such as R/, scripts/, src/, tests/, docs/, config/, data/, or outputs/ for every workstream. Repository organization should serve the analytical workflow.
A canonical repository should make clear
- its parent project and subproject purpose;
- the lead or contact and current status;
- principal data inputs and controlled-data IDs;
- public or external data sources;
- the computational location;
- workflow entry points and expected outputs;
- reproducibility information and known limitations.
GitHub is generally used for code, version control, documentation, collaboration, and subproject repositories. Do not put credentials, tokens, controlled data, or large computational outputs in a repository. See Repository versus compute for the boundary with Atlas and Ceres.