An R function to populate rOpenSci's "Review request template"

[maurolepore]

Maybe something like this could be available via a shiny app or the bot?

• Repo: https://github.com/maurolepore/ropensciutils
• Demo: https://youtu.be/0FeUVY5F21g

---

?ropensciutils::draft_email_for_potential_reviewer()

Usage

draft_email_for_potential_reviewer(
  reviewer_name = "Jane Smith",
  package = "coolr",
  author_name = "John Doe",
  package_does = "does cool things in R",
  package_repo_url = "https://github.com/jhondoe/coolr",
  package_review_issue_url = "https://github.com/ropensci/software-review/issues/000",
  why_reviewer_fits = "of your experience developing cool things"
)

Example

rOpenSci: Invitation to review the package coolr

Dear Jane Smith,

I hope this email finds you well. I'm writing to ask if you would be willing to review a package for rOpenSci. rOpenSci conducts peer review of R packages contributed to our collection in a manner similar to journals.

The package coolr, by John Doe, does cool things in R. You can find its GitHub repo at https://github.com/jhondoe/coolr and its open-review issue at https://github.com/ropensci/software-review/issues/000. If you accept, note that we ask reviewers to complete reviews in three weeks. (We've found it takes a similar amount of time to review a package as an academic paper.)

Our reviewers guide details what we look for in a package review, and includes links to example reviews. Our standards are detailed in our packaging guide, and we provide a reviewer template for you to use. Please make sure you do not have a conflict of interest preventing you from reviewing this package. If you have questions or feedback, feel free to ask me or post to the rOpenSci forum.

Are you able to review? I think you would be a great reviewer because of your experience developing cool things. If I don't hear from you within a week, I will assume you are unavailable.

Thank you for your time.

Sincerely, Mauro Lepore

[mpadge]

@maurolepore Unfortunately that can't be done as a bot request because issue comments can only be posted as complete entries, not as drafts. Plus issuing bot comments would then leave traces of who had been asked, which is undesirable. So we'll have to pursue one of your other strategies, unfortunately ... I would lean towards a function within a package rather than a shiny app, purely because that would be far easier to maintain. Interested to hear thoughts from @maelle and @steffilazerte?

We'd at least be able to simplify a function call down to just review URL and info on who is being asked. All the rest (package name, description, repo URL) would be able to be auto-extracted from the YAML issue header.

[maelle]

I've been meaning to create an R function doing that for a while, but haven't started.

[noamross]

I'm kind of curious about doing this as pure client-side Javascript. A simple HTML page could take the issue URL and reviewer name and URL and spit out the templated text.

[mpadge]

Ha, i thought about that suggesting againt shiny. I am a really strong advocate of vercel these days, and could easily whip up a vercel deploy for that if you want? nextjs is now by default all client-side, so you get that behaviour by default

[noamross]

You are already way ahead of me on this. Could we embed it in the dev guide? Or maybe the bot just prints a link to it when it's time to assign reviewers.

[mpadge]

Oh, one problem is that vercel deploys are only free from GitHub user spaces, not from orgs. So it'd have to be done in github.com/mpadge, alas. But we could assign a sub-domain to the deployment, so at least that would help.

[maurolepore]

Thanks @mpadge -- the problems with the bot make total sense. And I love your idea of extracting as much as possible of the info we already have.

[robitalec]

Not to jump in - but are the {pkgreviewr} functions pkgreview_request and render_request helpful here?

eg.

library(pkgreviewr)
pkg_data <- pkgreview_getdata('../rredlist/', 'ropensci/rredlist', 'editor', 663)
pkgreview_request(pkg_data)

---
output: html_document
params:
    reviewer_first_name: "Jane"
    banter: " "
    JOSS: FALSE

---

Dear `r params$reviewer_first_name`

Hi, this is  from rOpenSci `r emo::ji("wave")`.

`r params$banter`

I'm writing to ask if you would be willing to review a package for rOpenSci.
As you probably know, rOpenSci conducts peer review of R packages contributed to our collection in a manner similar to journals.

The package is **`rredlist`** by `r 
    c(person(given = "William",
             family = "Gearty",
             role = c("aut", "cre"),
             email = "willgearty@gmail.com"),
      person(given = "Scott",
             family = "Chamberlain",
             role = c("aut"),
             email = "myrmecocystus@gmail.com"),
      person(given = "rOpenSci",
             role = "fnd",
             comment = "https://ropensci.org/"),
      person(given = "Maëlle",
             family = "Salmon",
             role = "ctb",
             email = "maelle.salmon@yahoo.se")
      )`:

> 'IUCN' Red List (<https://api.iucnredlist.org/>) client.
    The 'IUCN' Red List is a global list of threatened and endangered species.
    Functions cover all of the Red List 'API' routes. An 'API' key is required.

You can find it on GitHub [here](https://github.com/ropensci/rredlist).
We conduct our open review process via GitHub as well, [here](https://github.com/ropensci/software-review/issues/663).

If you accept, note that we ask reviewers to complete reviews in three weeks.
(We’ve found it takes a similar amount of time to review a package as an academic paper.)

Our [reviewers guide] details what we look for in a package review and includes links to example reviews.
Our standards are detailed in our [packaging guide], and we provide a reviewer [template] for you to use.
You can also use package [pkgreviewr] to help set up and guide your review.
If you have questions or feedback, feel free to ask me or post to the [rOpenSci forum].
You can also try the rOpenSci Slack community.
If you accept to review and are not already a member of the Slack community, please let me know so I can invite you.

`r if(params$JOSS){"The authors have also chosen to jointly submit their package to the Journal of Open Source Software, so this package includes a short paper.md manuscript describing the software that we ask you include in your review."}`

Are you able to review?
If you cannot, suggestions for alternate reviewers are always helpful.
If I don't hear from you within a week, I will assume you are unable to review at this time.

Thank you for your time.

Sincerely,

[reviewers guide]: https://ropensci.github.io/dev_guide/reviewerguide.html
[packaging guide]: https://ropensci.github.io/dev_guide/building.html
[template]: https://ropensci.github.io/dev_guide/reviewtemplate.html
[rOpenSci forum]: https://discuss.ropensci.org/
[pkgreviewr]: https://github.com/ropenscilabs/pkgreviewr

(Not sure how active {pkgreviewr} is these days)

[noamross]

Oh, one problem is that vercel deploys are only free from GitHub user spaces, not from orgs. So it'd have to be done in github.com/mpadge, alas. But we could assign a sub-domain to the deployment, so at least that would help.

In that case, why deploy with Vercel at all? A pure client-side JS implementation should just be a single static HTML page that could go anywhere, like in the dev guide repo itself. In any case, this is not high priority, I was idly speculating above.

Thanks for reminding us of that pkgreviewer function, @robitalec! We can forget our own old projects.

[maurolepore]

Thanks @robitalec for the reminder! One great use of this conversation is precisely to re-discover the tools we already have.

Considering the overlap with pkgreviewr the tool I shared above lacks the merit to live in its own R package.

I'm now curiously watching the conversation between @noamross and @mpadge to try understand how that approach can help integrate tools like this directly on the devguide.

[mpadge]

We can't do it directly, primarily because of "Cross-origin resource sharing" that means that,

For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts.

So you can't have a script that fetches any HTTP(S) data. We could only get where we want with some kind of server, minimally a proxy to divert CORS requests, but if we need a server anyway, then a full vercel deploy would be easier. But even far easier still is likely just maintaining and directing to the simple R script/function wherever it ends up living.