submission: qualtRics

[JasperHG90]

Summary

• What does this package do? (explain in 50 words or less):

This package focuses on the retrieval of survey data using the Qualtrics API and aims to reduce the pre-processing steps needed to prepare this data for analysis. It also supports the import of manual data exports and other metadata (survey flow, questions, number of responses etc.).

• Paste the full DESCRIPTION file inside a code block below:

Package: qualtRics
Type: Package
Title: Download Qualtrics Survey Data Directly into R
Version: 3.0
Author: Jasper Ginn
Maintainer: Jasper Ginn <jasperginn@gmail.com>
Description: Qualtrics <https://www.qualtrics.com/about/> 
    allows users to collect online data through surveys.
    This package contains convenience functions to pull
    survey results straight into R using the Qualtrics
    API. See <https://api.qualtrics.com/> for more 
    information about the Qualtrics API. This package is 
    community-maintained and is not officially supported 
    by Qualtrics.
Imports:
    httr,
    stringr,
    readr,
    jsonlite,
    assertthat,
    sjlabelled,
    lubridate,
    yaml,
    dplyr,
    rlang
URL:
    https://jasperhg90.github.io/qualtRics/
BugReports:
    https://github.com/JasperHG90/qualtRics/issues
License: GPL-3 | file LICENSE
Encoding: UTF-8
LazyData: true
RoxygenNote: 6.0.1
Suggests: 
    knitr,
    rmarkdown,
    httptest
VignetteBuilder: knitr

• URL for the package (the development repository, not a stylized html page):

https://github.com/JasperHG90/qualtRics

• Please indicate which category or categories from our package fit policies this package falls under *and why(? (e.g., data retrieval, reproducibility. If you are unsure, we suggest you make a pre-submission inquiry.):

I would categorise it under 'data retrieval', since the package allows users to retrieve data exports from Qualtrics and import this data directly into R.

•   Who is the target audience and what are scientific applications of this package?  

Target audience are analysts who use Qualtrics to design and disseminate surveys and who want straightforward access to their data using the API.

• Are there other R packages that accomplish the same thing? If so, how does
  yours differ or meet our criteria for best-in-category?

Not entirely. There are several packages that provide functionality to interact with the Qualtrics API, e.g.

• Jason Bryer wrote an R package to work with the previous version of the Qualtrics API
• QualtricsTools creates automatic reports in shiny.
• qsurvey by James Dunham focuses on testing and review of surveys before fielding, and analysis of responses afterward.

However, I'm not sure if these packages are still under active development. qualtRics focuses entirely on importing survey data and attempts to make this as simple as possible. Furthermore, it is the only package that uses survey metadata to automatically convert survey questions.

•   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.

No pre-submission, but I was contacted by one of your colleagues who invited me to submit the package. See here

Requirements

Confirm each of the following by checking the box. This package:

• does not violate the Terms of Service of any service it interacts with.
• has a CRAN and OSI accepted license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration, including reporting of test coverage, using services such as Travis CI, Coveralls and/or CodeCov.
• I agree to abide by ROpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

Publication options

• Do you intend for this package to go on CRAN?

Already on CRAN. See CRAN page

• Do you wish to automatically submit to the Journal of Open Source Software? If so:
  • The package has an obvious research application according to JOSS's definition.
  • The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
  • The package is deposited in a long-term repository with the DOI: 10.5281/zenodo.1165279
  • (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:
  • 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.
  • (Please do not submit your package separately to Methods in Ecology and Evolution)

Detail

• Does R CMD check (or devtools::check()) succeed? Paste and describe any errors or warnings:

No warnings / errors

• Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:

Yes with following notes:

1. Function names: these do not conform to the rOpenSci standards. I chose to keep them as is since this package has already been on CRAN for some time and changing the names of the functions would result in useless existing code for users.

2. News file: Until recently I used a Changelog.md file for news about changes. I'm now using rOpenSci headers for new releases, but have not done so for previous releases.

• If this is a resubmission following rejection, please explain the change in circumstances:

• If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:

[karthik]

Editor checks:

• Fit: The package meets criteria for fit and overlap
• Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• License: The package has a CRAN or OSI accepted license
• Repository: The repository link resolves correctly
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

Editor comments

We understand your desire to keep function names the same to avoid breaking code for current users. The exception is noted.

Thanks for switching to the rOpenSci headers. Below are the comments from goodpractice. Please address the relevant comments as I work towards finding reviewers. You can run goodpractice::gp() on your package anytime as you fix these issues.

── GP qualtRics ────────────────────────────────────────────────────────────────

It is good practice to

  ✖ write unit tests for all functions, and all package code
    in general. 55% of code lines are covered by test cases.

    R/getSurveyQuestions.R:52:NA
    R/getSurveyQuestions.R:54:NA
    R/getSurveyQuestions.R:56:NA
    R/getSurveyQuestions.R:57:NA
    R/getSurveyQuestions.R:58:NA
    ... and 262 more lines

  ✖ use '<-' for assignment instead of '='. '<-' is the
    standard, and R users and developers are used it and it is easier
    to read your code for them if you use '<-'.

    R/utils.R:106:11

  ✖ avoid long code lines, it is bad for readability. Also,
    many people prefer editor windows that are about 80 characters
    wide. Try make your lines shorter than 80 characters

    R/assertions.R:21:1
    R/assertions.R:27:1
    R/assertions.R:29:1
    R/assertions.R:30:1
    R/assertions.R:35:1
    ... and 83 more lines

  ✖ avoid calling setwd(), it changes the global environment.
    If you need it, consider using on.exit() to restore the working
    directory.

    tests/testthat/test-getSurvey_reads_stored_survey.R:7:3
    tests/testthat/test-registerOptions_reads_from_file.R:15:3

  ✖ avoid sapply(), it is not type safe. It might return a
    vector, or a list, depending on the input data. Consider using
    vapply() instead.

    R/getSurveyQuestions.R:54:20
    R/getSurveyQuestions.R:57:32
    R/getSurveyQuestions.R:58:34
    R/getSurveyQuestions.R:59:36
    R/getSurveyQuestions.R:65:21
    ... and 1 more lines

  ✖ avoid 1:length(...), 1:nrow(...), 1:ncol(...),
    1:NROW(...) and 1:NCOL(...) expressions. They are error prone and
    result 1:0 if the expression on the right hand side is zero. Use
    seq_len() or seq_along() instead.

    R/getSurveyQuestions.R:69:23
    R/utils.R:464:56

  ✖ fix this R CMD check NOTE: Namespace in Imports field not
    imported from: ‘lubridate’ All declared Imports should be used.
  ✖ fix this R CMD check WARNING: LaTeX errors when creating
    PDF version. This typically indicates Rd problems.
  ✖ fix this R CMD check ERROR: Re-running with no
    redirection of stdout/stderr. Hmm ... looks like a package You may
    want to clean up by 'rm -rf /tmp/RtmpTvxGKw/Rd2pdf7cb12ddc5dd3'
────────────────────────────────────────────────────────────────────────────────

---

Reviewer 1: @kierisi
Due date: Feb 25

Reviewer 2: @trinker
Due date: March 7

[JasperHG90]

Hi Karthik,

Thanks for your comments.

I fixed the following gp feedback:

• Replaced '=' with '<-'
• Changed 'sapply' to 'vapply'
• Changed all instances of '1:nrow' with 'seq_len()'
• Now using 'on.exit()' to restore working directory
• 'lubridate' removed from imports field

Partially fixed or left as is:

• '56% of code lines are covered by test cases.': 89% of lines are covered by test cases. Several tests are using 'skip_on_cran()'. See code coverage here
• 'avoid long code lines': The lines referred to here are error messages (strings). Only way I can think to break them up is to use 'paste()' but that seems like a silly solution. Suggestions welcome for better solution.
• 'avoid calling setwd()': 'setwd()' is called as part of a test to check core functionality of the package. Hence, it is necessary. I added 'on.exit()' as per the feedback. Suggestions welcome for better solution.
• 'R CMD check WARNING: LaTeX errors when creating PDF version': It isn't clear to me where this warning comes from. I checked the package using devtools and R CMD CHECK and get no errors/warnings/notes:

I've added the latest gp output below.

---

GP qualtRics

It is good practice to

✖ write unit tests for all functions, and all package code in general. 56% of code lines are covered by test cases.

R/getSurvey.R:127:NA
R/getSurvey.R:128:NA
R/getSurvey.R:129:NA
R/getSurvey.R:130:NA
R/getSurvey.R:131:NA
... and 258 more lines

✖ avoid long code lines, it is bad for readability. Also, many people prefer editor windows that are about 80 characters
wide. Try make your lines shorter than 80 characters

inst/doc/qualtRics.R:8:1
inst/doc/qualtRics.R:11:1
inst/doc/qualtRics.R:14:1
R/assertions.R:21:1
R/assertions.R:27:1
... and 85 more lines

✖ avoid calling setwd(), it changes the global environment. If you need it, consider using on.exit() to restore the
working directory.

tests/testthat/test-getSurvey_reads_stored_survey.R:8:3
tests/testthat/test-getSurvey_reads_stored_survey.R:9:11
tests/testthat/test-registerOptions_reads_from_file.R:17:3
tests/testthat/test-registerOptions_reads_from_file.R:18:11

✖ fix this R CMD check WARNING: LaTeX errors when creating PDF version. This typically indicates Rd problems. LaTeX
errors found: ! LaTeX Error: File `inconsolata.sty' not found. Type X to quit or to proceed, or enter new name.
(Default extension: sty) ! Emergency stop. <read *> l.276 ^^M ! ==> Fatal error occurred, no output PDF file produced!

---

[maelle]

Just a note regarding long lines that can only be long lines like error messages, you can add # nolint at the end of those lines https://github.com/jimhester/lintr#project-configuration this way lintr will not see them. Not te be abused of of course 👼

[JasperHG90]

Reviewed all lines and added # nolint where appropriate