Skip to content
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions posts/epi-community-contrib/index.bib
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
@article{hellewellFeasibilityControllingCOVID192020,
title = {Feasibility of Controlling {{COVID-19}} Outbreaks by Isolation of Cases and Contacts},
author = {Hellewell, Joel and Abbott, Sam and Gimma, Amy and Bosse, Nikos I and Jarvis, Christopher I and Russell, Timothy W and Munday, James D and Kucharski, Adam J and Edmunds, W John and Funk, Sebastian and Eggo, Rosalind M and Sun, Fiona and Flasche, Stefan and Quilty, Billy J and Davies, Nicholas and Liu, Yang and Clifford, Samuel and Klepac, Petra and Jit, Mark and Diamond, Charlie and Gibbs, Hamish and Van Zandvoort, Kevin},
year = {2020},
month = apr,
journal = {The Lancet Global Health},
volume = {8},
number = {4},
pages = {e488-e496},
issn = {2214109X},
doi = {10.1016/S2214-109X(20)30074-7},
urldate = {2025-04-09},
langid = {english},
file = {/Users/lshjl15/Zotero/storage/NG9MCA47/Hellewell et al. - 2020 - Feasibility of controlling COVID-19 outbreaks by i.pdf}
}

@article{kucharskiCOVID19ResponseIllustrates2020,
title = {The {{COVID-19}} Response Illustrates That Traditional Academic Reward Structures and Metrics Do Not Reflect Crucial Contributions to Modern Science},
author = {Kucharski, Adam J. and Funk, Sebastian and Eggo, Rosalind M.},
year = {2020},
month = oct,
journal = {PLOS Biology},
volume = {18},
number = {10},
pages = {e3000913},
publisher = {Public Library of Science (PLoS)},
issn = {1545-7885},
doi = {10.1371/journal.pbio.3000913},
urldate = {2025-07-22},
copyright = {http://creativecommons.org/licenses/by/4.0/},
langid = {english},
file = {/Users/lshjl15/Zotero/storage/ZB4LABCU/Kucharski et al. - 2020 - The COVID-19 response illustrates that traditional.pdf}
}

@article{kucharskiEffectivenessRingVaccination2016,
title = {Effectiveness of {{Ring Vaccination}} as {{Control Strategy}} for {{Ebola Virus Disease}}},
author = {Kucharski, Adam J. and Eggo, Rosalind M. and Watson, Conall H. and Camacho, Anton and Funk, Sebastian and Edmunds, W. John},
year = {2016},
month = jan,
journal = {Emerging Infectious Diseases},
volume = {22},
number = {1},
pages = {105--108},
issn = {1080-6040, 1080-6059},
doi = {10.3201/eid2201.151410},
urldate = {2023-05-23},
file = {/Users/lshjl15/Zotero/storage/98HLKB9J/Kucharski et al. - 2016 - Effectiveness of Ring Vaccination as Control Strat.pdf}
}
77 changes: 77 additions & 0 deletions posts/epi-community-contrib/index.qmd
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
---
title: "Epiverse community engagement and software sustainability for research software"
author:
- name: "Joshua W. Lambert"
orcid: "0000-0001-5218-3046"
date: "2025-07-22"
categories: [open-source, R, R package, epidemiology, community, Epiverse, DOI]
bibliography: index.bib
format:
html:
toc: true
---

Software that is developed for research or by researchers can be difficult to maintain given the incentive and funding structures in academia. This remains true for epidemiology, with a large volume of software written during the COVID-19 pandemic, much of which is now abandonware[^1]. This does not mean that the software developed to understand the COVID-19 pandemic was bad or does not have utility in understanding future epidemics and pandemics, but just that the capacity to maintain and further develop these tools is not available now the pandemic is no [longer considered an acute public health emergency](https://www.who.int/news/item/05-05-2023-statement-on-the-fifteenth-meeting-of-the-international-health-regulations-(2005)-emergency-committee-regarding-the-coronavirus-disease-(covid-19)-pandemic).

These issues around software sustainability and the academic structures that hinder software longevity were raised by @kucharskiCOVID19ResponseIllustrates2020 and were one of the leading reasons for the [Epiverse-TRACE initiative](https://epiverse-trace.github.io/). Alongside the developing novel software (R packages), Epiverse also has a commitment to support the community of package developers in epidemiology and outbreak analytics.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last sentence bothers me mildly; maybe more like One of the key Epiverse objectives is "[pull quote from proposal]".? Not sure what that pull quote looks like, but the current wording here is a bit awkward. I also don't think its necessary to invoke that y'all also mint new software.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've gone through some of the early documentation for the project proposal and couldn't find any information that would fit into this context. Related is the mention of the CSCCE Community Participation Model.

I also don't think its necessary to invoke that y'all also mint new software.

I wanted to phrase it this way as I didn't want it come across as contributing to other software is our primary activity. (Added bonus for advertising our tools).


This blog post highlights some recent work by Epiverse software engineers to collaborate on research software, or researchware, to help develop an R package that was initially written in the early days of the COVID-19 pandemic (January 2020 - May 2020) and built on code written for the 2014-2016 West Africa Ebola outbreak. Code that has provided insights into ring vaccination [@kucharskiEffectivenessRingVaccination2016] and isolation and contact tracing effectiveness [@hellewellFeasibilityControllingCOVID192020]. Thus it could be of great help in future infectious disease outbreaks, but has been dormant for the past few years.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The text later focuses on improvements so I'd use that here:

Suggested change
This blog post highlights some recent work by Epiverse software engineers to collaborate on research software, or researchware, to help develop an R package that was initially written in the early days of the COVID-19 pandemic (January 2020 - May 2020) and built on code written for the 2014-2016 West Africa Ebola outbreak. Code that has provided insights into ring vaccination [@kucharskiEffectivenessRingVaccination2016] and isolation and contact tracing effectiveness [@hellewellFeasibilityControllingCOVID192020]. Thus it could be of great help in future infectious disease outbreaks, but has been dormant for the past few years.
This blog post highlights some recent work by Epiverse software engineers to collaborate on research software, or researchware, to help improve an R package that was initially written in the early days of the COVID-19 pandemic (January 2020 - May 2020) and built on code written for the 2014-2016 West Africa Ebola outbreak. Code that has provided insights into ring vaccination [@kucharskiEffectivenessRingVaccination2016] and isolation and contact tracing effectiveness [@hellewellFeasibilityControllingCOVID192020]. Thus it could be of great help in future infectious disease outbreaks, but has been dormant for the past few years.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe "refine"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went with "improve", resolved in 47d6936. I couldn't commit as part of the batch of other suggestions due to a conflict with another suggested change on the same line.


## The R package

The R package in question is [{ringbp}](https://github.com/epiforecasts/ringbp). The package has two pieces of functionality: 1) to simulate an infectious disease outbreak using a branching process model with non-pharmaceutical interventions; and 2) to calculate the proportion of simulated outbreaks that are contained (i.e. do not cause a large sustained human-to-human epidemic). The utility of the package's general model framework has been shown by serving as a template for other epidemiological research such as [post-exposure prophylaxis](https://sophiemeakin.github.io/pepbp/).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe also add other implementations based on ringbp, e.g. https://github.com/lgs85/covidhm and https://github.com/timcdlucas/ringbp

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a mention to both of these in 2cc2e67. I wasn't sure whether to link to the GitHub repo or the paper/pre-print that used them so decided to do both. I couldn't find a paper using {pepbp} but if there is one please point to it and I'll add a citation.


## The problem

It is understandable that because {ringbp} was written in haste to produce insights to inform pandemic response it did not adhere to all software best practices. Documentation, testing, code style and (computational) performance could be improved. Certain aspects of model code, like parameterisations, were fixed internally, not providing users the full flexibility that the model could allow.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first piece of work mentioned is the user interface but this is not mentioned here as a problem - add?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved in f5acabc.


## Epiverse contribution

In the recent months Epiverse has collaborated with {ringbp} developers Seb Funk and Carl Pearson, based at the London School of Hygiene and Tropical Medicine and University of North Carolina, respectively, to try and improve the R package, both internally and from the user-experience. The following sections will give brief summaries of some of the collaborative developments.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably somehow clarify that I'm also part of epiverse (and perhaps that that the package existed before), otherwise it may sound like an external collaboration which strictly speaking it wasn't.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree; also useful to emphasize i'm not epiverse, since (as I understand it) part of the epiverse remit is making these packages more external-collab/contrib-friendly?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added in parentheses both of your statuses with respect to Epiverse in 3bbe130.

External collaboration and contribution friendliness addressed in 906b8fc.

Copy link
Member Author

@joshwlambert joshwlambert Aug 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pearsonca I've phrased your role with Epiverse as external collaborator, if you'd like this rephrasing let me know.


### User interface

The user experience (API) of the package has been refactored. The main simulation function `scenario_sim()` remains, but its arguments have been modularised to better group model parameters and control arguments. This also makes the package easier to develop further without necessarily introducing many breaking changes and prevents the number of top-level function arguments from expanding.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be good here to give an example of before/after function syntax

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, show-don't-tell

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added old versus new scenario_sim() function signature in bd2a7cd.


The new API gives the user more control over the model's parameterisation. The incubation period is now specified by the user instead of being fixed to an estimate for COVID-19. The way offspring and delay distribution functions are specified also means that any distributional or non-parameteric form can be supplied, relaxing the assumption that the onset-to-isolation has to be a Weibull distribution.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again maybe give an example of how this is now specified?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully, the comparison between the old and new version shows how it's being specified differently. If not please let me know.


Users can now specify the proportion of presymptomatic transmission rather than having to understand the skew normal parameterisation used by the simulation model, making it easier to get started with the package for new users.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again I would put an example here which will really help people who don't know the package to follow

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, I think the comparison code chunks with the old and new scenario_sim() API should help readers see where these changes are, especially with the more informative argument names in the new version.


Lastly on user-facing changes, the naming and style of function arguments has been standardised for consistent use of [snakecase](https://en.wikipedia.org/wiki/Snake_case) style and abbreviations.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mention that this was previously a mix of stuff? (perhaps in "the problem" above)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem section mentions code style and here we mention standardisation so I would say it's implicit that there was a mix of styles previously. I'll leave as is, as I don't want the details to obfuscate the overarching message, I guess that if anyone is interested they can see the package changelog or version history (linked at the end of this post).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't the "Problem" section have various sections/paragraphs that describe the problems so that they're all in one place? Problems could be introduced as topic sentences in various paragraphs for each kind of problem.


### Documentation

Function documentation already used {roxygen2}, but did not make use of inheritance or comprehensively document the function output or usage. We used `@inheritParams` from {roxygen2} to deduplicate, added `@return` documentation to all functions. We also improved the function argument documentation by following a structure of: `<type>: description`, for example:

```r
@param sim a `list` with class `<ringbp_sim_opts>`: the simulation control
options for the \pkg{ringbp} model, returned by [sim_opts()]
```

Exported functions now have informative examples (`@examples`) to showcase how the functions should be used. Function examples now always run (removing `\dontrun{}`) to catch any errors.

The [{roxyglobals}](https://github.com/anthonynorth/roxyglobals) package has been added to automate the management of global variables with the use of the `@autoglobal` tag.

Vignettes are useful long-form package documentation. Thus far we've added one vignette to the package and plan to add more where relevant.

### Bug fixes

Perhaps more important that any of the software best practices and user interface is the correctness of the code. In our developments we've uncovered a few bugs in the previous version of {ringbp}. The timing of quarantining infected individuals, sampling from the onset-to-isolation distribution, and calculating the generation time from the incubation period have all been identified and fixed.

### Testing

- simulation correctness regression (snapshot) testing

### Miscellaneous

There are various other changes in {ringbp} from our work. Examples include: input checking, not specifying erroneous function defaults, updating the package website, and functions that return `data.table` objects no longer [return silently](https://cran.r-project.org/web/packages/data.table/vignettes/datatable-faq.html#sec:why-do-i-have-to-type-dt-sometimes-twice-after-using-to-print-the-result-to-console). Mentioned in the introduction, model performance has been incrementally improved, but we've not focused on this aspect, and the package will benefit from time spent focusing on this in the future; especially if the set and complexity of non-pharmaceutical interventions in the model expands.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
There are various other changes in {ringbp} from our work. Examples include: input checking, not specifying erroneous function defaults, updating the package website, and functions that return `data.table` objects no longer [return silently](https://cran.r-project.org/web/packages/data.table/vignettes/datatable-faq.html#sec:why-do-i-have-to-type-dt-sometimes-twice-after-using-to-print-the-result-to-console). Mentioned in the introduction, model performance has been incrementally improved, but we've not focused on this aspect, and the package will benefit from time spent focusing on this in the future; especially if the set and complexity of non-pharmaceutical interventions in the model expands.
There are various other changes in {ringbp} from our work. Examples include: input checking, not specifying erroneous function defaults, updating the package website, and functions that return `data.table` objects no longer [returning silently](https://cran.r-project.org/web/packages/data.table/vignettes/datatable-faq.html#sec:why-do-i-have-to-type-dt-sometimes-twice-after-using-to-print-the-result-to-console). Mentioned in the introduction, model performance has been incrementally improved, but we've not focused on this aspect, and the package will benefit from time spent focusing on this in the future; especially if the set and complexity of non-pharmaceutical interventions in the model expands.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"incrementally" seems a bit of an undersell - I recall getting some order of magnitude reductions in run times. That no longer hold?

I agree the point here isn't to do a systematic optimization comparison, but if there's a big gain, we should be able to brag a bit about the improvement.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just run a rough benchmarking comparison and the newest version of the package (min-gen-time branch on my fork) has approximately the same (if not marginally slower) runtime than the version before I started working on the package (using package version at dbf85c1). The newer version has smaller memory allocation. Therefore I'll keep the current wording which is ambiguous about "performance".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm! i guess things fell off w/ some flexibility introductions or when incorporating corrections that entail drawing more samples.


## Conclusion

The {ringbp} R package implements a simple but informative model for infectious disease transmission and interventions. When written it included many well-developed aspects, but the time constraints of real-time outbreak response meant several improvements were possible.

Epiverse-TRACE has the opportunity to not only develop new tooling for pandemic preparedness and response, but to contribute to the ecosystem of open-source software in infectious disease epidemiology. We hope that by covering the collaborative developments of {ringbp}, it can illustrate the benefits of bringing software up to date with best practices, and make tools available, accessible and robust when a new epidemic or pandemic occurs, in turn hopefully removing the need for redeveloping similar software in the future.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think there is scope for perhaps a reflection on sustainability / maintenance, which you mentioned extensively in the motivating intro? How do we ensure this is not again abandoned for 5 years (assuming it would be a problem if it was)?

Also perhaps there is scope for a final statement that we're hoping that this will make the package more useful for others and will re-visit the analysis for the paper (with ref to the cmmid ringbp repo) in the first instance?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the first item - maybe also lean into all the other contributor-friendliness-items you've added (contributor statement, code of contact, making issue templates, tag clean up, etc) [or will add prior to releasing blog]?

And plan for CRAN release?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think there is scope for perhaps a reflection on sustainability / maintenance, which you mentioned extensively in the motivating intro? How do we ensure this is not again abandoned for 5 years (assuming it would be a problem if it was)?

I did consider this but initially opted again as I don't think it would be a positive message. Given the current lifecycle stage of Epiverse-TRACE I'm not sure we can make any grand statements about long term improvements in the landscape for OSS for research. Specifically on "How to do we ensure this is not again abandoned for 5 years", I think this is outside the scope of the post and I'm not sure I have an adequate answer. If you disagree, or there is something specific you'd like the post to cover please suggest and I'd be happy to incorporate.

On the first item - maybe also lean into all the other contributor-friendliness-items you've added (contributor statement, code of contact, making issue templates, tag clean up, etc) [or will add prior to releasing blog]?

We could add this to the post but it's thus far not been added to the {ringbp} repository so would be similar to the Testing section of the post which requires some more work on the package before publishing. IIRC there hasn't been any discussion of code of conduct, issue or PR templates; the contributing document has been raised in epiforecasts/ringbp#109.

And plan for CRAN release?

This has been raised in epiforecasts/ringbp#128 and is the plan. It would be nice to publish this post in tandem with the {ringbp} release.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's a reasonably-but-not-overly optimistic statement here - that the flexibility, refactoring, expanded documentation, etc make it easier for other people to reuse it, which is the gateway for external contributors to engage with the project. That doesn't assure resources on it, but enables them.

I'd also argue that folding it into a larger effort (tho I guess Epiverse-TRACE is wrapping?), instead of just an isolated package, improves awareness.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that's a good point that I'd largely overlooked. I've added a paragraph to the Conclusion to hopefully address this point in 6743d36. Let me know if you think it needs reworking.

tho I guess Epiverse-TRACE is wrapping?

The project is moving into Phase II with a focus on implementation with training and maintenance of tools, so will have a reduced software engineering capacity.


All of the changes discussed in this blog post can be found in the [{ringbp} news](https://epiforecasts.io/ringbp/news/index.html). For details of developments see the [pull request history of {ringbp} on GitHub](https://github.com/epiforecasts/ringbp/pulls?q=is%3Apr+is%3Aclosed).

[^1]: [Defined by Cambridge Dictionary](https://dictionary.cambridge.org/dictionary/english/abandonware) as: "software that is no longer produced or supported by the company that originally made it".