I plan to update this comment with summary items of feedback for the tidymodels team based on the experience of developing {ordered}. (I keep misplacing notes i've left on paper and digital scraps.)
- Sensemaking and debugging: I've never gotten around to using helpful debugging tools, so i rely heavily on strategically-placed
print(), cat(), and save() commands throughout development code, in addition just to understand how different modules exchange information. Given the complexity of the tidymodels ecosystem, i might have been wise to take the opportunity to learn a more efficient toolkit. Would the team recommend some?
- Engine wrappers: These are relatively rare across {parsnip} and other extensions but are ubiquitous in {ordered}. As noted at some
REVIEW tags, i'm not confident that the wrapper is the better choice in each case, though in each case there is some justification for it. Especially as {parsnip} and its extensions expand to cover more tools, which because they are less common are likely to harmonize less with core conventions, some guidance on this choice would be useful.
- Prediction types: Different engines may provide different prediction options, and i did not find any guidance on which of these should be made available through {parsnip}. For example, as commented here, only another extension, {censored}, provides for
type = "linear_pred"; this would also be a meaningful option in {ordered}, but if it is to be provided by two extensions then should any of the machinery be moved to {parsnip} proper?
- Test coverage: I mimicked the test suites of other extensions, mostly {censored}, both in {ordered} itself and in the companion upgrades to {parsnip} and {dials}. Are these actually complete, or are they also works in progress? For sure any original tricks, such as those used in engine wrappers or
translate(), should be specifically covered. But my sense is that these packages are not expected to reach 100% coverage, and it would be helpful to have some guidance on what can be omitted.
- Longform documentation: Tidymodels is highly modular, so it makes sense that not every possible combination of tools warrants its own vignette. But i often wished that {censored} (from which i drew much inspiration) provided a self-contained data analysis as a vignette, and i plan to in {ordered}, though i don't know what the best level of detail and depth is best-suited to them, given the immense amount of documentation available for tidymodels as a whole.
I plan to update this comment with summary items of feedback for the tidymodels team based on the experience of developing {ordered}. (I keep misplacing notes i've left on paper and digital scraps.)
print(),cat(), andsave()commands throughout development code, in addition just to understand how different modules exchange information. Given the complexity of the tidymodels ecosystem, i might have been wise to take the opportunity to learn a more efficient toolkit. Would the team recommend some?REVIEWtags, i'm not confident that the wrapper is the better choice in each case, though in each case there is some justification for it. Especially as {parsnip} and its extensions expand to cover more tools, which because they are less common are likely to harmonize less with core conventions, some guidance on this choice would be useful.type = "linear_pred"; this would also be a meaningful option in {ordered}, but if it is to be provided by two extensions then should any of the machinery be moved to {parsnip} proper?translate(), should be specifically covered. But my sense is that these packages are not expected to reach 100% coverage, and it would be helpful to have some guidance on what can be omitted.