Assuming the r-hub/repos is fruitful, it would be nice to have a few functions for demo'ing a user-friendly interaction with the repo.
Similar to the .Rprofile tools mentioned in dgkf/rvalhub-repo-filters-mvp, we could put the filtering criteria as a function into some package to represent a R Validation Hub "best practice".
[ ] Modify installed package DESCRIPTION post-installation to include metrics
[ ] Add PACKAGES file into inst directory
[ ] Function for specifying filters (maybe defaults for "low", "medium" risk?)
Ideally, function could look like
risk_fields()
# [1] "coverage" "examples_coverage"
# manually specify options
options(available_package_filters = risk_filter(coverage > 0.5 & examples_coverage > 0.8))
# or use a helper function to update options directly
add_risk_filter(coverage > 0.5 & examples_coverage > 0.8))
[ ] A very basic "report" that uses metrics/logs to populate a template
Even if it starts small, I think this will be a good way to share amongst ourselves our own scripts for testing the repo and eventually can house some best practices that might make a process easier to adopt.
I'm open to any and all suggestions for a repo name and am happy to kick one off if someone is interested in taking the lead.
Assuming the
r-hub/repos
is fruitful, it would be nice to have a few functions for demo'ing a user-friendly interaction with the repo.Similar to the
.Rprofile
tools mentioned indgkf/rvalhub-repo-filters-mvp
, we could put the filtering criteria as a function into some package to represent a R Validation Hub "best practice".[ ] Decide on a package name
[ ] Modify installed package
DESCRIPTION
post-installation to include metrics[ ] Add
PACKAGES
file intoinst
directory[ ] Function for specifying filters (maybe defaults for "low", "medium" risk?) Ideally, function could look like
[ ] A very basic "report" that uses metrics/logs to populate a template
Even if it starts small, I think this will be a good way to share amongst ourselves our own scripts for testing the repo and eventually can house some best practices that might make a process easier to adopt.
I'm open to any and all suggestions for a repo name and am happy to kick one off if someone is interested in taking the lead.