Version v0.0 of the documentation is no longer actively maintained. The site that you are currently viewing is an archived snapshot. For up-to-date documentation, see the latest version.

Priority 1: Launch ready4 Minimum Viable Product (MVP) systems model

We want to give potential users confidence that they can appropriately apply ready4 to their decision problems by bringing all our existing development release and unreleased software to production release status.

Why?

All our software, regardless of status is supplied without any warranty. However, our views about whether an item of software is potentially appropriate for others to use in undertaking real world analyses can be inferred from its release status. If it is not a production release, we probably believe that it needs more development and testing and better documentation before it can be used for any purpose other than the specific studies in which we have already applied it. Partly for this reason, it is unlikely that any item of our software will be widely adopted until it is available as a production release. We also cannot meaningfully track uptake of our software until it becomes available in a dedicated production release repository. We need a critical mass of modules available as production releases so that they can be combined to model moderately complex systems.

What?

By bringing all our current development version and pipeline libraries to production release, we aim to launch the ready4 Minimum Viable Product (MVP) systems model. The MVP model will comprise our modelling framework plus an initial skeleton of production ready modules for modelling people, places, platforms and programs.

The most important types of help we need with achieving this goal are funding, code contributions, community support and advice.

How?

The main tasks to be completed to bring all of our existing code libraries to production releases is as follows:

  1. (For unreleased software) Address all issues preventing public release of code repositories (e.g. fixing errors preventing core functions working, removing all traces of potentially confidential artefacts from all versions/branches of repository, etc.).

  2. (For code libraries are implemented using only the functional programming paradigm) Author and test new modules.

  3. Write / update unit tests (tests of individual functions / modules for multiple potential uses / inputs that will be automatically run every time a new version of a library is pushed to the main branch of its development release repository).

  4. Enhance the documentation that is automatically authored by algorithms from our model authoring tools. This will involve some or all of:

  1. Adding human authored documentation for the modules contained in each library.

  2. (For some libraries) Adding a user-interface.

When?

Our production releases will be submitted to the Comprehensive R Archive Network (CRAN). CRAN does not allow for submitted R packages to depend on development version R packages, so the dependency network of our code-libraries shapes the sequence in which we bring them to production releases.

The planned sequence for bringing current development release code libraries to production releases is:

  1. Three of the six framework libraries - the ready4 foundation followed by the ready4show and ready4use authoring tools.

  2. The seven module libraries that are sufficiently developed to have been used in real world scientific studies, in the following order: youthvars, scorz, specific, TTU, youthu, mychoice and heterodox.

  3. The very early stage bimp library from the modelling programs pipeline,

  4. The three remaining computational model authoring tools framework libraries, starting with ready4fun, then ready4class and finally ready4pack.

The planned sequence for bringing unreleased code first to development releases and then to production releases is:

  1. The four development module libraries from the modelling places pipeline (the library for synthesising geometry and spatial attribute data, followed by the spatial attribute simulator, the prevalence predictor and user interface libraries).

  2. The two module libraries from the modelling people pipeline (the synthetic household creation library and that agent based modelling library).

  3. The three module libraries from the modelling platforms pipeline (the primary mental health service discrete event simulation, followed by the early psychosis cohort model, followed by the service system eligibility and referral policy optimisation model).

How quickly we can launch production releases of all our code depends on how much and what type of help we get. Working within our current resources we expect the first of the 23 libraries listed to be released early in 2023 and the last during late 2025. With your help this release schedule can be sped up.

Last modified January 20, 2023: added advice contribution (d69d2bf)