2023-03-08 developer team meeting minutes

[wlandau]

• Kevin: Start with narrow scope, then broaden later. No random effects for now.
• Yoni: Allow flexible formulas like in {mmrm}.
• Kevin: For historical borrowing, let's use informative priors instead of a meta-analysis model.
• Kevin: Regarding recipes, it's an interface question. Pipes are potentially useful both for both preprocessing and to set options for a later mmrm fit call. Idea: pipe-ready recipe-like function in front of mmrm call, minus the caching and lazy eval in recipes itself.
• Yoni: Idea: add a few verbs that can be used in an existing recipes workflow. Example: https://github.com/tidymodels/themis.
• Kevin: Do not store dataset with the model object, for privacy issue.
• Will: Sounds like we have a consensus for exposing the data processing exposed to the user.
• Kevin: For data processing: pipe-friendly steps, return a plain tibble. Informative classed errors if people don't do that.
• Will: Let's consider a simulation function for both development and SBC.
• Kevin: Sample from the prior predictive distribution, also consider sampling from posterior predictive. Start with whatever brms does.
• Christian: Consider starting the implementation from brms and letting the syntax and features guide those of the wrapper package. Consider allowing full flexibility of brms.
• Kevin: The Novartis vignettes show how to do the analysis with just {brms}, without the additional layer on top of it we are planning to build.
• Christian: There is value is in the standardized MMRM output and postprocessing, typical plots, etc. That way, the user has the full flexibility of brms and helpers to make the repetitive postprocessing easy.
• Will: I think there is also value in making the modeling simpler too, especially for analysts who may not know what an MMRM is, but who need to churn out TFLs for a primary analysis. Maybe the summary functions could accept either a model from the wrapper or a custom MMRM from brms.
• Kevin: In that case, we would want to handle each case separately: a model from brms directly vs a model from the wrapper package.
• Christian: The former would require more checks and assertions to make sure it is the right kind of brms object.