Replies: 1 comment 2 replies
-
This is a great question. I think building some conditions into the standards could be helpful, e.g. allowing authors to skip standards related to missing data in the general category if they have met standards regarding missing data in another, such as machine learning. Putting this into practice may be feasible. If authors request standards for the general category plus at least one other category, you can filter the standards presented in the general category (or mark them as optional) based on the other requested categories. Some tangential thoughts being able to mark some standards as not applicable to your software is very helpful. Checking off the standards for two categories took me a while, but I felt all of the standards that applied to my software helped me improve my documentation and also improve the package itself. I was confused by the following two categories:
My confusion was caused by the decision to put regression into the same category as supervised learning. They certainly do have an overlap (prediction models fitted with regression), but the overlap between ML and supervised learning is much larger so it made me uncertain whether my own software was in the first category or the second. I wonder if you could turn these two categories into three:
I think these three categories have very little overlap, hopefully making it easier for authors to figure out which one their software belongs in. It would not be easy to go back and restructure the standards though, so I completely understand if you choose not to act on this suggestion. Hopefully it is helpful! |
Beta Was this translation helpful? Give feedback.
-
rOpenSci's general software review process requires authors to identify one or more categories. Statistical software can also potentially fit into multiple categories, but authors are required to document compliance with all standards from each category. This is a considerable burden, and will pose a particular challenge for people who suspect their package might fit into multiple categories. Could there be any way to allow packages to fit multiple categories, while requiring them to comply with only a subset of all corresponding standards? We currently require compliance with at least half of all category-specific standards. Could this requirement be spread across multiple categories, requiring compliance with at least half of standards, regardless of which category they come from?
(And note that numbers of standards complied with is automatically generated by the
srr::srr_report()
function, so those numbers are easy to obtain.)Beta Was this translation helpful? Give feedback.
All reactions