I am currently working on my first ( ) network study. Super happy to be here and part of the community! I have a background in open source software development and in biomedical engineering. In many projects I have worked on in the past, especially software related ones, there was often a best practice I could follow, adopt, or adapt to my projects.
After perusing studies on the OHDSI Studies organization is there any sort of centralized best practices to ensure quality control of the creation of network packages for the OHDSI Community pertaining to testing, documentation and style guides, and dependency management? I could not immediately find something that is centralized - did I miss it somewhere?
We use renv for dealing with package depedencies. I recommend using this function to generate the renv lock file, as it will correctly handle versions of packages in the OHDSI GitHub.
Most study packages are (initially) generated using the ATLAS Estimation and Prediction tools, which generate study packages.
In general, the Book of OHDSI is a good place to start if you’re new to OHDSI.
Currently, there is a package in the R ecosystem called styler which does automatic formatting of your R scripts. The command I would suggest to use from this library is:
Awesome! I’ve been wresting with tidyr for a long time (even made my own wrapper). But styler seems to be much better! I’ll play with it for a bit, and this may become our new standard.
Hey @schuemie, on the topic of standards, is there any interest in a work group or discussion centered around creating centralized standards that give guidance on best practices in package development, steps to enhance reproducibility, and user experience? It seems that there is a slowly emerging critical mass of discussions that could intersect well based on the discussions here:
The discussion on standards for research packages have so far taken place in the HADES workgroup. This workgroup has decided the research packages fall under its care, although we’ve also been busy with lots of other stuff. I’m unsure whether having a separate workgroup for this is a good or a bad idea.
Ah didn’t know that was how the governance worked for the packages. Thanks @schuemie - I will plan on coming to the workgroup as as I can. But I lean more towards if HADES is already in charge of best practice, it is best to keep it to the HADES workgroup and not spawn off another workgroup.