In rjournal/rj: Tools for managing the R journal

knitr::opts_chunk$set(
  collapse = TRUE,
  comment = "#>",
  echo = FALSE,
  warning = FALSE,
  message = FALSE
)

Mission

As an Associate Editor, you will receive manuscripts from one of the four current Editors. You will be responsible for the following steps.

Read the paper and decide if it needs reviews. If you feel that the article is not sufficient quality for the R Journal, you can provide a review yourself and recommend rejection, without obtaining any other reviews. You can also request (via the Editor) further refinement of the paper before you send it to reviewers.
Find reviewers. If you feel that the paper needs expert reviews, you will need to find at least two reviewers with expertise in the subject area of the submission. (See below for some tips on finding reviewers.) Reviewers are given approximately 1--3 months to review a paper.
Make a recommendation. You should recommend one of the following options: reject, accept with major revisions, accept with minor revisions, or accept as is.
Write a short summary explaining the reason for the recommendation. Ultimately it is the handling editor who makes the final decision on a paper, and manages all communication with authors.

The expected workload is 1--2 papers per month.

Terms are for three years, with an opportunity to renew.

Communication

Each AE is provided a Github repo for handling papers, with the name in the form of ae-articles-XX. When you receive an article from an editor, you will find it in the Submissions folder of your repo.

Slack is used for communication between editors and associate editors, and general information about operations. The channel for AEs is associate-editors and there are numerous other channels focusing on different aspects of operations, including rj-software, general, journal-website, that you are welcome to join. This is the best place to receive messages from an editor that a paper is assigned to you, and for you to notify that editor when you have received reviews, made your summary and are ready to hand it back.

Meetings with the Editors and Associate Editors will usually be held monthly. The meeting time is set by the Editor-in-Chief.

Email is usually the best way to communicate with reviewers.

Please do not communicate directly with authors. The Editor is responsible for all communication with authors. You should only be communicating with reviewers and with the handling editor who allocated you the paper.

Workflow and operations

Getting started

Install the rj package with

remotes::install_github("rjournal/rj")

The package is being updated and revised regularly, so you may want to re-install occasionally.

Workflow

All submissions you are handling will be in your Github repository, in the Submissions folder. Each submission is in a separate folder named with the ID of the article; e.g., 2024-12. This folder will contain a number of files:

article files: RJwrapper.tex, .tex, .bib, and possibly .R, .Rmd, data and figure files.
our operation files:
- DESCRIPTION: contains up to date information about the state of the article. It is plain text but you should use the rj function to modify it, if possible.
- correspondence folder, usually containing motivating-letter.pdf. This is also where the invitations to each reviewer will be added, and the reviews will be stored once they have been returned by reviewers.

#| label: wfgraph
#| fig.width: 8
#| fig.height: 12
#| fig.align: center
library(DiagrammeR)
AE_df <- create_node_df(n=10,
   type=c("decision", #1
          "action", #2
          "action", #3
          "action", #4
          "action", #5
          "decision", #6
          "decision", #7
          "action", #8
          "action", #9
          "action"), #10
   label=c("Send for review?", #1
           "Select reviewer (ideally two), rj::match_keywords() or use your own experts", #2
           "Update reviewer in DESCRIPTION, rj::add_reviewer() \n This also generates the email template saved in the correspondence folder", #3
           "Send email to reviewers, which includes motivating letter, pdf and R files \n rj::update_status() to out for review", #4
           "Check all file changes into GitHub, \n including correspondence folder", #5
           "Reviewer agreed (1 week)? \n Use agree_reviewer() or\n decline_reviewer()", #6
           "Reviews received", #7
           "Save reviews into correspondence folder, rj::add_review()", #8
           "Make recommendation (AE: major revision, AE: minor revision, AE: accept or AE: reject),\n update DESCRIPTION using rj::update_status(), notify editor, check all into GitHub", #9
           "Send reminder email"), #10
   shape = c("rectangle",
             "rectangle",
             "rectangle",
             "rectangle",
             "rectangle",
             "rectangle",
             "rectangle",
             "rectangle",
             "rectangle",
             "rectangle",
             "rectangle"),
   width = c(3, 5, 6, 6, 3, 4, 3, 4, 6, 2),
   fillcolor = c("orange", "grey90",
                 "grey90", "grey90", "grey90",
                 "orange", "orange", "grey90",
                 "aquamarine2", "grey90"),
   fontcolor = "black")

AE_edge_df <- create_edge_df(from = c(1:8,6,7,10,1),
                             to = c(2:9,2,10,7,9),
                             label = c("Y", rep(".", 4), "Y",
                                       "Y", ".", "N", "N","done","N"),
                             color = c("dodgerblue2",
                                       "grey50", "grey50",
                                       "grey50", "grey50",
                                       "dodgerblue2",
                                       "dodgerblue2",
                                       "grey50",
                                       "red", "red",
                                       "grey50", "red"
                                       ))

AE <- create_graph(AE_df, AE_edge_df,
                   directed = TRUE, attr_theme = "tb")
render_graph(AE)

Potential reviewers

There are several ways to find reviewers for a paper.

Match keywords against the reviewer database.

We have a list of potential reviewers that has been collected using this form for people to volunteer to review for the R Journal. Please complete this form yourself.

This form populates a spreadsheet that is used to match keywords between articles and reviewers. Once you are set up as an AE, you need access to this sheet in order to use the rj::match_keywords() function. You can request access from the assigning editor if it isn't visible to you.
Look for authors of related R packages. The submission may cite some similar packages, or you may find similar packages on a CRAN Task View. Authors of similar packages are often the best reviewers, and are usually motivated to review a paper that is related to their own work.
Look for authors of recent related papers. These may be papers cited in the submission, or papers that you find via a Google Scholar search. Restrict your search to papers that are published in the last few years.
Once you have a list of a few potential reviewers, check their websites to determine (a) how active they are in the area; (b) how senior they are; and (c) whether they appear to be R users. The ideal reviewer is someone who is actively working in the area, uses R, and does not have substantial management responsibilities. Post-docs or junior faculty are often the best reviewers, as they have more time than senior academics, and more experience than PhD students. Someone with substantial expertise in the topic, but who is not an R user, may still be able to provide helpful comments on the paper, but they are less likely to be able to provide useful comments on the code.
Rank your reviewers in preference order. You will need to invite at least two reviewers, and it is best to have some in reserve in case one of the first two declines. Think about who is most likely to agree; e.g., someone is more likely to agree if they know you.
Where possible, try to find reviewers with different expertise. For example, one may have stronger expertise in the statistical methods, with the other having greater expertise in writing R packages.
Before sending them, edit the review-request emails to explain why you're asking them to review the submission. For example, "As the author of package X, I'd be interested in your thoughts on this submission." Or "I'm aware of your JRSSB paper on XXX, so I'm keen to get your thoughts on this submission which takes a different approach to the same problem." Or "The authors compare their package against the method you developed in XXX, so I'd like to know your views on this submission." If they know why you asked them, they are more likely to respond positively.
If you only manage to get one review, you may need to provide a review yourself.

Package usage

These are the primary functions that are useful for AE operations

match_keywords
add_reviewer
invite_reviewers
agree_reviewer, decline_reviewer
add_review
update_status using AE:major_revision, AE:minor_revision, AE:major_reject
valid_status lists the available statuses to use