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

[karthik]

Reviewer 2 is @trinker (due date: by March 7th)

[kierisi]

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

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

• 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
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• 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.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• 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.
• 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: 3

---

Review Comments

This package allows an R user to access Qualtrics survey data quickly and easily within R by using the Qualtrics API feature. As an avid Qualtrics user, I was pleasantly surprised with how quickly and seamlessly I was able to access survey data for analysis, because this is normally a tedious and time-consuming task. I tested the package using surveys of various:

• lengths
• survey flow complexity
• response numbers

Overall I encountered no difficulty in installing and using the package, even when testing complex surveys with high response rates.

As indicated above, a statement of need has not yet been provided by the package authors. From my perspective, this package addresses several major needs often encountered by analysts who use R to work with Qualtrics data. Speaking broadly, Qualtrics itself can be quite finnicky in how it handles survey response data outside of Qualtrics. The qualtRics package helps mitigate this through the following methods:

• circumvents character encoding errors that occur when downloading Qualtrics data and then bringing it into R.

• utilizes question labels as header names, thereby preventing unwieldy and poorly formatted column headers.

• seamlessly allows the user to analyze data from multiple related surveys. I often have to write two (or more) surveys that are linked together through embedded data and query strings, and this package makes accessing and joining the data significantly more straightforward.

• the automatic conversion of variables makes my heart happy, and I'm hopeful that this feature will eventually extend past single answer multiple choice questions.

Tests

Using devtools::test() had three failures, all with the following error message:

test-getSurveys.R:4: error: (unknown) could not find function "with_mock_api"

Documentation/vignette

The explanation on registering Qualtrics credentials and creating a configuration file are aces. Providing links on where to find the Qualtrics API token that lead to Qualtrics help documentation reinforces what Qualtrics should be providing support on vs. what the package authors can provide support on.

Help documentation and the vignette both provide good baseline information on the package and provide examples for the use of each function. I do recommend adding in line spacing to help improve the readability of the help documentation examples.

[trinker]

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

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

• 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
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• 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.
  • This was contained in the Summary section
• References: with DOIs for all those that have one (e.g. papers, datasets, software).
  • Exists but was empty

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• 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.
• 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: 4.5 hrs

---

Review Comments

Thanks for providing this interface to the R community. I was able to get up and running pretty quickly which is kudos considering I had never used Qualtrics and that the package is an API interface which can be tricky to have a smooth user interface. I have broken down additional comments into sub headings.

Functionality

The package was pretty intuitive and easy to use. There were a few cognitive sticking points as I worked through the Vignette, README, and Examples that are in the form of suggestions below:

1. Suggest a function for making a '.qualtRics.yml' in the working directory would be nice and add to the user experience. This may negate the need for images showing how to manually make this file.

Messages

Messages (messages, warnings, and errors) were detailed and had suggestions for what to do.

1. Suggested use of line breaks (i.e., '\n') for qualtRicsConfigFile's message. It currently is 419 characters wide, making it difficult to read. Same is true of the error message in getSurveys for bad url. This is true across many messages, warnings, and errors.

README/Vignette

Between the README and Vignette I was up and running quickly. The links to the Qualtrics page for the base_url and institution specific url were very helpful. I did find the following points that were a little challenging in getting set up:

1. The README doesn't state "Why is this package needed?" The README points to related work but doesn't compare or show the advantages of qualtRics. The advantage of this package is mentioned in 'paper.md' and in the ROpenSci submission but the later won't be accessible to users.
2. Numbering process steps as described in the README (e.g., under the Setting up a config file heading) and the Vignette would help the user know what to do an when. A video may be a nice addition as this package requires set up beyond writing code but the screen shots do a good job providing a visual view of the text describing the process.
3. When using the Vignette I noticed: the term root_url vs. Qualtrics' term base_url could be confusing. It's nice to be consistent when possible. In this case base_url seems to match what Qualtrics calls hostname (The /API doesn't seem to be required by qualtRics).
4. When using the Vignette I noticed: the root_url parameter for registerOptions or the '.qualtRics.yml' is not consistent with the Qualtrics description which ends the url with /API, using this format described by Qualtrics in the package causes an error. Perhaps (a) automatically stripping /API off in functions like getSurveys or (b) better description of this in the documentation would assist the user.

Examples

Examples ran as expected with correct parameters and tweaks (examples with a package like this are difficult to do out of the box because every user's experience will be different). Nice job with making as generic as possible. I did note the following difficulties and/or suggestions:

1. readSurvey example has readSurvey("<YOUR-PATH-TO-CSV-FILE>"). A minimal .csv file could easily be included in the inst file and accessed via system.file. This would make the examples more reproducible.
2. metadata examples uses a slightly different format (and more difficult to follow) for giving surveyId (it uses id which is a variable that doesn't exist) while other function examples use surveyId = surveys$id[6] (or simular) which connects to the prior step in the example and easy to follow.

CRAN Specifications

This appeared to pass CRAN checks. It does violate the following requirements in the Writing R Ext.:

1. Function titles are lower cased in .Rd files (and roxygen). CRAN Ext. states "Title information for the Rd file. This should be capitalized and not end in a period..."

ROpenSci Packaging Guidelines

The package generally complies with ROpenSci's Packaging Guidelines (https://github.com/ropensci/onboarding/blob/master/packaging_guide.md). Code contains many comments for ease of understanding. There is little if any code duplication. I did note:

1. Snake case is not used
2. Mix of snake and camel case in the arguments to getSurvey
3. Inconsistent function naming convention where some lead with a verb while others do not. Consistency here will allow users to recall function names easier. That being said the package is already on CRAN, slow deprecation required.
4. The ROpenSci Guidelines suggest Hadely's code styling: http://r-pkgs.had.co.nz/r.html. The Spacing under http://r-pkgs.had.co.nz/r.html#style is violated in some examples such as ?getSurvey we see api_token="<YOUR-API-TOKEN>", root_url="<YOUR-ROOT-URL>") and verbose=TRUE
5. Code in some .R files could benefit from vertical spacing as well to make it more readable. For example, in 'R/assertions.R' file we see that at lines 55-56 there are 2 functions that have no space between. Often multiple nested functions are on one or two lines. Breaking up these lines and adding indenting would improve readability.

Tests

Testing things that are secret (like API keys) is difficult. This package runs as many tests as possible. I did note:

1. devtools::test had three failures: could not find function "with_mock_api" If I load library(httptest) it works. This may just be ignorance on my part on usage. Travis-CI seems to know how to handle this so it's likely me.

[JasperHG90]

Thanks for the reviews! I expect to start incorporating your feedback at the end of the week, as I'm currently wrapping up a project for a client.

[karthik]

Thanks @JasperHG90! Looking forward to your revisions.

[JasperHG90]

Started working on revisions. Expect to finish by Friday 23 March at latest.

[JasperHG90]

Hello all,

Thank you for your reviews. They were very useful. I've addressed most of them in the code (see the development branch), and have placed several comments/questions at the bottom of this post.

Updates

• Statement of need: added to the README file.
• Root url v. base url: Deprecation warning added for root_url, and changed to base_url across code, examples, vignette and README. Internally, the package still uses root_url, but this will be changed to base_url later. Added examples of what the base url passed to qualtRics package should look like to README and vignette.
• Legibility and style: Added additional vertical spaces in README around code blocks and in code to improve legibility. Core functions are now split up in sections.
• Code examples for functions: Updated examples to conform to Hadley's style guide. Added lines for metadata() function and added examples for readSurvey() function.
• Warnings/errors: Added newlines in errors.
• Config file: Added numbering in README and vignette.
• Snake case/Camel case mix in getSurvey(): Deprecated arguments that use snake case in favour of arguments that use camel case.

Questions/comments

• Snake case: as mentioned in the submission, the package is already on CRAN and I will deprecate functions for snake case in a future update. Aim to use rOpenSci's guidelines for deprecation of these functions and replace them with e.g. 'qualtrics_get_survey()' etc. Should be done by version 4.0.
• Deprecation of manual setup configuration file: Like the ideo of a video. Will keep this in mind for next update. Plan to re-write this s.t. order is (.RProfile --> .qualtRics.yml --> passed by user to function).
• CRAN policies:: I don't understand this comment:

Function titles are lower cased in .Rd files (and roxygen). CRAN Ext. states "Title information for the Rd file. This should be capitalized and not end in a period..."

Could you provide a link/example?

• Failed tests: httptest package is suggested so that could be the reason that some tests fail. Would it be good to move this to 'imports' field?

[trinker]

@JasperHG90 Sorry for the lack of clarity on the lower cased titles:

CRAN policies:: I don't understand this comment:

What I mean is that cran states:

Function titles are lower cased in .Rd files (and roxygen). CRAN Ext. states "Title information for the Rd file. This should be capitalized and not end in a period..."

If you go to one of your files: https://github.com/JasperHG90/qualtRics/blob/master/R/getSurvey.R

We see:

#' Export a survey and download into R

at line 17. This should not be lower cased but in title case:

#' Export a Survey and Download into R

This will then transfer to the .Rd files when you roxygenize.

My thinking on the failed test is that it only fails for devtools::test and since it works on Travis-CI and when I run a CRAN check I'd say this can be ignored. I wouldn't move httptest to Imports unless you're actually importing it. I'd appreciate others to weigh in here.

[JasperHG90]

Thanks for your comments @trinker . I edited the titles.

[karthik]

@kierisi Hi Jesse! 👋 Could you please take a look at @JasperHG90's recent changes and see if you are able to check off a statement of need issue? And please let us know if the fixes and updates are ok by you for a sign off. 🙏

[kierisi]

clicked and on-board for a sign off 🚀

[karthik]

@trinker Do you have other concerns that remain unaddressed or are you happy to sign off as well?

[trinker]

@karthik happy to sign off as well

[karthik]

Approved! 🎉 Thank you for submitting and @kierisi and @trinker for thorough and timely reviews! 🙏

@JasperHG90

To-dos:

• Transfer the repo to the rOpenSci organization under "Settings" in your repo. I have invited you to a team that should allow you to do so. You'll be made admin once you do.

• Add the rOpenSci footer to the bottom of your README

[![ropensci_footer](https://ropensci.org/public_images/ropensci_footer.png)](https://ropensci.org)

• Fix any links in badges for CI and coverage to point to the ropensci URL. (We'll turn on the services on our end as needed)

Welcome aboard! We'd also love a blog post about your package, either a short-form intro to it (https://ropensci.org/tech-notes/) or long-form post with more narrative about its development. ((https://ropensci.org/blog/). If you are, @stefaniebutland will be in touch about content and timing.

[JasperHG90]

To-dos:

• Transfer the repo to the rOpenSci organization under "Settings" in your repo. I have invited you to a team that should allow you to do so. You'll be made admin once you do.

• Add the rOpenSci footer to the bottom of your README

• Fix any links in badges for CI and coverage to point to the ropensci URL. (We'll turn on the services on our end as needed)

[JasperHG90]

Happy to write a technical note!

[stefaniebutland]

@JasperHG90 Great to hear that you'd like to publish a technote on this. We can publish at any time (in contrast to blog posts that are scheduled). Please submit a draft by pull request at your convenience and we can review before publishing.

Here are examples: https://ropensci.org/technotes/

Instructions on pull request and preview: https://github.com/ropensci/roweb2#contributing-a-blog-post. The only difference in YAML for technote is
categories:

• technotes

I will add the topicid before publishing.

Don't hesitate to ask any questions here.

[JasperHG90]

Hi Stefanie. Thanks for the information!

[karthik]

@JasperHG90 One quick question. Would you be interested in adding @kierisi and @trinker as reviewers in your description file? Read more about why here

Also would be good to see if they're both comfortable with the idea.

e.g. https://github.com/ropensci/rdflib/blob/master/DESCRIPTION#L8-L10

[kierisi]

fine by me!

[JasperHG90]

What a neat feature! If @kierisi and @trinker are OK, i’d Like to add them as reviewers. Please leave information in a comment so I can add!

…

On Wed, 11 Apr 2018 at 19:31, Karthik Ram ***@***.***> wrote: @JasperHG90 <https://github.com/JasperHG90> One quick question. Would you be interested in adding @kierisi <https://github.com/kierisi> and @trinker <https://github.com/trinker> are reviewers in your description file? Read more about why here <https://ropensci.org/blog/2018/03/16/thanking-reviewers-in-metadata/> Also would be good to see if they're both comfortable with the idea. e.g. https://github.com/ropensci/rdflib/blob/master/DESCRIPTION#L9-L11 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHtJuw8OnBE_Trr4GLu2q0Au5dlyneVzks5tnj3TgaJpZM4R4hH5> .

[karthik]

@kierisi @trinker If you don't already have an ORCID, sign up for one here: https://orcid.org/

[kierisi]

here you go: 0000-0003-1915-9612

[trinker]

0000-0002-4299-7692

[JasperHG90]

@karthik had one more question: could you explain to me how the JOSS process works? Is the accompanying paper automatically submitted or do I need to do something? Thanks!

[karthik]

@JasperHG90 Sure. Just follow the submission instructions for JOSS (http://joss.theoj.org/papers/new) and submit a paper there. You'll need to write the paper of course, and include some high level references in a .bib file, then commit both to this same repo.

Then tag me as editor. I'll do a quick review of the paper itself and make sure it reads well. Once that's cleared, you will have to archive a copy of your repo in Zenodo (zenodo.org) and share the DOI. After that the EIC and I can finish the final steps for acceptance.

[karthik]

@JasperHG90 I'm going to close this issue here but feel free to ping me over email (see my profile) for help with the JOSS part. 🙏

[karthik]

Paper is now published on JOSS! 🎉 http://joss.theoj.org/papers/10.21105/joss.00690

[stefaniebutland]

@JasperHG90 Are you still interested/ willing to write a tech note about qualtRics? I think it would really be of interest and would be great to bring some attention to the package

[JasperHG90]

Hi Stefanie,

Thanks for your message. I'd be happy to do this but I am currently involved in a couple of projects that are taking up all of my time. Things should ease up around half August. I'll put this on the to-do list for around that time!

Best,

Jasper.

[stefaniebutland]

I'll ping you here in late August then @JasperHG90 so we can come up with a tentative date for a draft.
Cheers

[stefaniebutland]

@JasperHG90 Hoping your projects load allows you some breathing room soon.
I have blog post publication dates available Sept 18, Oct 2, 9, 16. If you're still interested, let me know your preferred date and mark your calendar to submit a draft a week in advance. Goal is to get more eyes on your work, but I know this is extra work beyond the review process. No worries if you're reluctant to spend the extra time.

[stefaniebutland]

Hi @JasperHG90. One last ping to ask if you want to write a qualtRics post.