Submitting Author: Monique Wong (@moniquewong), Alistair Clark (@alistair-clark) , Miro Hu (@mirohu), Thomas Pin (@MrThomasPin) Repository: https://github.com/UBC-MDS/RDataPeek Version submitted: 1.1.1 Editor: @kvarada Reviewer 1: @cgostic Reviewer 2: @HanyingZhang Archive: TBD Version accepted: TBD

Package: RDataPeek
Title: Generates a Visual Summary of a Dataset
Version: 0.0.0.9000
Authors@R: 
    c(person(given = "Alistair",
           family = "Clark",
           role = c("aut", "cre", "ctb", "cph"),
           email = "alistair.jl.clark@gmail.com"),
       person(given = "Shangjing",
           family = "Hu",
           role = c("aut", "ctb", "cph")),
        person(given = "Thomas",
           family = "Pin",
           role = c("aut", "ctb", "cph")),
        person(given = "Monique",
           family = "Wong",
           role = c("aut", "ctb", "cph")))
Description: RDataPeek is a package that enables data scientists to efficiently generate a visual summary of a dataset. This package includes functions that show the size of the dataset, a visual summary of missing data, a sample of the dataset showing the data types as well as exploratory visualizations for quantitative and qualitative data.This package is also useful for business users who have to interact with data and want to begin exploring the data without using too much code or having to open a potentially large dataset on Excel. 
License: MIT + file LICENSE
Encoding: UTF-8
LazyData: true
Suggests: 
    testthat (>= 2.1.0),
    covr,
    knitr,
    rmarkdown
RoxygenNote: 7.0.2
Imports: 
    magrittr,
    tools,
    readxl,
    reshape2,
    readr,
    ggplot2,
    tm,
    wordcloud,
    dplyr
URL: https://github.com/UBC-MDS/RDataPeek
BugReports: https://github.com/UBC-MDS/RDataPeek/issues
VignetteBuilder: knitr

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
  - [x] data extraction
  - [ ] data munging
  - [ ] data deposition
  - [ ] workflow automataion
  - [ ] version control
  - [ ] citation management and bibliometrics
  - [ ] scientific software wrappers
  - [ ] database software bindings
  - [ ] geospatial data
  - [x] text analysis
Explain how and why the package falls under these categories (briefly, 1-2 sentences): The package extracts information from the data such as the missing values, column type, sample responses, unique value of each column and counts distribution of quantitative column through histograms. It generates a word bubble of qualitative responses (text).
Who is the target audience and what are scientific applications of this package? The package targets on people such as business userswho have to interact with data and want to begin exploring the data without using too much code or having to open a potentially large dataset on Excel.
Are there other R packages that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category? Several R packages and functions are available that support exploratory data analysis (e.g. Base R's summary(), R ggplot2 and R Word Cloud) but none are specific to the targeted use cases here - a simple and technologically friendly way of summarizing data.

Base R’s summary(): This function computes summary statistics for R dataframes. Our package differs in that it aims to offer summary statistics dependent on data type, including long form text data.
R ggplot2: Our package will leverage ggplot2 to create visualizations that summarize the dataset as well as user-defined features in the dataset. There are existing recommended visualizations for exploratory data analysis such as missing data visualizations which will be adapted where appropriate.
R Word Cloud: This package will also be used to create summary visualizations for long form text data. - If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted.

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. 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.
[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 automatically submit to the Journal of Open Source Software? If so:

JOSS Options

- [ ] The package has an **obvious research application** according to [JOSS's definition](https://joss.readthedocs.io/en/latest/submitting.html#submission-requirements). - [ ] The package contains a `paper.md` matching [JOSS's requirements](https://joss.readthedocs.io/en/latest/submitting.html#what-should-my-paper-contain) with a high-level description in the package root or in `inst/`. - [ ] The package is deposited in a long-term repository with the DOI: - (*Do not submit your package separately to JOSS*)

[ ] 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.

In Progress

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

[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
[ ] 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 in R help
[ ] Examples for all exported functions in R Help that run successfully locally
[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).

For packages co-submitting to JOSS

[ ] The package has an obvious research application according to JOSS's definition

The package contains a paper.md matching JOSS's requirements with:

[ ] A short summary describing the high-level functionality of the software

[ ] Authors: A list of authors with their affiliations

[ ] A statement of need clearly stating problems the software is designed to solve and its target audience.

[ ] References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

[ ] 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

Final approval (post-review)

[ ] The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

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

Functions

There's a @NoRd tag in the missing_data_overview() function! Update this to @export so it is callable after installing the package. I haven't run the provided example on this function.
The file-save location is set with dir in missing_data_overview() but not explore_w_histogram(). You might want to make this consistent across functions. It would clarify part of the feedback in Documentation below!
A "nice to have" would be including immediate output (i.e. create each image in the viewer panel, or print the df) of each function in addition to a saved file.

README

You note above that you do not plan to submit RDataPeek to CRAN, so I would consider removing the CRAN installation instructions from your README completely.
- The github installation instructions are also commented out in the README. This is nit-picky, but users appreciate when they can be lazy!
It would be useful to note any dependencies in your README near the installation instructions to help users troubleshoot if there are issue downloading the library. If you do not have any dependencies, (which would be awesome!) this is still useful to note!

Vignette

In your vignette, I'd suggest hiding your calls to knitr (using echo=FALSE) and just showing the files that are produced. Also, it'd be helpful if you could make it very clear that the result of your functions is a saved file at \<file location> named \<naming convention>.
To make the vignette more immediately accessible, you could add the "example.csv" as a link directly in the code! (i.e. csv_file <- https://raw.githubusercontent.com/UBC-MDS/RDataPeek/master/vignettes/example.csv and then call your functions on csv_file)

Documentation

I'd suggest updating your roxygen documentation to explain exactly what the return of each function is. Just by reading the docs, I'm not sure if I should expect an immediate output, a saved file, where the saved file will go, what it will be named, etc.
Consider adding an example or two for each function in the roxygen docstring. (Note that these need to be completely runnable, as check() will actually run them (i.e. inputs need to be defined and callable)! My group ran into some trouble here.)

Folder Structure

Consider relocating the test_movie_copy.csv file from the R folder to the test folder if it is being used in a test function.

Note that a left a few boxes unchecked above, and I think I addressed the reasoning for each within the comments above. If you're unsure about any unchecked box, feel free to shoot me a message!

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

[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 in R help
[ ] Examples for all exported functions in R Help that run successfully locally
[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).

For packages co-submitting to JOSS

[ ] The package has an obvious research application according to JOSS's definition

The package contains a paper.md matching JOSS's requirements with:

[ ] A short summary describing the high-level functionality of the software

[ ] Authors: A list of authors with their affiliations

[ ] A statement of need clearly stating problems the software is designed to solve and its target audience.

[ ] References: with DOIs for all those that have one (e.g. papers, datasets, software).

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

Final approval (post-review)

[ ] The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

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

Functionality

The functions are all well structured. And all run well for me. A little suggestion would be: I noticed that all the functions save the outputs to files. Would it be better to have another option to save outputs as returned objects for users who do not want to save them to files?

Readme

In the "Functions in this package" section, function names used are not exactly consistent with the actual function names in your package. I would suggest using consistent function names.
In the "Example" section, maybe you could show a little bit what your example.csv file looks like so the readers can better understand the subsequent examples. (you may also apply this to your vignette file)

Documentation

@examples sections are used in the functions' roxygen docstrings, but no example is given. Maybe consider adding some real examples. I left the "Examples" box in "Documentation" section unchecked because of this. (affected files: word_bubble.R, explore_w_histograms.R, missing_data_overview.R, sample_data.R)
@NoRd tags appear to be "unknown tag" when I run devtools::check() and .Rd files for these helper functions are still generated. Replacing @NoRd with @noRd might fix this problem. (affected files: word_bubble.R, explore_w_histograms.R, missing_data_overview.R, sample_data.R)

Other suggestions

There is a file called test_movie_copy.csv in the R folder that appears to be invalid. Maybe you could consider removing this file.
package_name-vignettee.Rmd and RDataPeek-vignette.Rmd in the vignettes folder seem to be redundant with no actual content. Maybe you could check the files again and drop the unnecessary ones.

Overall, the package seems to be very useful and practical to me. The helper functions make the main functions very well-structured and hard to break. I couldn't find any major issues. Great work! I am open to any discussion if you have any doubts on these comments.

Hello Hanying,

I have addressed some of your concerns they have been checked off:

Functionality "Would it be better to have another option to save outputs as returned objects for users who do not want to save them to files?"

Unforchanently some of our plots are base R plots which are unable to be saved as objects. Furthermore, we made the decision to let users download them for their business reports.

Readme

[x] "In the "Functions in this package" section, function names used are not exactly consistent with the actual function names in your package. I would suggest using consistent function names."
[x] "In the "Example" section, maybe you could show a little bit what your example.csv file looks like so the readers can better understand the subsequent examples. (you may also apply this to your vignette file)"

Documentation

[ ] "@examples sections are used in the functions' roxygen docstrings, but no example is given. Maybe consider adding some real examples. I left the "Examples" box in "Documentation" section unchecked because of this. (affected files: word_bubble.R, explore_w_histograms.R, missing_data_overview.R, sample_data.R)"
[x] "@NoRd tags appear to be "unknown tag" when I run devtools::check() and .Rd files for these helper functions are still generated. Replacing @NoRd with @noRd might fix this problem. (affected files: word_bubble.R, explore_w_histograms.R, missing_data_overview.R, sample_data.R)"

Other suggestions

[x] There is a file called test_movie_copy.csv in the R folder that appears to be invalid. Maybe you could consider removing this file.
[x] package_name-vignettee.Rmd and RDataPeek-vignette.Rmd in the vignettes folder seem to be redundant with no actual content. Maybe you could check the files again and drop the unnecessary ones.

Hello Cari,

I have addressed some of your concerns they have been checked off:

Functions

[x] There's a @NoRd tag in the missing_data_overview() function! Update this to @export so it is callable after installing the package. I haven't run the provided example on this function.
[x] The file-save location is set with dir in missing_data_overview() but not explore_w_histogram(). You might want to make this consistent across functions. It would clarify part of the feedback in Documentation below!
[ ] A "nice to have" would be including immediate output (i.e. create each image in the viewer panel, or print the df) of each function in addition to a saved file.

README

[x] You note above that you do not plan to submit RDataPeek to CRAN, so I would consider removing the CRAN installation instructions from your README completely.
[x] The github installation instructions are also commented out in the README. This is nit-picky, but users appreciate when they can be lazy!
[ ] It would be useful to note any dependencies in your README near the installation instructions to help users troubleshoot if there are issue downloading the library. If you do not have any dependencies, (which would be awesome!) this is still useful to note!

Vignette

[x] In your vignette, I'd suggest hiding your calls to knitr (using echo=FALSE) and just showing the files that are produced. Also, it'd be helpful if you could make it very clear that the result of your functions is a saved file at named .
[x] To make the vignette more immediately accessible, you could add the "example.csv" as a link directly in the code! (i.e. csv_file <- https://raw.githubusercontent.com/UBC-MDS/RDataPeek/master/vignettes/example.csv and then call your functions on csv_file) Documentation
[x] I'd suggest updating your roxygen documentation to explain exactly what the return of each function is. Just by reading the docs, I'm not sure if I should expect an immediate output, a saved file, where the saved file will go, what it will be named, etc.
[ ] Consider adding an example or two for each function in the roxygen docstring. (Note that these need to be completely runnable, as check() will actually run them (i.e. inputs need to be defined and callable)! My group ran into some trouble here.)

Folder Structure

[x] Consider relocating the test_movie_copy.csv file from the R folder to the test folder if it is being used in a test function.

UBC-MDS / software-review

Submission: RDataPeek (R) #2

Scope

Technical checks

Publication options

Code of conduct

In Progress

Package Review

Documentation

For packages co-submitting to JOSS

Functionality

Final approval (post-review)

Review Comments

Functions

README

Vignette

Documentation

Folder Structure

Package Review

Documentation

For packages co-submitting to JOSS

Functionality

Final approval (post-review)

Review Comments

Functionality

Readme

Documentation

Other suggestions