Submission group 22: StrapvizR

Submitting Author Name: Margot Vore Submitting Author Github Handle: !--author1-->@voremargot<!--end-author1-- Other Package Authors Github handles: Julien Gordon (@BooleanJulien), Gautham Pughazhendhi (@gauthampughazhendhi) , Zack Tang (@zackt113) Repository: https://github.com/UBC-MDS/strapvizr Version submitted: V2.0.0 Submission type: Standard Reviewers: Rada Rudyak (@Radascript), Arushi Ahuja (@Arushi282), Zheren Xu (@ZherenXu), Anupriya Srivastava (@Anupriya-Sri)

Package: strapr
Title: Bootstrapped Confidence Intervals, Plots, and More
Version: 0.1.0
Authors@R:
    person("Gordon", "Julien", , "junigord@gmail.com", role = c("aut", "cre"))
    person("Tang", "Zack", , "zacktang113@gmail.com", role = c("aut", "cre"))
    person("Vore", "Margot", , "vore.margot@gmail.com", role = c("aut", "cre"))
    person("Pughazhendhi", "Gautham", , "gautham.pughazhendhi@gmail.com", role = c("aut", "cre"))
Description: The purpose of this package is to simplify and automate the process 
    of creating simple bootstrap distributions of numerical data columns. 
    The package will have a module which intakes a dataset column and relevant 
    parameters such as the desired confidence bounds and number of simulations. 
    The module will perform the simulation statistics to generate the bootstrap 
    mean distribution and relevant statistics such as the sample mean and 
    bootstrapped confidence interval. The package will also contain a module 
    for visualization of the bootstraped confidence interval, and a module for 
    creating a professional publication-ready table of the relevant statistics.
License: MIT + file LICENSE
Encoding: UTF-8
LazyData: true
Roxygen: list(markdown = TRUE)
RoxygenNote: 7.1.2
Suggests: 
    testthat (>= 3.0.0)
Config/testthat/edition: 3
Imports: 
    tibble,
    dplyr,
    knitr,
    kableExtra,
    ggplot2

Scope

Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):
- [ ] data retrieval
- [ ] data extraction
- [ ] data munging
- [ ] data deposition
- [ ] workflow automation
- [ ] version control
- [ ] citation management and bibliometrics
- [ ] scientific software wrappers
- [x] field and lab reproducibility tools
- [ ] database software bindings
- [ ] geospatial data
- [ ] text analysis
Explain how and why the package falls under these categories (briefly, 1-2 sentences):

This package was developed to assist with the creation of plots and tables related to bootstrapping statistical analysis. Our functions focus on creating reproducible plots and figures needed in DSCI 552 course in the MDS program.
Who is the target audience and what are scientific applications of this package?

This package was developed to assist anyone who wants to bootstrap and visualize sampling distributions with different estimators during statistical analysis (especially students in 552 course). The package takes care of the tedious tasks of bootstrapping and visualization, and helps the user focus on the actual analysis.
Are there other R packages that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category?

While the package has functions that perform bootstrapping, the package's main functionality is to create publication- ready visualizations thus we would categorize it as a data visualization package.
(If applicable) Does your package comply with our guidance around Ethics, Data Privacy and Human Subjects Research?
If you made a pre-submission inquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted.
Explain reasons for any pkgcheck items which your package is unable to pass.

Technical checks

Confirm each of the following by checking the box.

[x] I have read the guide for authors and rOpenSci packaging guide.

This package:

[x] does not violate the Terms of Service of any service it interacts with.
[x] has a CRAN and OSI accepted license.
[x] contains a README with instructions for installing the development version.
[x] includes documentation with examples for all functions, created with roxygen2.
[x] contains a vignette with examples of its essential functions and uses.
[x] has a test suite.
[x] has continuous integration, including reporting of test coverage using services such as Travis CI, Coveralls and/or CodeCov.

Publication options

[ ] Do you intend for this package to go on CRAN?
[ ] Do you intend for this package to go on Bioconductor?
[ ] Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:

MEE Options

- [ ] The package is novel and will be of interest to the broad readership of the journal. - [ ] The manuscript describing the package is no longer than 3000 words. - [ ] You intend to archive the code for the package in a long-term repository which meets the requirements of the journal (see [MEE's Policy on Publishing Code](http://besjournals.onlinelibrary.wiley.com/hub/journal/10.1111/(ISSN)2041-210X/journal-resources/policy-on-publishing-code.html)) - (*Scope: Do consider MEE's [Aims and Scope](http://besjournals.onlinelibrary.wiley.com/hub/journal/10.1111/(ISSN)2041-210X/aims-and-scope/read-full-aims-and-scope.html) for your manuscript. We make no guarantee that your manuscript will be within MEE scope.*) - (*Although not required, we strongly recommend having a full manuscript prepared when you submit here.*) - (*Please do not submit your package separately to Methods in Ecology and Evolution*)

Code of conduct

[x] I agree to abide by rOpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

Briefly describe any working relationship you have (had) with the package authors.
[x] As the reviewer I confirm that there are no conflicts of interest for me to review this work (if you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

[x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
[x] Installation instructions: for the development version of package and any non-standard dependencies in README
[x] Vignette(s): demonstrating major functionality that runs successfully locally
[x] Function Documentation: for all exported functions
[x] Examples: (that run successfully locally) for all exported functions
[x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[x] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing: 30 minutes

[x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

Review Comments

Nice work! The project is well organized and the documentation is helpful and easy to understand. Here are my suggestions:

Since the package was built on the dplyr package and the ggplot2 package, they need to be referred to in the citation section in README.
Although the coverage of test cases has reached 100%, there are few edge cases.
Some simple examples can be added to the Usage part (not only the link) so that users don't need to read the entire doc to understand your package.
In the pkgdown.yaml and test-coverage.yaml, you only test ubuntu. It's necessary to test Window and macOS to ensure your package is compatible with other systems.
In the "How to use strapvizr" section 1.1, the function name in the title is bootstrap_distribution, but the actual name is bootstrap.

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

Briefly describe any working relationship you have (had) with the package authors.
[x] As the reviewer I confirm that there are no conflicts of interest for me to review this work (if you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

[x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
[x] Installation instructions: for the development version of package and any non-standard dependencies in README
[x] Vignette(s): demonstrating major functionality that runs successfully locally
[x] Function Documentation: for all exported functions
[x] Examples: (that run successfully locally) for all exported functions
[x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[x] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing: 1 hr

[x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

Review Comments

Great work with this package! The functionalities are extremely useful and I especially appreciate the package catering to DSCI 552. Below I have mentioned some points that you can improve on and make the package more user friendly:

In the Readme, it would nice to write information more in bullet points and highlight key things you would definitely want the users to take away. I am especially talking about the "Package context within the R ecosystem" section, I think it would make this section more clear if each bullet covers a specific point.
Following up on the "Package context within the R ecosystem" section, I feel there needs to be more elaboration on how the package is built on "dpylr" and "ggplot2" . Also it would be good to elaborate more on some of the boostrapping jargon, specifically this phrase is not necessarily easy to understand: "embedding in documents which is not available as a single bundle".
It is a bit hard to understand your source code and I would recommend that more comments be added to explain what some of the branches do and also to separate the branches with spaces. It would be nice to have a small phrase describing what exception handling you are doing. This is also the case in your test code, it would be good to explain what part the unit test is testing.
In your documentation under "How to use strapvizr", I appreciate the details provided in each example, however to make things more clear, it would be good to use more clear variable names as opposed to "boot_1" and "boot_2". Additionally, it would be good to have sentences comparing that the different boostraps and visualizations done.
I also noticed some small inconsistencies in your package, like for example your package is named "strapvizr" and this is how your users would install and import it, but sometimes in your Readme and documentation you instead say "StrapvizR". I think in general it would be good to stick with "strapvizr" making it less confusing.

All in all, great job! It very clear that a lot of thought and effort has been put into this package. It is very detailed and it would be interesting to see if this will be used by the next cohort in DSCI 552!

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

Briefly describe any working relationship you have (had) with the package authors.
[x] As the reviewer I confirm that there are no conflicts of interest for me to review this work (if you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

[x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
[x] Installation instructions: for the development version of package and any non-standard dependencies in README
[x] Vignette(s): demonstrating major functionality that runs successfully locally
[x] Function Documentation: for all exported functions
[x] Examples: (that run successfully locally) for all exported functions
[x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[x] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing: 1.25

[x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

Review Comments

I was pretty stoked to get to review this package! It is unique and well-suited for our purposes. A few things I notices:

bootstrap() function could perhaps be incorporated into calculate_boot_stats() function. Seems a little redundant, although I understand the value of having a simple bootstrap() function for instance if someone wants to just import that one
red line on the blue background on histogram is a little bit jarring, and purple dashed lines get a little lost. Perhaps could tweak the color scheme to be a little, or use of the existing pallets.
I would like a little more control over the plot in general, in particular renaming the X-axis, not just the Y-axis.
Documentation on this package is impeccable. Super easy to use, and each documentation when doing ?plot_ci, ?tabulate_stats, ?bootstrap and ?calculate_boot_stats looks beautiful and super easy to parse
LOVE the precision as a param in tabulate_stats()! That should be an option in any similar function.
Overall, easy installation, very accessibly documentation, smooth performance, nice job especially considering short time constraint. 📊🦋😻!

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

Briefly describe any working relationship you have (had) with the package authors.
[x] As the reviewer I confirm that there are no conflicts of interest for me to review this work (if you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

[x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
[x] Installation instructions: for the development version of package and any non-standard dependencies in README
[x] Vignette(s): demonstrating major functionality that runs successfully locally
[x] Function Documentation: for all exported functions
[ ] Examples: (that run successfully locally) for all exported functions
[x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[x] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing:

[x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

Review Comments

This project is very relevant to our work in Statistics, and I thoroughly enjoyed reviewing it. The repository is well structured and had clear instructions on how to install and use the functionality. All the functions are working as per the documentation and test cases cover a broad range of scenarios.

I do have a few comments for your consideration:

Documentation: While the functions individually give examples, it would be good to have a demo on the landing page itself. This can include toy data along with use case example for all functions.
Functionality: During bootstrapping, there is sometimes a need to get the samples without replacement. So, the function bootstrap_distribution() can have replacement as an optional argument. This will allow the user to specify if bootstrapping is to be done with or without replacement.
Unit tests: One test can be included for each function to validate that the type of output is as per the function documentation. This will ensure that the users do not get unexpected data types while using the package.
References: It would be good to include attribution/references to the packages, research papers or MDS material used for implementing this project.
Entity Names: There are subtle differences between the actual names of functions and package, and the names used in documentation. For example the name of function is bootstrap() where as it is mentioned as bootstrap_distribution() in ReadMe. Also, the package name appears as StrapvizR, strapvizr, StrapVizR etc. It would be good to maintain consistency across nomenclature.

Overall, I think that the work done is impressive in terms of functionality as well as documentation. I wish you the best as you develop it further.

UBC-MDS / software-review-2022