Maintainers
What maintaining the malariaverse actually involves
These are maintainer-facing pages. If you just want to use the packages, start with the tutorials.
Maintaining the malariaverse is three fairly different jobs that happen to share a name. They need different skills, different access, and — realistically — often different people. This page sets out what each one is and where the detail lives.
The three pillars
| Pillar | What it covers | Who can do it | |
|---|---|---|---|
| 1 | Site files & data | Building, calibrating and publishing the site files that fetch_site() serves |
Imperial only |
| 2 | Packages | Keeping the R packages versioned, compatible and releasable together | Anyone |
| 3 | Users & support | Access requests, announcements, issue triage | Anyone with team-admin rights |
Governance — who signs off on what — sits across all three.
1. Site files & data (the back end)
The data pipeline. Raw global datasets are collated per country, assembled into a site file, calibrated against observed prevalence, and published as versioned packets to a Packit server. This is the layer everything else rests on: when a user calls fetch_site(), they are downloading the output of this pillar.
Most of it can only be run from Imperial — see Site files & data.
2. Packages (the front end)
The R packages users actually install. The work is keeping them working together: some are coupled through the data they exchange rather than through declared dependencies, so a change in one can break another with no build failure to warn you.
- Versioning & releases — what is coupled to what, how to check compatibility before releasing, and how to coordinate a breaking change.
- Adding a package — the minimum bar, scaffold and house style.
3. Users & support
The ongoing, unglamorous, never-finished pillar. Granting site-file access, answering questions, telling people when something has changed under them, and routing bug reports to the right repo. See Users & support.
Where to start
Taking over the whole thing? Read this page, then Site files & data — it is the pillar with the most implicit knowledge and the hardest access requirements, so it is where a handover is most likely to fail.
Taking over one package? Versioning & releases is the one to read.
Covering support while someone is away? Users & support is self-contained.
Imperial-only steps
Some work needs Imperial infrastructure — the DIDE cluster and the malaria network share — and simply cannot be done from outside. Section headings covering those steps carry a badge, like the “Publishing a release Imperial only” heading on Site files & data.
These pages are public, so they describe what each step is and that it needs internal access. They do not carry credentials. Where a step is Imperial-only, the page says what the external equivalent is, if there is one.
The site-file pipeline lives in a public repository, but its large raw inputs do not: they are gitignored and absent from a clone. Reading the code tells you how site files are made; it does not let you make them. The supported route for everyone outside Imperial is fetch_site(). This is explained in full on Site files & data.
A note on version names
The string malariaverse_<MM_YYYY> names both a site-file release (e.g. malariaverse_06_2026) and a set of package git tags (e.g. malariaverse_01_2025 on site, postie, malariasimulation and the rest). They are related, but not in the way the shared name first suggests.
The rule is a single invariant:
The current site-file release works with the current
mainbranches of the packages.
Package tags are therefore archival, not concurrent. While a site-file release is current there is no package tag naming it — main is the supported combination. When a new site-file release supersedes the old one, every package is tagged with the name of the release being retired, freezing the last package set that works with it.
So the tags reading malariaverse_01_2025 while site files are at malariaverse_06_2026 is the system working as designed: 01_2025 preserves the previous world for anyone still using those site files.
For users: on the current site files, install the packages normally. On older site files, install the package tag named after that site-file release. Full detail on Versioning & releases.