thibautjombart
commented
2 years ago Just to flag a related issue with the current mode of storage.
I can see some pros/cons, listing some below. After writing this I might lean towards a dual system.
Store as csv (current version)
Assuming files are used for internal purpose and moved to inst/ (see related issue).
Pros
- simple
- decent visualization of the data from github page
- standard format
- contributions: relatively easy to edit and follow changes
Cons
- non-compact; but should not be a problem initially
- contributions will require a PR; clear guidelines and examples for contributing may mitigate the problem, but still a barrier to some
Store online
Assuming the package pulls in real time content off the web eg using googlesheet4.
Pros
- relatively simple
- very simple to contribute to
Cons
- adds a dependency on package pulling content
- no real version control on the database
- package cannot be used offline or with slow internet (timeouts), which is a real issue in resource-limited settings
- hazardous: any temporary issue with the database may impact users
Dual system
This would involve:
- having a user-facing database people can contribute to
- making periodic releases of the database (i.e. a timestamped and curated version)
- pulling the latest release into the package as a local csv file
- timing package releases with database releases
I think it would have most of the pros and not many of the cons. A bit heavier maintenance on our end, but some of the process may be automated.
It might be worth thinking about what we want to store (e.g. individual data points if available, or only summary statistics, sample size) and how to store them - csv probably fine for now but if we want to invite external contribution something like a curated google sheet might be more amenable (and could easily be imported here, or regularly updated).