ropensci / statistical-software-review-book

Guide for development and peer-review of statistical software
https://stats-devguide.ropensci.org
42 stars 11 forks source link

Documentation of review for Validation #21

Open elimillera opened 4 years ago

elimillera commented 4 years ago

Hey all, I'm curious what everyone thinks about the documentation or "end-product" of the review. Validation in the pharmaceutical space is mostly concerned around the documentation of the reviews and how they were conducted rather than the review itself. Section 8.8 could contain information about how the review will be documentation and provide useful information for R admins when they are qualifying their systems if requested by a regulatory authority. I think this information could just be the basic information about the process and the package. The who, what, and when would likely be sufficient.

mpadge commented 4 years ago

Thanks for the input @elimillera. That's a good point you make, and definitely ideas that we will incorporate when we get to that phase. Some of the key ideas that will determine the form of what you're talking about will be a hopefully quite well defined and category-specific review template that is automatically generated in response to a submission. That template will itself be linked to the current version of the Standards, and will include the version number. So a reference for regulatory authorities to the version number would be the key thing you'd get, in addition to the aspects you suggest (link to the actual review, date, and reviewer names).

And then there's a "but wait there's more ...": We are also hoping to expand the scope of review in the additional sense of structured post-review code interventions. Each of these will provide further opportunity for the code to the updated to latest standards, and so to update version number. That will alleviate problems you might otherwise have comparing risk between a relatively new package that is of lower quality yet meets latest standards versus an older package that is comparably better. Regardless of how long ago a review occurred, any actively developed package may be expected to be continually updated to meet current standards, and so to be labelled accordingly. Your risk-based context is actually a really strong argument for the importance of that kind of system - thanks!