Release plan

[athowes]

Version 0.1.0 of the functionality for this package is due to be complete around ~9th of September. I think that we should have a plan for how we get initial feedback and generate interest in the package. Here are some suggestions. Please use the comments in this issue to:

1. Support particular ideas
2. Strengthen ideas
3. Be against ideas
4. Suggest new ideas

Tagging @seabbs @kgostic @parksw3.

Ideas

• [ ] Early adopters: Identify and invite potential users who would benefit from the package and are likely to provide valuable feedback. This might involve: a. Listing potential users b. Sending them materials and a suggested onboarding method to the package (to be honest this suggested onboarding should be very clear from the README.Rmd in my opinion) c. Listing key questions/uncertainties we have that users might want to give input on c. Having a follow-up call with them for 15 minutes to gather their feedback (I'd say that a risk with this approach is that it has a lot of friction in it.)
• [ ] Publish a blog post or announcement: I'd be happy to write a short blog post or Twitter thread introducing the package. We should also look to make use of @seabbs audience and sway within the industry. There are also other senior/influential people on the papers
• [ ] Epinowcast community seminar: it's my understanding that they're looking for people to give seminars. I think ideally the seminar would involve some engagement and wouldn't be structured as a talk, as I don't think this is the best way to recieve feedback
• [ ] Rt collabathon (September 24-26, 2024): I believe that @seabbs (and @kgostic?) are attending. Is there a way that we could use this opportunity?
• [ ] CFA seminar: we could give some kind of presentation internal to CFA. As with the Epinowcast community seminar, I'd be quite keen to structure this so that if it's a 1 hour slot, at least 30 minutes of that 1 hour is spent by audience members engaging with the package rather than listening to someone talk. One version of this would be that I port the vignettes to Word, allow for comments, then we spend 30 minutes asking people to read and give comments live in Word on the vignettes.
• [ ] MLGH seminar: this is my old research group, I think likely I could give a short talk/pitch of the package. These are more a bit more likely to be methods/theory people rather than very applied, so somewhat a different audience
• [ ] Mailing lists: are there mailing lists of users that might be interested? We could craft a short email, sending users to the vignettes or README landing page
• [ ] Existing papers: there are the Park et al. and Charniga et al. preprints, both not published yet. We should use these an an opportunity to bring users into the package and disseminate ideas.
  • Park et al.: as this is more about theory, I think an option here would just be a sentence at the end stating which model is available in epidist (with the flexibility we have in 0.1.0) and that there are plans to continue to develop. i.e. "the paper code for this analysis has been generalised into a more user friendlly/facing R package which has features X, Y, and Z"
  • Charniga et al.: this is about best practises and aimed at a more applied audience. In my opinion this paper should be quite tightly coupled with the package. Given that the readers of the paper are unlikely to be able to easily implement the best models described in the paper themselves, I think an important purpose of the paper would be to onboard users to epidist. In some ways, the material in this paper would be good presented as a non-static document on the package website as a vignette. Of course papers have different audiences from vignettes, so I think there is a reason to have both, but I do think it'd be worth exploring which aspects of the paper we could port to a vignette / versus rely on pointing to. I suggest we set-up a meeting with the authors of this paper and talk about how the text could be updated based on 0.1.0 of epidist (if that fits with the publication timelines)
• [ ] Package paper: as well as these methods/applied papers we could write a software paper which would be more about the design and use of the package. Could try to publish this in R Journal etc. I'd guess we are too early stage for that but something to have on the radar for next version in my opinion
• [ ] StanCon: this event is 9th - 13th September. This wasn't feasible logistically, but I think this would be been a good event to present at
  • On that topic, perhaps it's possible to make some kind of thread / advertise on the Stan forum. Don't want to annoy them, so will have to investigate if they like this or not
• [ ] This isn't an idea as such, but I'd like us to build out the FAQ page (as suggested in #182). I think we can use these avenues to do this. If a question is asked more than once it should be an FAQ. It's easy to do this, and I think we should default to giving lots partial/bad answers quickly over being perfectionist about it

[seabbs]

Just flagging I have read this and these all seems like good ideas. Will respond with some ranking/tier list today.

[athowes]

This is not urgent so although ranking/tier welcome today not required. (Though I suppose the sooner we know the plan the sooner we can start moving some things forward, but anyway the main thing to move forward is the codebase.)

[kgostic]

Awesome, thanks for putting this together @athowes. Some comments:

Early adopters: Identify and invite potential users who would benefit from the package and are likely to provide valuable feedback. This might involve: a. Listing potential users b. Sending them materials and a suggested onboarding method to the package (to be honest this suggested onboarding should be very clear from the README.Rmd in my opinion) c. Listing key questions/uncertainties we have that users might want to give input on c. Having a follow-up call with them for 15 minutes to gather their feedback (I'd say that a risk with this approach is that it has a lot of friction in it.)

This seems like a good idea, but I think it may be too much work for not enough reward.

Publish a blog post or announcement: I'd be happy to write a short blog post or Twitter thread introducing the package. We should also look to make use of @seabbs audience and sway within the industry. There are also other senior/influential people on the papers Epinowcast community seminar: it's my understanding that they're looking for people to give seminars. I think ideally the seminar would involve some engagement and wouldn't be structured as a talk, as I don't think this is the best way to recieve feedback

These are good ideas

Rt collabathon (September 24-26, 2024): I believe that @seabbs (and @kgostic?) are attending. Is there a way that we could use this opportunity?

I think this is going to be out of scope for this meeting. I don't even think there are going to be talks, and the focus is very strictly on Rt, which is unrelated to epidist.

CFA seminar: we could give some kind of presentation internal to CFA. As with the Epinowcast community seminar, I'd be quite keen to structure this so that if it's a 1 hour slot, at least 30 minutes of that 1 hour is spent by audience members engaging with the package rather than listening to someone talk. One version of this would be that I port the vignettes to Word, allow for comments, then we spend 30 minutes asking people to read and give comments live in Word on the vignettes.

I think this is a good idea, but for CFA may need to be a Division meeting slot

Other ideas:

• We meet monthly with ECDC and with the Canadian Public health agency. It would be great if you could present there
• Could present on the MIDAS call once they re-start in the fall
• KG likely will talk about this when giving a seminar at UGA in October

MLGH seminar: this is my old research group, I think likely I could give a short talk/pitch of the package. These are more a bit more likely to be methods/theory people rather than very applied, so somewhat a different audience I think this is probably out of scope for CFA-related work, but you could invite them to epinowcast or do this on your own time!

Mailing lists: are there mailing lists of users that might be interested? We could craft a short email, sending users to the vignettes or README landing page

Existing papers: there are the Park et al. and Charniga et al. preprints, both not published yet. We should use these an an opportunity to bring users into the package and disseminate ideas. Park et al.: as this is more about theory, I think an option here would just be a sentence at the end stating which model is available in epidist (with the flexibility we have in 0.1.0) and that there are plans to continue to develop. i.e. "the paper code for this analysis has been generalised into a more user friendlly/facing R package which has features X, Y, and Z" Charniga et al.: this is about best practises and aimed at a more applied audience. In my opinion this paper should be quite tightly coupled with the package. Given that the readers of the paper are unlikely to be able to easily implement the best models described in the paper themselves, I think an important purpose of the paper would be to onboard users to epidist. In some ways, the material in this paper would be good presented as a non-static document on the package website as a vignette. Of course papers have different audiences from vignettes, so I think there is a reason to have both, but I do think it'd be worth exploring which aspects of the paper we could port to a vignette / versus rely on pointing to. I suggest we set-up a meeting with the authors of this paper and talk about how the text could be updated based on 0.1.0 of epidist (if that fits with the publication timelines)

Package paper: as well as these methods/applied papers we could write a software paper which would be more about the design and use of the package. Could try to publish this in R Journal etc. I'd guess we are too early stage for that but something to have on the radar for next version in my opinion

I think one of these should happen. If it's a separate paper, maybe just a brief writeup here: https://joss.theoj.org/

StanCon: this event is 9th - 13th September. This wasn't feasible logistically, but I think this would be been a good event to present at On that topic, perhaps it's possible to make some kind of thread / advertise on the Stan forum. Don't want to annoy them, so will have to investigate if they like this or not

This seems like a pretty niche application, so not really sure if this is our target audience.

[seabbs]

focus is very strictly on Rt, which is unrelated to epidist.

@kgostic I am a bit surprised by this statement as I thought the most useful areas of collaboration are really on inputs and outputs to Rt estimation? Unless the aim is to make people focus on the eval side or make direct contributions to Rt packages?

[parksw3]

I've also finished reading over just now. This all looks great. I will also try to finish up the long delay paper soon. I also think it's a great idea to write a package specific paper. Sam and I discussed briefly over a call with Kelly and there may be a few more methodological papers that could come out later on & I'm willing to put some more time/effort as I'm close to wrapping up some of the major projects from PhD, which should free up more time (things have been taking longer than I expected)...