TA extension packages - Lessons Learned & Next Steps

[manciniedoardo]

@bms63 @rossfarrugia and I had a discussion about TA Extension packages. @pharmaverse/admiral please see below some observations and propositions for how we approach the packages moving forward, and feel free to add your thoughts as well.

Current Paradigm

Development of extension packages has a number of issues:​

• No specific guidance on how to start. Unclear to TA teams that dev guidance on {admiraldev} must be followed for extension packages too.​

• Developers rely on heavy support from core team with R package development issues. Extension package development stunted unless a) someone from the core team offers hypercare-type support, or b) someone from the TA team joins the core team.​

• Developers sometimes unaware of existing {admiral} functionality (tendency to reinvent the wheel).​

• Very hard to upkeep core package programming standards.​

Some Observations

• Since ADaM is conceived as TA agnostic, and TA standards can widely differ across companies, TA package extensions shouldn’t contain many new functions. Some exceptions exist, eg:​

  • derive_var_studyeye in {admiralopthha} ​
  • derive_var_param_response in {admiralonco} ​

  but in general the R folder should be lean.

• ​Real work is in creating vignettes, examples, test data and templates and making sure the package is up-to-date with respect to new {admiral} releases (eg due to deprecations) - maintaining the package long-term is the only way to ensure its success.

• Beware of developing just for the sake of developing!

Propositions Moving Forward

• For every TA extension package, one developer (ideally technical lead) should be heavily involved with core team. No more developing in isolation!

• Augment extension package guidance on {admiraltemplate} with section about the value of vignettes, examples, test data and templates and the extension packages being lean, as well as expectations of creating the extension package. Also encourage understanding of core admiral functions as well as core dev docs.

• Link extension package guidance in admiraldev. Describe tech Lead versus Product Owner Model and Expectations.

• Periodic (~6 months?) review of extension package contents by members of the core team to ensure nothing is duplicated. Additionally, we could use more frequent reviews at the beginning of a package extension (1 per month) This was way we can enforce standards and best practices.

[bms63]

These two discussion are related - #1982. Can we collapse into one?

[manciniedoardo]

@bms63 sorry, my scanning and memory seem to be subpar... 😂 I added the points from the other one into this more detailed discussion and closed it. Hope that's ok.