Issue #337: Use family as string in Ebola vignette

[athowes]

Description

This is a draft PR to work on #337.

Checklist

• My PR is based on a package issue and I have explicitly linked it.
• I have included the target issue or issues in the PR title in the for Issue(s) issue-numbers: PR title
• I have read the contribution guidelines.
• I have tested my changes locally.
• I have added or updated unit tests where necessary.
• I have updated the documentation if required.
• My code follows the established coding standards.
• I have added a news item linked to this PR.
• I have reviewed CI checks for this PR and addressed them as far as I am able.

[athowes]

Some things to try here:

• Try running ebola.Rmd locally on a Windows machine to see if the error reproduces
• Ensure any file paths in ebola.Rmd are OK on Windows
• Use options(stringsAsFactors = FALSE): some R functions (especially older ones) may behave differently on Windows if stringsAsFactors is set differently
• Check for warnings suppressed on Ubuntu
• Check for differences in locale or encoding and set the locale explicitly in the R session for the vignette and specify encoding (e.g., UTF-8) in ebola.Rmd to prevent issues.

[athowes]

@seabbs to have a look at this.

[seabbs]

I don't want to be annoying and I know I drove this but I have just gone through the brms vignettes and help files and it looks like they are moving more and more towards using lognormal() vs a string.

Given that and given our annoying problem here shall we just return to doing so as well?

we dropped this before because we needed to write brms for it to work and it was clunky. When we made the change we also suggested we could export just the families we support (as we need to write custom functionality) and I think this does make sense.

[seabbs]

We would do this using this approach and enforce all new models to hit all currently supported families: https://forum.posit.co/t/best-practices-for-documenting-re-exports/89254

[seabbs]

If we agree we want to do this I am happy to make the code changes ahead of the release next week (also happy for @athowes to cover)

[athowes]

I'm fine with using brms::lognormal() if we can't resolve this bug.

[seabbs]

So I am saying we reexport and so don't use brms:: just lognormal()

[athowes]

Yes I am on the same page. Was just using brms::lognormal() to clarify which function rather than that we explicitly call it (but can see how that would have been confusing).