Skip to content

Contributing

These guidelines are for contributors who clone this repository to run or change the dashboard. They are not required to use the deployed application.

Terminal window
npm install
npm run dev # http://127.0.0.1:43127

Without NEO4J_*, the app serves static JSON under apps/web/data. For Aura Free or local Neo4j and seeding, see docs/neo4j-aura.md.

Install rustup so cargo is on PATH (%USERPROFILE%\.cargo\bin on Windows).

Windows MSVC: host cargo test / cargo build / npm run build:wasm need link.exe. If you see linker link.exe not found:

  1. Install Build Tools for Visual Studio 2022.
  2. Select workload Desktop development with C++ (include the MSVC toolset and Windows SDK for your CPU — ARM64 tools on Snapdragon).
  3. Open a new terminal (or the ARM64/x64 Native Tools prompt) and confirm where link.
  4. Then: cargo test -p surv_engine and npm run build:wasm.

Until Build Tools are installed, run the same checks in Docker (Linux image has a linker):

Terminal window
docker run --rm -v "${PWD}:/app" -w /app rust:1-bookworm cargo test -p surv_engine -p surv_wasm

Prebuilt wasm under apps/web/lib/surv_wasm/ may already be present; regenerate with npm run build:wasm after the linker works.

Internal planning lives in the Linear project 2026 BDBV outbreak dashboard (team BDBV / 2026 Ebola Dashboard). Linear is the source of truth for open work.

Where to open GitHub Issues

Surface Repository
Map / public /app reads diaphana-io/2026bdbv-dashboard (this repo)
Curate / Extract / Access / claim writes private diaphana-io/2026bdbv-curate

Both repos sync one-way into BDBV (GitHub → Linear), not two-way. Prefer linking PRs to the current open items in the tracker; do not hard-code individual issue identifiers into README or other durable docs.

To enable sync (Linear workspace admin): Settings → Features → Integrations → GitHub → GitHub Issues → +, map diaphana-io/2026bdbv-dashboard and diaphana-io/2026bdbv-curate → team BDBV, choose One-way. See Linear GitHub Issues sync.

Every open GitHub Issue should carry exactly one area label so triage can filter surfaces:

Label Use for
curate Prefer opening on private Curate (2026bdbv-curate: UI/API, Extract, Access, claim writes). On this OSS repo only for rare Map↔shared-D1 cross-cuts.
map Public Map / dashboard surface: basemap, layers, incidence series, Rt/Cori, country-stats, map-facing snapshots
docs Starlight / public docs site, Privacy Policy, CONTRIBUTING sync, docs-only copy
other Neither Curate, Map, nor Docs primary: infra, CI, cross-cutting work with no clear product surface

Pick by primary surface, not by every phase that touches another system. Combine with type labels when useful (enhancement, bug, discussion, duplicate, …). Do not invent parallel area names; add a row here if a new area is needed.

  1. Work on a feature branch named <issue-number>-<short-slug> (for example 45-privacy-policy). Do not commit directly to main.
  2. Open a pull request targeting main.
  3. When a change relates to tracked work, link the relevant issue in the PR description (for example Closes #45; see Issue tracking).

Continuous integration runs bash scripts/verify.sh all on push and on pull requests to main (see .github/workflows/ci.yml).

Before each push, run the commit-unit gate that matches your change (or all):

Terminal window
bash scripts/verify.sh scaffold # or schema|engine|curation|all
  • UI language: English only.
  • Data: Prefer curated official and news sources; keep unresolved contradictions visible until a human resolves them (see Data and provenance in the README).
  • Extract: Automated extract stays disabled in production until decided through the project’s issue tracker (issue-based gating).
  • Secrets: Do not commit .env, credentials, or other secrets.