Users & support
Pillar 3 — access requests, announcements and triage
This is a maintainer-facing page, and one of the three maintainer pillars.
The ongoing user-facing work: letting people in, telling them when something has changed, and getting their problems to the right place. None of it needs the data pipeline or release machinery, so it is the pillar that is easiest to hand over or cover short-term — provided it is written down, which is what this page is for.
Granting site-file access
Site files are not public downloads. Access is granted per person, and this is the most frequent recurring task in the whole of maintenance.
How the request arrives
Users are told — in the Accessing site-files vignette and in tutorial part 3 — to email malariaverse@imperial.ac.uk with:
- their name,
- their institution,
- their GitHub username, and
- a short description of the project the site files are for.
How to grant it
Add the user to the sitefiles team in the malariaverse GitHub organisation:
https://github.com/orgs/malariaverse/teams/sitefiles
That team membership is the access control. The Packit server that serves site files authorises against it, so adding someone to the team is the entire technical step — there is nothing to configure on the server itself, and nothing to send the user beyond a confirmation.
Note the team lives in the separate malariaverse organisation, not in mrc-ide.
What to check first
The details requested above exist so that a human can sanity-check the request, and the bar in practice is low — site files are research inputs, not sensitive data, and the default is to say yes to a plausible research use. What the check is really for is knowing who is using the data, so that they can be told when it changes.
The one thing worth getting right is the GitHub username, since a wrong or guessed username means the invitation goes nowhere and the user is left waiting.
There is currently no documented policy on what would constitute grounds for refusing a request. In practice this has not come up. If a genuinely awkward request arrives, it is a governance question for the group lead rather than something the person on the mailbox should have to decide alone.
What the user does next
Once they are in the team, fetch_site() works. The first call triggers an interactive GitHub device-flow authentication — a link and a code — and caches the credentials afterwards. Users hitting authentication problems usually either have not accepted the team invitation yet, or are missing orderly from the mrc-ide r-universe.
Telling people when things change
Users pin their work to the packages and site files they downloaded. When those move, somebody has to tell them, and there is no automatic mechanism.
The full coordinated process — branch across repos, bump versions, cut the archival snapshot tag if the site files are moving, publish a note, email the list — is on Versioning & releases. The support-side craft is in the last two steps:
The Latest changes note. The canonical template is site’s Latest-changes.Rmd vignette. A good one answers three questions in this order:
- What changed, in user terms rather than commit terms.
- Will my existing code still run? — say so explicitly, including the blunt version (“code written against the previous versions will likely not run unchanged”) when that is the truth.
- How do I reproduce what I had? — the specific pinned versions and site-file version, not a general gesture at reproducibility.
The email. Send it to malariaverse@imperial.ac.uk, pointing at the note rather than restating it, so there is one canonical description that can be corrected later.
A change to the site files themselves is just as breaking as a change to the packages, even though no package version moves. If a new site-file version changes results, it needs the same announcement.
Where issues should go
There is no central issue tracker; each package uses its own. Routing:
| Symptom | Where it goes |
|---|---|
| Can’t download a site file; authentication fails | site issues |
| Site-file contents look wrong for a country | site issues |
| Model behaviour, parameters, interventions | malariasimulation issues |
| Output processing, rates, DALYs | postie issues |
| Calibration to a target prevalence | cali issues |
| Future scenarios | scene issues |
| The pipeline that builds site files | foresite-orderly issues |
| These tutorials or maintainer pages | malariaverse issues |
Two routing traps worth knowing:
- “The model gives odd results for country X” is usually a site-file or calibration question, not a
malariasimulationbug. Check the run period first (below). - “
fetch_site()doesn’t work” is usually access, not code — check team membership before opening anything.
Questions that come up repeatedly
Worth having an answer ready for, and worth checking the docs still cover:
“Can I run the site file just for the years I care about?” No — and this is the most common serious misconception. The model is path-dependent and the site-file EIR is calibrated over the full historical period, so a run starting in 2019 is simply wrong. Run the full period plus a burn-in and subset the output afterwards. Covered in tutorial part 3, with the mechanism explained on Site files & data.
“Which version should I use?” If they are on the current site-file release, the current packages are the right answer — that pairing is the one the group maintains. If they are working from an older site-file release, point them at the package tag named after it (e.g. mrc-ide/site@malariaverse_01_2025), which freezes the package set that goes with it. See how package tags relate to site-file releases.
“My results changed and I didn’t change anything.” Almost always an unpinned dependency: either fetch_site() picked up a newer site file, or packages tracking default branches moved underneath them.
“Can I model P. vivax?” Yes — malariasimulation implements a vivax-specific model, and site files carry fitted vivax EIRs. Note that SMC, RTS,S and PMC are not implemented for vivax.