Updating hubDocs to note hubUtils split into hubAdmin and hubData #101
Conversation
docs/source/user-guide/software.md
Outdated
| ## [`hubUtils`](https://infectious-disease-modeling-hubs.github.io/hubUtils/) | ||
|
|
||
| The goal of `hubUtils` is to provide a set of utility functions for downloading, plotting, and scoring models (e.g., forecasts) and truth data from Infectious Disease Modeling Hubs. You can find instructions to download and use the package [here](https://infectious-disease-modeling-hubs.github.io/hubUtils/). | ||
| Much of `hubUtils` has been moved and split across `hubData` and `hubAdmin`, and users are advised to use those packages instead. `HubUtils` still exists but is now a lightweight package that primarily contains general utilities imported by other hubverse packages. |
There was a problem hiding this comment.
I suggest writing this to assume that people are not aware of the prior state of hubUtils. E.g. this will be confusing for someone new to the software because they weren't aware of the prior state of hubUtils. So maybe just say something like hubUtils is a lightweight package...".
Also, I think even when at the beginning of the sentence, HubUtils should be hubUtils.
There was a problem hiding this comment.
Hi Nick, I addressed both these items, mentioning the split at the end, in case someone was a prior user of hubUtils.
docs/source/user-guide/tasks.md
Outdated
| @@ -32,7 +32,7 @@ Task ID variables can be thought of as columns of a tabular representation in a | |||
|
|
|||
| We note that some task ID variables are special in that they conceptually define a modeling "target" (these are referred to in the [tasks metadata](tasks_metadata) as a `target_key`). In our [Running Example 1](running-examples), the task ID variables are `target`, `location`, and `origin_date`. In this example, `target` is the target key and can only take on one value "inc covid hosp". In other examples, (such as [Running Example 3](running-examples)) more than one variable can serve as target keys together. In example 3,both 'outcome_variable' and 'outcome_measure' make up the target keys. | |||
|
|
|||
| Some task ID variables serve specific purposes. For example, every hub must have a single task ID variable that uniquely defines a submission round. It has become a convention to use a task ID like `origin_date` or `forecast_date` for this purpose, although in practice hubs could use other task ID variables for this purpose. In [Running Example 1](running-examples), this task ID is `origin_date`. Additionally, to plot forecasts using standard functionality in the `hubUtils` package for hubs with step-ahead short term predictions, hubs must have either `origin_date` and `horizon` task ID or a `target_date` task ID. | |||
| Some task ID variables serve specific purposes. For example, every hub must have a single task ID variable that uniquely defines a submission round. It has become a convention to use a task ID like `origin_date` or `forecast_date` for this purpose, although in practice hubs could use other task ID variables for this purpose. In [Running Example 1](running-examples), this task ID is `origin_date`. Additionally, to plot forecasts using standard functionality in the `hubVis` package for hubs with step-ahead short term predictions, hubs must have either `origin_date` and `horizon` task ID or a `target_date` task ID. | |||
There was a problem hiding this comment.
Additionally, to plot forecasts using standard functionality in the
hubVispackage for hubs with step-ahead short term predictions, hubs must have eitherorigin_dateandhorizontask ID or atarget_datetask ID.
This is not strictly true, as the function has an argument where you can specify the x_col_name. Maybe just delete this sentence?
There was a problem hiding this comment.
I deleted the "Additionally..." sentence. I hope that's enough.
nickreich
merged commit de629fa
into
Infectious-Disease-Modeling-Hubs:main
No description provided.