tidytags: Simple Collection and Powerful Analysis of Twitter Data

[bretsw]

Date accepted: 2022-01-31
Submitting Author Name: Bret Staudt Willet
Submitting Author Github Handle: @bretsw
Other Package Authors Github handles: (comma separated, delete if none) @jrosen48
Repository: https://github.com/bretsw/tidytags
Version submitted: 0.1.0
Submission type: Standard
Editor: @maelle
Reviewers: @llrs, @marionlouveaux

Due date for @llrs: 2021-04-19 Due date for @marionlouveaux: 2021-04-27

Archive: TBD
Version accepted: TBD

---

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

Package: tidytags
Version: 0.1.0
Title: Simple Collection and Powerful Analysis of Twitter Data
Authors@R: c(
    person("K. Bret", "Staudt Willet", , 
      email = "bret@bretsw.com", role = c("aut", "cre"),
      comment = c(ORCID = "0000-0002-6984-416X")
    ),
    person("Joshua M.", "Rosenberg", ,
      role = c("aut"),
      comment = c(ORCID = "0000-0003-2170-0447")
    )
  )
Description: {tidytags} coordinates the simplicity of collecting tweets over time 
    with a [Twitter Archiving Google Sheet](https://tags.hawksey.info/) (TAGS) and the utility of the 
    [{rtweet} package](https://rtweet.info/) for processing and preparing additional Twitter metadata. 
    {tidytags} also introduces functions developed to facilitate systematic yet 
    flexible analyses of data from Twitter.
License: GPL-3
URL: https://bretsw.github.io/tidytags/, https://github.com/bretsw/tidytags
Depends: 
    R (>= 4.0)
Imports:
    dplyr (>= 0.8),
    googlesheets4 (>= 0.2),
    purrr (>= 0.3),
    readr (>= 1.3),
    rlang(>= 0.4),
    rtweet (>= 0.7),
    stringr (>= 1.4),
    tibble (>= 3.0), 
    tidyr (>= 1.0),
    tidyselect (>= 1.0)
Suggests:
    beepr,
    covr,
    ggplot2,
    knitr,
    longurl,
    mapsapi,
    mapview,
    rmarkdown,
    testthat,
    tidyverse,
    urltools,
    usethis
Encoding: UTF-8
VignetteBuilder: knitr
LazyData: TRUE
RoxygenNote: 7.1.0

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 automataion
  • version control
  • citation management and bibliometrics
  • scientific software wrappers
  • 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):

{tidytags} allows for both simple data collection and thorough data analysis. In short, {tidytags} first uses a Twitter Archiving Google Sheet (TAGS) to easily collect tweet ID numbers and then uses the R package {rtweet} to re-query the Twitter API to collect additional metadata. {tidytags} also introduces new functions developed to facilitate systematic yet flexible analyses of data from Twitter.

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

The target users for {tidytags} are social scientists (e.g., educational researchers) who have an interest in studying Twitter data but are relatively new to R, data science, or social network analysis. {tidytags} scaffolds tweet collection and analysis through a simple workflow that still allows for robust analyses.

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

{tidytags} wraps together functionality from several useful R packages, including {googlesheets4} to bring data from the TAGS tracker into R and {rtweet} for retrieving additional tweet metadata. The contribution of {tidytags} is to bring together the affordance of TAGS to easily collect tweets over time (which is not straightforward with {rtweet}) and the utility of {rtweet} for collecting additional data (which are missing from TAGS). Finally, {tidytags} reshapes data in preparation for geolocation and social network analyses that should be accessible to relatively new R users.

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

• I have read the guide for authors and rOpenSci packaging guide.

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, created with roxygen2.
• 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.

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.
  • 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:
  • (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)
• (Scope: Do consider MEE's Aims and Scope 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

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

[annakrystalli]

Hello @bretsw and many thanks for your submission! We have discussed the package and have deemed it to be in scope.

@geanders will you be your handling editor 🙂

[bretsw]

Thank you, @annakrystalli! And thank you in advance, @geanders, for working with us. We are looking forward to your feedback.

[bretsw]

Hi @geanders, thank you so much for considering {tidytags} for review. @jrosen48 and I were just thinking about this and thought to reach out to inquire about the status of the review. We recognize that this is likely to be a very busy and hectic time and so understand if the answer is simply that it's 'in-process'. But would you be able to let us know? Thanks again for considering this. //Bret

[maelle]

👋 @bretsw, some first remarks from me (another editor).

• I am generally wondering how the reviewers can test the package. For instance is the TAGS used in the vignette usable by anyone? I see the vignette chunks aren't evaluated, why is it so? Not that I have anything against pre-compiling vignettes in such a case!

• Could you add documentation on data protection? See https://devguide.ropensci.org/policies.html#ethics-data-privacy-and-human-subjects-research I saw a related open issue in your repo.

• In the pkgdown reference page, it would make sense to group functions.

• The README content could be partly re-used as a Get Started vignette (just name a vignette tidytags.Rmd). How to re-use chunks.

• Relatedly, although the README structure is clear, I'd appreciate a setup checklist to provide an overview. Or maybe a setup vignette like the rtweet vignette about secrets.

* Have a TAGS with blablabla ready (blablabla being the public URL)
* Setup rtweet credentials if you want to use blablabla
* Setup Google geocoding credentials if you want to use blablabla

• In the TAGS setup explanation maybe some screenshots would make sense. I say maybe as a) they easily go stale b) your text seems quite clear (not tested yet) and a screenshot wouldn't replace instructions.

• Regarding tests am I correct that they're skipped everywhere but locally? Is it both because you are using authentication & Twitter data you don't own/can't share? I am actually working on the "HTTP testing in R" book so I'd recommend choosing an approach with some sort of fake data. I can help more once I know more about your constraints.

[bretsw]

@maelle, thank you for this initial feedback. @jrosen48 and I chatted today and divided up tasks. We're aiming to get back to you on these things by the end of next week (10/23).

[maelle]

Thanks for the update! 👍 Don't hesitate to ask any question here.

[bretsw]

@maelle, thank you again for your feedback! Below are responses from @jrosen48 and I, and we have pushed all changes to the repo: https://github.com/bretsw/tidytags

We're looking forward to more dialogue on this!
//Bret

1. I am generally wondering how the reviewers can test the package. For instance is the TAGS used in the vignette usable by anyone? I see the vignette chunks aren't evaluated, why is it so? Not that I have anything against pre-compiling vignettes in such a case!

Our response: The example vignette is usable by anyone. We’ve just set the chunks as eval=FALSE because many of the processes are slow, even when limiting the examples to small data. But all the code should work and anyone can view/pull data from the TAGS tracker linked to in the vignette.

2. Could you add documentation on data protection? See https://devguide.ropensci.org/policies.html#ethics-data-privacy-and-human-subjects-research I saw a related open issue in your repo.

Our response: We added several paragraphs to a new “Considerations Related to Ethics, Data Privacy, and Human Subjects Research” in the README.
Regarding the open issue in the repo (Issue #2), we are considering this enhancement for a future version of {tidytags}.

3. In the pkgdown reference page, it would make sense to group functions.

Our response: We have grouped the functions. See https://bretsw.github.io/tidytags/reference/index.html

4. The README content could be partly re-used as a Get Started vignette (just name a vignette tidytags.Rmd). How to re-use chunks.

Our response: We have created a “Getting started with tidytags” vignette (https://bretsw.github.io/tidytags/articles/setup.html).

5. Relatedly, although the README structure is clear, I'd appreciate a setup checklist to provide an overview. Or maybe a setup vignette like the rtweet vignette about secrets.

Our response: We have added duplicate checklists in both the README and in the new “Getting started with tidytags” vignette.

6. In the TAGS setup explanation maybe some screenshots would make sense. I say maybe as a) they easily go stale b) your text seems quite clear (not tested yet) and a screenshot wouldn't replace instructions.

Our response: We have added screenshots to the “Getting started with tidytags” vignette.

7. Regarding tests am I correct that they're skipped everywhere but locally? Is it both because you are using authentication & Twitter data you don't own/can't share? I am actually working on the "HTTP testing in R" book so I'd recommend choosing an approach with some sort of fake data. I can help more once I know more about your constraints.

Our response: We have set up tests for many of the functions, often using fake data. The functions that we cannot test for CRAN/Travis (i.e., we can only test locally) are those that are querying either the Twitter or Google Maps API. For example, add_users_data() uses a Twitter API key, so we cannot test all aspects of it for CRAN or Travis.

[maelle]

Thanks a lot to both of you, awesome work! I have a few comments already

• I think it'd be good to have a process in place for re-computing the vignette. See for instance https://ropensci.org/technotes/2019/12/08/precompute-vignettes/

• Regarding the ethics section of the README, it's very thoughtful! I'd prefer it to be in one of the vignettes too, because users don't usually access the README locally. We can hope they'll read the pkgdown website instead of the local docs, but who knows. Therefore if it were me I'd make the ethics guidance a re-usable chunk. https://www.garrickadenbuie.com/blog/dry-vignette-and-readme/

• To make the editors checks I'd need a contributing guide, which reviewers will need too. E.g. I have no TAGS so do I create one (if so how) or is there one developers (and editors/reviewers) of the package can access as a sort of sandbox? (much easier if it's technically feasible)
  Examples

  • https://docs.ropensci.org/osfr/CONTRIBUTING.html
  • https://docs.ropensci.org/ruODK/CONTRIBUTING.html
    Once I know more, I'll give more precise suggestions of how to add tests for the API stuff. We require a test coverage of 75% before review and I'll help you get there as smoothly as possible!

Now I'll go create my credentials, that part I can already follow.

[maelle]

PS: I like the phrasing "Pain Point" 😂

[maelle]

Is there no free tier for Google geocoding? If so then my opencage suggestion is becoming more important. 🤔

[maelle]

well i guess the free credits one gets when creating the billing account count as free tier maybe 🤔

[maelle]

A small note, in the rtweet docs for creating a token at the very end there is a step allowing you to check your token is available in a new session.
What could a similar check be for the Google Geocoding API?

And even more ambitious and not necessary would be a sitrep function for tidytags, that you'd run to check Twitter and Google geocoding are now set up, and if not pointers to relevant docs. (à la devtools::dev_sitrep())

[maelle]

Last question before I log off, could the docs state what kind of restrictions can be applied to the Google geocoding API key for tidytags stuff to work?

[maelle]

👋 @bretsw @jrosen48! Any update? (Acknowledging this is not an easy year/week)

[bretsw]

Hi @maelle! Thank you so much for checking in. I apologize for our delay. This week has been my big annual conference (AECT), and last week I was getting things ready, so I've been sidetracked. I give my last presentation tomorrow, so I'll respond to your comments and suggestions here next week. Thanks for bearing with us!

[maelle]

No problem, thanks for the update and good luck with your presentation 🎤 🙂

[maelle]

👋 @bretsw @jrosen48! Have you had time to look at this again? Thank you!

[bretsw]

Hi @maelle, thank you again for your patience, and your helpful comments and suggestions. We have quite a few updates for your review. We list our response to your comment here:

1. I think it'd be good to have a process in place for pre-computing the vignette. See for instance https://ropensci.org/technotes/2019/12/08/precompute-vignettes/

• Our response: I have added the file tidytags-with-conf-hashtags.Rmd.orig for precomputing this vignette (which requires both Twitter API and OpenCage API keys, and takes a long time to compute). I also added the precompile.R file for a quick script for refreshing this vignette in the future.

2. Regarding the ethics section of the README, it's very thoughtful! I'd prefer it to be in one of the vignettes too, because users don't usually access the README locally. We can hope they'll read the pkgdown website instead of the local docs, but who knows. Therefore if it were me I'd make the ethics guidance a re-usable chunk. https://www.garrickadenbuie.com/blog/dry-vignette-and-readme/

• Our response: We have added the reusable fragment “ethics.Rmd” to both the README (where it was already) and the “tidytags-with-conf-hashtags.Rmd” vignette. We also created the reusable fragment “getting-help.Rmd” for both the README and the “setup.Rmd” vignette.

3. To make the editors checks I'd need a contributing guide, which reviewers will need too. E.g. I have no TAGS so do I create one (if so how) or is there one developers (and editors/reviewers) of the package can access as a sort of sandbox? (much easier if it's technically feasible). Examples: https://docs.ropensci.org/osfr/CONTRIBUTING.html, https://docs.ropensci.org/ruODK/CONTRIBUTING.html. Once I know more, I'll give more precise suggestions of how to add tests for the API stuff. We require a test coverage of 75% before review and I'll help you get there as smoothly as possible!

-Our response: We have added CODE_OF_CONDUCT.md and CONTRIBUTING.md

4. Outside of my role as editor, let me introduce you to opencage, where a lot of work by @dpprdan is happening in the dev branch these days. Not sure you even need an alternative to Google maps. 😉 Two advantages: 1. no "billing account" for free accounts. 2. use of open data so you're allowed to keep it. Is there no free tier for Google geocoding? If so then my opencage suggestion is becoming more important. 🤔 Well i guess the free credits one gets when creating the billing account count as free tier maybe 🤔 #: https://opencagedata.com/#

• Our response: I have switched geocode_tags() to draw from OpenCage API instead of Google Maps API. The geocode_tags() documentation has been updated, and the setup.Rmd and tidytags-with-conf-hashtags.Rmd vignettes have been adjusted as well.

5. A small note, in the rtweet docs for creating a token at the very end there is a step allowing you to check your token is available in a new session. What could a similar check be for the Google Geocoding API? And even more ambitious and not necessary would be a sitrep function for tidytags, that you'd run to check Twitter and Google geocoding are now set up, and if not pointers to relevant docs. (à la devtools::dev_sitrep())

• Our response: Following the {rtweet} model, I have added a “Authorization in future R sessions” section to the setup.Rmd vignette for both the Twitter API key and the OpenCage API key.

6. Last question before I log off, could the docs state what kind of restrictions can be applied to the Google geocoding API key for tidytags stuff to work?

• Our response: I have added a paragraph in the setup.Rmd vignette that compares the price points between Google Maps API and OpenCage API. I conclude with “OpenCage does seem to be a bit flexible if the 2,500 queries per day are exceeded. However, if you greatly exceed this limit, they send a warning and ask you to upgrade to a paid plan.”

Outstanding issues:

• I followed some examples for our Contributing Guide, but I don’t know if what I’ve written is sufficient.
• I would love further guidance on increasing our test coverage, which is way below 75%.

Thank you again for working with us! @jrosen48 and I are looking forward to continuing to develop {tidytags}.

//Bret

[maelle]

Thanks a ton for all your work!

• Regarding the code of conduct, awesome! Note that after acceptance the rOpenSci COC will apply cf https://devguide.ropensci.org/collaboration.html#coc-file

• I am glad about OpenCage, not only because it's a nice package 😁 but also because setup is so much easier.

• Speaking of setup docs, they are really good!

• Now regarding the contributing guide what's missing is a sandbox TAGS like OSF's development environment/ODK sandbox. Could reviewers (and the editor?) get access to a TAGS used for testing the package? (even if ideally once I start looking for reviewers I hope to find TAGS users who'd use the package on their own data)

• Speaking of testing. You will want both tests that use cached responses of some sort, and tests making real requests at least once in a while.

  • The rOpenSci "HTTP testing in R" book is undergoing a major update (by me 🙂 ) in particular I've worked on demos of the three tools for HTTP testing there are in R. See Whole games ropensci-books/http-testing#47 and the Netlify preview linked from the PR checks https://5fbb93389e79d3867339005d--http-testing-book.netlify.app/ (the Whole games section is the one with the demos)
  • Regarding tests with real requests especially on CI the best guidance out there is https://gargle.r-lib.org/articles/articles/managing-tokens-securely.html
  • If I get access to a sandbox TAGS I can help with setting up tests, e.g. making a PR adding a first vcr test if that helps.

[bretsw]

Hi @maelle! I've added an openly shared TAGS tracker to the CONTRIBUTING guide. See https://github.com/bretsw/tidytags/blob/master/CONTRIBUTING.md#prerequisites

I mention this in the guide, but the TAGS itself is read-only in the web, because the purpose of {tidytags} is to read the tracker archive into R and let you do all your analyses there.

I'll look more at the testing examples you've listed (THANK YOU!), but I wanted to quickly get you the TAGS sandbox first.

[maelle]

👋 @bretsw! Sorry for the delay, thanks, having the TAGS tracker is awesome.

I've merged my PR to the HTTP testing in R book and added some advanced chapters. https://books.ropensci.org/http-testing/index.html

Do you have any specific questions regarding test setup, that I could look into?

Speaking of testthat, with testthat newest version context() is deprecated, what's used as context instead is the name of the test file (that hopefully reflects the name of the R file).

Also note that you don't need to load tidytags manually (library(tidytags)) in tests as it's loaded by testthat.

[maelle]

reg testthat's new version https://testthat.r-lib.org/articles/third-edition.html

[bretsw]

Hi @maelle! Thanks again for pointing me in all the right directions. I think I've gotten vcr tests working with Twitter and OpenCage APIs. At least it looks good on my local machine. I just pushed a big update so we'll see. When I ran covr::package_coverage() locally it looked like the tests are covering around 85% now. I've gotten tests for all functions, in any case.

It does look like R-CMD-check is failing on Github though.

One place where I got stuck and couldn't find my way through was on a vcr test for get_url_domain(). The vcr test worked with long URLS but not shortened ones (e.g., bit.ly). Seems like there's something going on in a dependency package that I'm not catching yet. Anyway, set those test to skip() for now.

Let me know what's next! THANK YOU, as always, for all your help.

[maelle]

Awesome, I'm going to have a look!

I see that the README links to an older version of the R packages book reg licencing. Here's the updated chapter https://r-pkgs.org/license.html

[bretsw]

I've removed the .DS_Store files (and added this to .gitignore).
I've fixed the lines longer than 80 characters.
I've added the 'codemeta.json' file.

Should be ready for @ropensci-review-bot check package again.

[mpadge]

@ropensci-review-bot check package

[ropensci-review-bot]

Thanks, about to send the query.

[ropensci-review-bot]

Error (500). The editorcheck service is currently unavailable

[ropensci-review-bot]

Checks for tidytags (v0.2.1)

git hash: 943a3522

• ✔️ Package name is available
• ✔️ has a 'CITATION' file.
• ✔️ has a 'codemeta.json' file.
• ✔️ has a 'contributing' file.
• ✔️ uses 'roxygen2'.
• ✔️ 'DESCRIPTION' has a URL field.
• ✔️ 'DESCRIPTION' has a BugReports field.
• ✔️ Package has at least one HTML vignette
• ✔️ All functions have examples.
• ✔️ Package has continuous integration checks.
• ✔️ Package coverage is 88.8%.
• ✔️ R CMD check found no errors.
• ✔️ R CMD check found no warnings.

Package License: MIT + file LICENSE

---

1. Statistical Properties

This package features some noteworthy statistical properties which may need to be clarified by a handling editor prior to progressing.

Details of statistical properties (click to open)

The package has:

• code in R (100% in 6 files) and
• 2 authors
• 2 vignettes
• no internal data file
• 8 imported packages
• 12 exported functions (median 17 lines of code)
• 16 non-exported functions in R (median 20 lines of code)

---

Statistical properties of package structure as distributional percentiles in relation to all current CRAN packages
The following terminology is used:

• loc = "Lines of Code"
• fn = "function"
• exp/not_exp = exported / not exported

The final measure (fn_call_network_size) is the total number of calls between functions (in R), or more abstract relationships between code objects in other languages. Values are flagged as "noteworthy" when they lie in the upper or lower 5th percentile.

measure	value	percentile	noteworthy
files_R	6	40.3
files_vignettes	2	85.7
files_tests	28	97.7
loc_R	323	34.5
loc_vignettes	280	61.3
loc_tests	1054848	100.0	TRUE
num_vignettes	2	89.2
n_fns_r	28	38.0
n_fns_r_exported	12	51.3
n_fns_r_not_exported	16	34.3
n_fns_per_file_r	2	41.9
num_params_per_fn	2	11.9
loc_per_fn_r	18	54.7
loc_per_fn_r_exp	18	42.0
loc_per_fn_r_not_exp	20	63.0
rel_whitespace_R	14	32.6
rel_whitespace_vignettes	71	84.3
rel_whitespace_tests	0	69.2
doclines_per_fn_exp	32	38.2
doclines_per_fn_not_exp	0	0.0	TRUE
fn_call_network_size	18	44.2

---

1a. Network visualisation

Click to see the interactive network visualisation of calls between objects in package

---

2. goodpractice and other checks

Details of goodpractice and other checks (click to open)

3a. Continuous Integration Badges

![https://github](https://github.com/ropensci/software-review/issues/382"><img src="https://img.shields.io/github/last-commit/bretsw/tidytags.svg)

GitHub Workflow Results

name	conclusion	sha	date
pages build and deployment	success	943a35	2021-12-21
R-CMD-check	success	943a35	2021-12-21
test-coverage	success	943a35	2021-12-21
with-real-requests	success	943a35	2021-12-22

---

3b. goodpractice results

R CMD check with rcmdcheck

rcmdcheck found no errors, warnings, or notes

Test coverage with covr

Package coverage: 88.81

Cyclocomplexity with cyclocomp

No functions have cyclocomplexity >= 15

Static code analyses with lintr

lintr found no issues with this package!

---

Package Versions

package	version
pkgstats	0.0.3.59
pkgcheck	0.0.2.203

---

Editor-in-Chief Instructions:

This package is in top shape and may be passed on to a handling editor

[llrs]

I'm testing it now with R 4.1.2

• 1.1
  There a missing [ on the first line of the Key task 1. I'm not sure now what I meant but I find the titles and indices of the vignettes are now appropriate Note that there are some links related to the other viggnette that are hardcoded. It is usually recommended to look up vignette("setup", package = "tidytags").
  Also note that users don't see the options used on the code chunks so mentions to " (notice that eval = FALSE)." (Found on the last text line before pull_tweet_data) are not useful for the reader without accessing the source of the vignette.

• 1.2
  The vignettes are now very clear

• 1.3
  As you wish

• 1.4
  Much better documented, thanks.

• 1.5
  Thanks, was the discussion about price keep on purpose?

• 1.6
  Great!

• 1.7
  get_url_domain uses longurl package without checking if it is installed, either add it to imports or check via if (requireNamespace("longurl", quiet = TRUE) ) {...}. geocode_tags uses unconditional opencage as you said it is optional I would use if (requireNamespace("longurl", quiet = TRUE) ) {...}. Check that other suggested packages are used conditionally (I think mapview is also used on the vignette but not checked if installed). So that the users receive a friendly message when using the function without the package (not only on the vignette [where I would delete this information])

• 1.8
  I couldn't find any requireNamespace on the package.

• 1.9
  Thanks, that will help the users.

• 1.13
  I'm sure the changes made will help all R users using the package.

• 1.21
  This comment was meant as a heads up of the work that will mean to maintain a package that depends on 3 different APIs an the upcomming changes on rtweet, not that the changes on rtweet could affect the review.

• 1.28
  If users have not set up correctly the rtweet account, they don't receive any information and the tmp_df from get_upstream_tweets example is empty, resulting on an error when using get_upstream_tweets. Maybe adding a check on the function to see if some tweets were collected might be helpful.

Many thanks for all the changes.

Hours spend: ~3 (Is still needed to report this?)

[bretsw]

@llrs thank you for your quick turnaround on your follow-up review! I'm unplugged this week, but I will clean up these remaining few things on Monday. Thank you again!

[maelle]

Thanks @bretsw for the detailed response & @llrs for the new feedback!

Regarding empty cassettes, it might be worth subscribing to ropensci/vcr#244

[maelle]

@llrs yes I will update the time spent, thank you for reporting that as well!

[bretsw]

@llrs, thank you for your follow-up review and comments. I have made further updates as requested:

• 1.1: I have corrected the missing "[", referenced vignettes everywhere using vignette(), and removed the comment about setting "eval = FALSE".
• 1.5: We accidentally missed deleting the discussion of price. I have now deleted this paragraph.
• 1.7 and 1.8: I have added if (!requireNamespace("package_name", quietly = TRUE)) {stop("Please install the {package_name} package to use this function", call. = FALSE)} for {longurl} and {urltools} inside the get_url_domain() function, for {opencage} inside the geocode_tags() function., and for {beepr} inside the lookup_many_tweets() and lookup_many_users() functions. I have added `if (requireNamespace("package_name", quietly = TRUE) for {mapview}, {sf}, {ggplot2}, {ggraph}, and {tidygraph} in the function documentation and vignettes. This should cover all suggested-but-not-imported packages.
• 1.28: I added an if(nrow(unknown_upstream) == 0) {...} else {...} to the get_upstream_tweets() function. Please let me know if this is sufficient for the concern you have raised, or if there needs to be another check added to get_upstream_tweets() or even pull_tweet_data().

[bretsw]

@maelle, could we remove the holding label for this thread?

[llrs]

I think that the package is now in great shape @bretsw, thanks for adding me as reviewer on your package description file.

---

I think I do not need to mark anything on the current template to signal the review as finished (Wasn't there a check mark on the previous version of the reviewer's template?). I think that on my side, unless other discussions or more feedback is wanted I do not have anything else to suggest as improvements. I will unsubscribe the thread, but ping me to let me know if there is anything I can help with.

[bretsw]

I think that the package is now in great shape @bretsw, thanks for adding me as reviewer on your package description file.

Thank you, @llrs, for your feedback, guidance, and patience. I have been very grateful for this review process.

[maelle]

@llrs thank you! Here's the reviewer approval comment template if you have time: https://devguide.ropensci.org/approval2template.html

@marionlouveaux would you have time to take a last look at the package?

[llrs]

Reviewer Response

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

[marionlouveaux]

Reviewer Response

Thank you for responding to my review and adding me as a reviewer on your package. The package documentation is much better and much clearer. I found one minor aesthetic issue in the help of pull_tweet_data(): I noticed some formatting issues such as \code{n} (in the example section). I suggest using roxygen2md::roxygen2md() to fix these (see https://roxygen2md.r-lib.org/).

I still approve the package now so as not to delay further the process.

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

[bretsw]

@marionlouveaux, thank you so much for your follow up review. @jrosen48 and I are truly grateful!

Thank you for pointing out roxygen2md::roxygen2md()--what a handy function! I've cleaned up the documentation and pushed changes.

[maelle]

Thanks a ton @marionlouveaux!

[maelle]

@ropensci-review-bot approve tidytags

[ropensci-review-bot]

Approved! Thanks @bretsw for submitting and @llrs, @marionlouveaux for your reviews! 😁

To-dos:

• Transfer the repo to rOpenSci's "ropensci" GitHub organization under "Settings" in your repo. I have invited you to a team that should allow you to do so.
• After transfer write a comment @ropensci-review-bot finalize transfer of <package-name> where <package-name> is the repo/package name. This will give you admin access back.
• Fix all links to the GitHub repo to point to the repo under the ropensci organization.
• Delete your current code of conduct file if you had one since rOpenSci's default one will apply, see https://devguide.ropensci.org/collaboration.html#coc-file
• If you already had a pkgdown website and are ok relying only on rOpenSci central docs building and branding,
  • deactivate the automatic deployment you might have set up
  • remove styling tweaks from your pkgdown config but keep that config file
  • replace the whole current pkgdown website with a redirecting page
  • replace your package docs URL with https://docs.ropensci.org/package_name
  • In addition, in your DESCRIPTION file, include the docs link in the URL field alongside the link to the GitHub repository, e.g.: URL: https://docs.ropensci.org/foobar (website) https://github.com/ropensci/foobar
• Fix any links in badges for CI and coverage to point to the new repository URL.
• Increment the package version to reflect the changes you made during review. In NEWS.md, add a heading for the new version and one bullet for each user-facing change, and each developer-facing change that you think is relevant.
• We're starting to roll out software metadata files to all rOpenSci packages via the Codemeta initiative, see https://docs.ropensci.org/codemetar/for how to include it in your package, after installing the package - should be easy as running codemetar::write_codemeta() in the root of your package.
• You can add this installation method to your package README install.packages("<package-name>", repos = "https://ropensci.r-universe.dev") thanks to R-universe.

Should you want to acknowledge your reviewers in your package DESCRIPTION, you can do so by making them "rev"-type contributors in the Authors@R field (with their consent).

Welcome aboard! We'd love to host a post about your package - either a short introduction to it with an example for a technical audience or a longer post with some narrative about its development or something you learned, and an example of its use for a broader readership. If you are interested, consult the blog guide, and tag @stefaniebutland in your reply. She will get in touch about timing and can answer any questions.

We maintain an online book with our best practice and tips, this chapter starts the 3d section that's about guidance for after onboarding (with advice on releases, package marketing, GitHub grooming); the guide also feature CRAN gotchas. Please tell us what could be improved.

Last but not least, you can volunteer as a reviewer via filling a short form.

[bretsw]

@ropensci-review-bot finalize transfer of tidytags

[ropensci-review-bot]

Transfer completed. The tidytags team is now owner of the repository

[bretsw]

Hi @maelle, so I thought I updated everything as requested for the transfer to rOpenSci, but now all my GitHub actions are failing. Any suggestions? https://github.com/ropensci/tidytags/actions

[bretsw]

@maelle, could you also remove the 4/review(s)-in-awaiting-changes tag? I'm wondering if this makes the badge in the README show up as "Under Review" instead of "Peer Reviewed"...

[bretsw]

Looks like I fixed the GitHub pages issue (needed to change the build to happening from the root directory in Settings) and got codecov to work (needed to update the key following the transfer to rOpenSci) - https://github.com/ropensci/tidytags

For the R-CMD-CHECK, looks like some issue with the terra package is tripping it up. So, probably nothing to be done at this point.

[maelle]

Thanks for the updates, happy to look again if the installation issue doesn't resolve itself within a few days.