revise editors chapter for #487 #974

mpadge · 2025-12-02T12:05:12Z

No description provided.

And rm previously separate 'Asking for more details' sub-section

mpadge · 2025-12-03T11:50:12Z

@maelle This would be ready for review, but the Render Book workflow is failing, in ways I think related to babelquarto. The pandoc render of the English version works fine, then it moves on to the Spanish version and fails soon after then.

I've seen those fails on other PR renders before, but they've always auto-resolved. This one seems not to want to do that. Any insights would be greatly appreciated, thanks!

maelle · 2025-12-05T13:37:39Z

I'm investigating the CI problem, we had issues for a while recently then I fixed one workflow file and forgot to update the others.

maelle

Thank you! Soon we'll need a whole book for editors 😅

maelle · 2025-12-05T13:39:11Z

softwarereview_editor.Rmd

+All submissions are initially considered by the Editor-in-Chief, who makes the initial decision on whether a package is in scope.
+If so, a handling editor is assigned who is then responsible for guiding the actual review process.
+
+Please be aware that all people involved in the review process are volunteers who are freely and willingly devoting their own time.


Rather that those two sentences, use the same ones as at the top of the reviewer's guide about rOpenSci community being its best asset?

maelle · 2025-12-05T13:40:22Z

softwarereview_editor.Rmd

+The EiC is responsible for [general management](#eic-general) of the review process, and for the [initial stages](#eic-submission) of all submissions.

- Tagging each new full submission with ` 0/editorial-team-prep`
+### General EiC duties {#eic-general}


on the dashboard page, how do you

know when it's last been updated

get a link to the workflow building it to investigate status if need be?

It's updated daily, and issues a ping on any failures, visible to anybody watching the repo. That one virtually never fails - unlike others - so we don't really need to worry.

maelle · 2025-12-05T13:40:42Z

softwarereview_editor.Rmd

+- At the start of a rotation, the EiC should review the status of current open reviews on the [editorial dashboard](https://dashboard.ropensci.org/reviews.html), and issue reminders to other editors or package authors as needed.

- Regularly (for instance weekly) monitoring the pace of all open reviews by keeping an eye on the [*Dashboard* page](https://dashboard.ropensci.org/reviews.html), and reminding other editors to move packages along as needed.
+- Watch all new issues posted to the software-review repo, for which the EiC must either subscribe to repo notifications on GitHub, or watch the `#editors-only` channel on Slack (ideally both).


why ideally both?!

maelle · 2025-12-05T13:41:08Z

softwarereview_editor.Rmd

+- Regularly (for instance weekly) monitor the pace of all open reviews by keeping an eye on the [*Dashboard* page](https://dashboard.ropensci.org/reviews.html), and reminding other editors to move packages along as needed.

- Making decisions on scope and overlap for pre-submission inquiries, referrals from JOSS or other publication partners, and submissions. Discussions should be initiated in the rOpenSci Slack editors-only channel through summarising the (pre-)submitted/referred software, along with any concerns the EiC might have. If after the EiC feels they haven't received enough answers after a day or two, they can ping all editors.
+- Respond where appropriate to issues posted to the [software-review-meta repo](https://github.com/ropensci/software-review-meta/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen).


I wonder if this should be a staff task.

Yeah, I wonder that too. Shall we just remove it? (I think so)

maelle · 2025-12-05T13:42:32Z

softwarereview_editor.Rmd

+#### Deciding on scope and overlap

- Looking over submissions in "0\/presubmission" and "1\/editorial-team-prep", to check whether any action needs to be taken (such as polling editors, making decisions, putting issues on hold, pinging for updates, or finding and assigning editors).
+The EiC is entitled to take scope and overlap decisions as independently as possible, but is recommended to request opinions on the `#editors-only` channel on Slack.


Add that one should request opinions for submissions outside of one's areas of expertise.

maelle · 2025-12-05T13:45:16Z

softwarereview_editor.Rmd

+  ```
+  This will also add the tag `1/editor-checks` to the issue.
+
+#### Statistical software submissions {#eic-stats-submissions}


should this content also exist as a short video intro to the stat system or would that get out of date too quickly?

maelle · 2025-12-05T13:47:29Z

softwarereview_editor.Rmd

  If rejected, see [this section](#outofscoperesponse) about how to respond.
 - Ensure that the package gets tested on multiple platforms (having the package built on several operating systems via GitHub Actions for instance; see [criteria in this section of the CI chapter](#whichci) for further details and options).
- Wherever possible when asking for changes, direct authors to automatic tools such as [usethis](https://usethis.r-lib.org/), [Air](https://posit-dev.github.io/air/) and [styler](https://styler.r-lib.org/), and to online resources (sections of this guide, sections of the [R packages book](https://r-pkgs.org/)) to make your feedback easier to use. See this [example of editor's checks](https://github.com/ropensci/software-review/issues/207#issuecomment-379909739).
+- Wherever possible when asking for changes, direct authors to automatic tools such as [usethis](https://usethis.r-lib.org/), [Air](https://posit-dev.github.io/air/) and [styler](https://styler.r-lib.org/), and to online resources (sections of this guide, sections of the [R packages book](https://r-pkgs.org/)) to make your feedback easier to use.


Suggested change

- Wherever possible when asking for changes, direct authors to automatic tools such as [usethis](https://usethis.r-lib.org/), [Air](https://posit-dev.github.io/air/) and [styler](https://styler.r-lib.org/), and to online resources (sections of this guide, sections of the [R packages book](https://r-pkgs.org/)) to make your feedback easier to use.

- Wherever possible when asking for changes, direct authors to automatic tools such as [usethis](https://usethis.r-lib.org/), [Air](https://posit-dev.github.io/air/) and [styler](https://styler.r-lib.org/), and to online resources (sections of this guide, sections of the [R packages book](https://r-pkgs.org/)) to make your feedback easier to use.

rm styler, add flir and jarl instead?

maelle · 2025-12-05T13:48:11Z

softwarereview_editor.Rmd

 - Check in with reviewers and authors occasionally. Offer clarification and help as needed.
- In general aim for 3 weeks for review, 2 weeks for
-  subsequent changes, and 1 week for reviewer approval of changes.
+- In general aim for 3 weeks for review, 2 weeks for subsequent changes, and 1 week for reviewer approval of changes.


Suggested change

- In general aim for 3 weeks for review, 2 weeks for subsequent changes, and 1 week for reviewer approval of changes.

- In general, aim for 3 weeks for review, 2 weeks for subsequent changes, and 1 week for reviewer approval of changes.

maelle · 2025-12-05T13:50:29Z

softwarereview_editor.Rmd

+
+- **If the author stops responding**, refer to [the policies](#policies) and/or ping the other editors in the Slack channel for discussion.
+  Importantly, if a reviewer was assigned to a closed issue, contact them when closing the issue to explain the decision, and thank them once again for their work.
+  Let the other editors know in the Slack channel to consider them for a package in the future with high chances of smooth software review.


Suggested change

Let the other editors know in the Slack channel to consider them for a package in the future with high chances of smooth software review.

Let the other editors know in the Slack channel to consider them as reviewers for a package in the future with high chances of smooth software review.

maelle · 2025-12-05T13:51:27Z

softwarereview_editor.Rmd

-  package, contact [an rOpenSci staff member](https://ropensci.org/about/#team) so they might contact the authors
-  about transfer to [the `ropensci-books` GitHub organisation](https://github.com/orgs/ropensci-books).
+- Approve the package with `@ropensci-review-bot approve <package-name>`
+- If the original repository wishes to keep the package in their own GitHub organization rather than transfer to rOpenSci, open a pull request adding the repository URL to [this repos list](https://github.com/ropensci/roregistry/blob/gh-pages/info/not_transferred.json) to ensure the package gets included in rOpenSci package registry.


Suggested change

- If the original repository wishes to keep the package in their own GitHub organization rather than transfer to rOpenSci, open a pull request adding the repository URL to [this repos list](https://github.com/ropensci/roregistry/blob/gh-pages/info/not_transferred.json) to ensure the package gets included in rOpenSci package registry.

- If the original repository wishes to keep the package in their own GitHub organization rather than transfer to rOpenSci, open a pull request adding the repository URL to this [list](https://github.com/ropensci/roregistry/blob/gh-pages/info/not_transferred.json) to ensure the package gets included in rOpenSci package registry.

mpadge added 11 commits December 2, 2025 13:04

review EiC section for #487

ac07d62

further edits of EiC section for #487

8f908f3

two new sub-sections in EiC section for #487

755de8b

And rm previously separate 'Asking for more details' sub-section

revise guest editor section for #487

b067302

rm 'out-of'scope' section, merge into EiC section #487

dfeca5b

start revision of handling editor sections for #487

ebfdfa5

update 'during review' section of editors chapter #487

a9b3d7a

finish edits of handling editors section for #487

d6412f6

expand initial statements of editors chapter #487

b88ca58

spell check, and add 2 new sub-sections for #487

0d838a1

describe statistical properties pkgcheck output in eds chapter #487

957e8f7

maelle requested changes Dec 5, 2025

View reviewed changes

	- Wherever possible when asking for changes, direct authors to automatic tools such as [usethis](https://usethis.r-lib.org/), [Air](https://posit-dev.github.io/air/) and [styler](https://styler.r-lib.org/), and to online resources (sections of this guide, sections of the [R packages book](https://r-pkgs.org/)) to make your feedback easier to use.
	- Wherever possible when asking for changes, direct authors to automatic tools such as [usethis](https://usethis.r-lib.org/), [Air](https://posit-dev.github.io/air/) and [styler](https://styler.r-lib.org/), and to online resources (sections of this guide, sections of the [R packages book](https://r-pkgs.org/)) to make your feedback easier to use.

	- In general aim for 3 weeks for review, 2 weeks for subsequent changes, and 1 week for reviewer approval of changes.
	- In general, aim for 3 weeks for review, 2 weeks for subsequent changes, and 1 week for reviewer approval of changes.

	Let the other editors know in the Slack channel to consider them for a package in the future with high chances of smooth software review.
	Let the other editors know in the Slack channel to consider them as reviewers for a package in the future with high chances of smooth software review.

	- If the original repository wishes to keep the package in their own GitHub organization rather than transfer to rOpenSci, open a pull request adding the repository URL to [this repos list](https://github.com/ropensci/roregistry/blob/gh-pages/info/not_transferred.json) to ensure the package gets included in rOpenSci package registry.
	- If the original repository wishes to keep the package in their own GitHub organization rather than transfer to rOpenSci, open a pull request adding the repository URL to this [list](https://github.com/ropensci/roregistry/blob/gh-pages/info/not_transferred.json) to ensure the package gets included in rOpenSci package registry.

revise editors chapter for #487 #974

Are you sure you want to change the base?

revise editors chapter for #487 #974

Uh oh!

Conversation

mpadge commented Dec 2, 2025

Uh oh!

mpadge commented Dec 3, 2025

Uh oh!

maelle commented Dec 5, 2025

Uh oh!

maelle left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants