ropensci · mpadge · May 25, 2026 · May 29, 2026 · Jun 25, 2026 · Jun 25, 2026
diff --git a/booknews.Rmd b/booknews.Rmd
@@ -2,7 +2,13 @@
 
 ## Dev version
 
-- 2026-05-22, document current AI policies.
+- 2026-06-30, document current AI policies.
+- 2026-05-21, better document reviewer search in Airtable (#1009, #1010).
+- 2026-06-12, add mention of testit (#1014).
+- 2026-05-29, link in reviewer guide to stats template for stats reviews (#1012)
+- 2026-05-21, clarify that stats must start with a pre-sub (#1011).
+- 2026-05-21, add comment on updating Airtable rev-prod for new editors (#1005).
+- 2026-05-21, update docs to require pkg websites at submission (#1004).
 - 2026-04-10, two fixes to roxygen2 tags mentions (#1000, #1001, `@Pakillo`). Now 4 digits for PRs and issues!
 
 ## 1.0.0

diff --git a/images/airtable-filters.png b/images/airtable-filters.png
diff --git a/images/airtable.png b/images/airtable.png
diff --git a/pkg_building.Rmd b/pkg_building.Rmd
@@ -207,7 +207,7 @@ The badge will first indicated "under review" and then "peer-reviewed" once your
 - Consider using `usethis::use_readme_rmd()` to get a template for a `README.Rmd` file and to automatically set up a pre-commit hook to ensure that `README.md` is always newer than `README.Rmd`.
 
 - Extensive examples should be kept for a vignette. 
-  If you want to make the vignettes more accessible before installing the package, we suggest [creating a website for your package](#website).
+  If you want to make the vignettes more accessible before installing the package, we suggest [creating a website for your package](#website). All packages submitted for software review must have a website.
 
 - Add a [code of conduct and contribution guidelines](#friendlyfiles).
 
@@ -305,7 +305,8 @@ Furthermore, links would not be clickable from local docs.
 
 ## Documentation website {#website}
 
-We recommend creating a documentation website for your package using [`pkgdown`](https://github.com/r-lib/pkgdown). 
+All packages submitted for software review must have a documentation website clearly linked in the source repository.
+We recommend using [`pkgdown`](https://github.com/r-lib/pkgdown) to create your website.
 The R packages book features a [chapter on pkgdown](https://r-pkgs.org/website.html), and of course `pkgdown` has [its own documentation website](https://pkgdown.r-lib.org/).
 
 There are a few elements we'd like to underline here.
@@ -412,7 +413,7 @@ For how to update your DESCRIPTION file, see the [R packages book](https://r-pkg
 - It is good practice to write unit tests for all functions, and all package code in general, ensuring key functionality is covered. 
   Test coverage below 75% will likely require additional tests or explanation before being sent for review.
 
-- We recommend using [testthat](https://testthat.r-lib.org/) for writing tests. An alternative is [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html).
+- We recommend using [testthat](https://testthat.r-lib.org/) for writing tests. Alternatives includes [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) or [testit](https://yihui.org/en/2026/05/testthat-to-testit/).
 
 - Strive to write tests as you write each new function. 
   This serves the obvious need to have proper testing for the package, but allows you to think about various ways in which a function can fail, and to *defensively* code against those. 

@@ -2,7 +2,6 @@
 aliases:
   - building.html
 ---
-
 # Guía de empaquetado  {#building}
 
 ```{block, type="summaryblock"}
@@ -207,7 +206,7 @@ La etiqueta indicará primero "en revisión" y luego "revisado" una vez que tu p
 - Considera utilizar `usethis::use_readme_rmd()` para generar una plantilla para el archivo `README.Rmd` y para configurar automáticamente un chequeo que garantice que `README.md` sea siempre más reciente que `README.Rmd` antes de hacer un commit.
 
 - Los ejemplos largos deben incluirse sólo en las viñetas.
-  Si quieres que las viñetas sean más accesibles antes de instalar el paquete, te sugerimos [crear un sitio web para tu paquete](#website).
+  Si quieres que las viñetas sean más accesibles antes de instalar el paquete, te sugerimos [crear un sitio web para tu paquete](#website). Todos los paquetes presentados para su revisión deben contar con un sitio web.
 
 - Añade un [código de conducta y una guía de contribución](#friendlyfiles).
 
@@ -305,6 +304,7 @@ Además, no se podrá hacer click en los enlaces desde la documentación local.
 
 ## Sitio web de documentación  {#website}
 
+Todos los paquetes enviados para su revisión de software deben incluir un enlace claro a la página web de documentación en el repositorio de código fuente.
 Te recomendamos que crees un sitio web con la documentación de tu paquete utilizando [`pkgdown`](https://github.com/r-lib/pkgdown).
 Hay un [capítulo sobre pkgdown (en inglés)](https://r-pkgs.org/website.html) en libro "R packages", y, cómo no es de extrañar, el paquete `pkgdown` tiene [su propio sitio web de documentación](https://pkgdown.r-lib.org/).
 
@@ -412,8 +412,7 @@ Para saber cómo actualizar tu archivo DESCRIPTION, consulta el libro [*R packag
 - Es una buena práctica escribir *tests* unitarios para todas las funciones, y para todo el código del paquete en general, asegurando que se cubra las funcionalidades clave.
   Si la cobertura de los *tests* en tu paquete está por debajo del 75% probablemente requerirá *tests* adicionales o una explicación de la baja cobertura antes de ser enviado para su revisión.
 
-- Recomendamos utilizar [testthat](https://testthat.r-lib.org/) para escribir los *tests*. Otro paquete que se puede usar es [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html).
-
+- Recomendamos utilizar [testthat](https://testthat.r-lib.org/) para escribir los *tests*. Otros paquetes que se pueden usar son [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) y [testit](https://yihui.org/en/2026/05/testthat-to-testit/).
 -  Intenta escribir *tests* a medida que escribas cada nueva función.
   Esto responde a la necesidad obvia de tener *tests* adecuados para el paquete, pero te permite pensar en varias formas en las que una función puede fallar, y programar *defensivamente* contra esas fallas.
   [Más información sobre *tests*](https://r-pkgs.org/tests.html).

diff --git a/pkg_building.pt.Rmd b/pkg_building.pt.Rmd
@@ -2,7 +2,6 @@
 aliases:
 - building.html
 ---
-
 # Guia de desenvolvimento de pacotes {#building}
 
 ```{block, type="summaryblock"}
@@ -191,7 +190,7 @@ onde issue\_id é o número da *Issue* no repositório `software-review`. Por ex
 
 - Considere o uso da função `usethis::use_readme_rmd()` para obter um modelo para o arquivo `README.Rmd` e para configurar automaticamente uma verificação para garantir que o arquivo `README.md` seja sempre mais recente que o `README.Rmd` antes de fazer um commit.
 
-- Exemplos extensos devem ser mantidos em uma vinheta. Se você quiser tornar as vinhetas mais acessíveis antes de instalar o pacote, sugerimos [criar um site para seu pacote](#website).
+- Exemplos extensos devem ser mantidos em uma vinheta. Se você quiser tornar as vinhetas mais acessíveis antes de instalar o pacote, sugerimos [criar um site para seu pacote](#website). Todos os pacotes enviados para a revisão de software devem ter um site.
 
 - Adicionar um [código de conduta e as diretrizes de contribuição](#friendlyfiles).
 
@@ -270,6 +269,7 @@ Outras pessoas já usaram a opção para escapar de alguns URLs (alterar `<https
 
 ## Site de documentação {#website}
 
+Todos os pacotes enviados para a revisão de software devem ter um site de documentação claramente indicado no repositório de código-fonte.
 Recomendamos a criação de um site de documentação para seu pacote usando o pacote [`pkgdown`](https://github.com/r-lib/pkgdown). O livro *R packages* (em inglês) apresenta um [capítulo sobre pkgdown](https://r-pkgs.org/website.html) e também o `pkgdown` tem [seu próprio site de documentação](https://pkgdown.r-lib.org/).
 
 Há alguns elementos que gostaríamos de destacar aqui.
@@ -360,8 +360,7 @@ Para saber como atualizar seu arquivo DESCRIPTION, consulte [o livro *R packages
 
 - É uma boa prática escrever testes unitários para todas as funções e para todo o código do pacote em geral, garantindo que a funcionalidade principal seja coberta. Se a cobertura de testes em seu pacote está abaixo de 75%, provavelmente exigirá testes adicionais ou explicações antes de ser enviado para revisão.
 
-- Recomendamos o uso do [pacote testthat](https://testthat.r-lib.org/) para escrever testes. Uma alternativa é o [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html).
-
+- Recomendamos o uso do [pacote testthat](https://testthat.r-lib.org/) para escrever testes. Outras opções incluem os pacotes [tinytest](https://journal.r-project.org/archive/2021/RJ-2021-056/index.html) ou [testit](https://yihui.org/en/2026/05/testthat-to-testit/).
 - Se esforce para escrever testes ao escrever cada nova função. Isso atende à necessidade óbvia de ter um teste adequado para o pacote, mas permite que você pense sobre as várias maneiras pelas quais uma função pode falhar e programe *defensivamente* contra essas falhas. [Mais informações sobre testes](https://r-pkgs.org/tests.html).
 
 - Os testes devem ser fáceis de entender e ser tão autocontidos quanto possível. Ao usar o testthat, evite usar código fora do `test_that()` (como etapas de pré-processamento). Recomendamos a leitura da seção [*"high-level principles for testing"* (princípios de alto nível para testes)](https://r-pkgs.org/testing-design.html#sec-testing-design-principles) no *livro R Packages*.
@@ -561,5 +560,3 @@ Se você pretende que seu pacote seja enviado para o Bioconductor ou se o pacote
 #### MOOCs {#moo-cs}
 
 Existe um [especialização do Coursera correspondente ao livro escrito por Roger Peng, Sean Kross e Brooke Anderson](https://fr.coursera.org/specializations/r), com um curso específico sobre pacotes R.
-
-
diff --git a/scripts/airtable-get-data.R b/scripts/airtable-get-data.R
@@ -24,13 +24,13 @@ at_guest <- airtabler::airtable(base = "app8dssb6a7PG6Vwj",
                                  table = "guest-editors")
 
 
-editor_index_all <- purrr::map_lgl(reviewers$editor, ~!is.null(.))
+editor_index_all <- purrr::map_lgl(reviewers$editor, ~!is.null(.) && !anyNA(.))
 editors_all <- reviewers[which(editor_index_all), c("name", "github", "Affiliation", "editor")]
 editors_all <- editors_all [which(!editors_all$name == eic_name), ]
 last_names <- humaniformat::last_name(trimws(editors_all$name))
 editors_all <- editors_all[order(last_names), ]
 
-editors_past <- editors_all[grep("Emeritus", editors_all$editor), ]
+editors_past <- editors_all[grep("Emeritus|On\\sLeave", editors_all$editor), ]
 editors <- editors_all[which(!editors_all$name %in% editors_past$name), ]
 
 guest_editors <- at_guest$`guest-editors`$select_all()

diff --git a/softwarereview_author.Rmd b/softwarereview_author.Rmd
@@ -16,6 +16,8 @@ This concise guide presents the software peer review process for you as a packag
 - Consult our [policies](#policies) see if your package meets our criteria for fitting into our suite and does not overlap with other packages.
   - If you are unsure whether a package meets our criteria, feel free to open an issue as a pre-submission inquiry to ask if the package is appropriate.
   - [Example response regarding overlap](https://github.com/ropensci/software-review/issues/199#issuecomment-375358362). Also consider adding some points about similar packages to your [package documentation](#docs-general).
+- Statistical software must comply with additional requirements detailed in our separate [*Statistical Software Guide*](https://stats-devguide.ropensci.org/).
+  - Statistical software *must* also start with a pre-submission inquiry.
 
 ### Lifecycle
 
@@ -39,8 +41,10 @@ This concise guide presents the software peer review process for you as a packag
 
 The use of generative AI tools is acceptable in packages submitted for peer review, as described in [our initial blog post](https://ropensci.org/blog/2026/02/26/ropensci-ai-policy/).
 As stated in [our general policies](#policies-ai), we require all submitting authors to describe how such tools may have been used, and to include links to any relevant aspects of repositories.
-A very general rule-of-thumb is the greater the use of generative AI tools in an rOpenSci submission, the more documentation we will expect, and the more we will expect such tools to have been used _systematically_.
-Systematic tool usage includes any approach which transparently and progressively details the contribution of generative AI tools to software production.
+
+- Please provide easy-to-find details or links on any usage of generative AI tools in your documentation, like in [this package](https://apaf-bioinformatics.github.io/HydraR/#robot-use-of-generative-ai).
+- A very general rule-of-thumb is the greater the use of generative AI tools in an rOpenSci submission, the more documentation we will expect, and the more we will expect such tools to have been used _systematically_.
+- Systematic tool usage includes any approach which transparently and progressively details the contribution of generative AI tools to software production, such as [GitHub's "spec-kit"](https://github.github.com/spec-kit/).
 Examples of systematic generative AI tools range from [GitHub's "spec-kit" for specification-driven development](https://github.com/github/spec-kit) to [our own experimental tool to document software design decisions](https://github.com/ropensci-review-tools/designlens).
 These all share the common pattern of producing additional artefacts which document the _process_ of development alongside the software itself.
 

@@ -16,6 +16,9 @@ Esta guía condensa el proceso de revisión por pares desde el punto de vista de
   - Si no sabes si un paquete cumple con nuestros criterios, no dudes en abrir un _issue_ para consultarlo.
   - [Ejemplo de respuesta sobre solapamiento](https://github.com/ropensci/software-review/issues/199#issuecomment-375358362). Considera también añadir información sobre paquetes similares a tu [documentación de paquetes](#docs-general).
 
+- Los paquetes estadísticos deben cumplir los requisitos adicionales que se detallan en nuestra otra [*Guía de desarrollo de software estadístico*](https://stats-devguide.ropensci.org/).
+  - Software estadístico *debe* comenzar también con una investigación previa a la presentación.
+
 ### Ciclo de desarrollo
 
 - Por favor, no envies varios paquetes a la vez: te rogamos que espere hasta que un paquete haya sido aprobado antes de enviar otro.

diff --git a/softwarereview_author.pt.Rmd b/softwarereview_author.pt.Rmd
@@ -13,9 +13,12 @@ Este guia conciso apresenta o processo de revisão de software por pares, para v
 ### Escopo
 
 - Consulte nossas [políticas de uso](#policies) para ver se o seu pacote atende aos nossos critérios e se encaixa em nossa coleção, não se sobrepondo a outros pacotes já existentes.
-  - Se você não tiver certeza de que um pacote atende aos nossos critérios, sinta-se à vontade para abrir um  _issue_ no GitHub como uma consulta de pré-submissão para perguntar se o pacote é apropriado.
+  - Caso não tenha certeza se um pacote atende aos nossos critérios, sinta-se à vontade para abrir uma _issue_ no GitHub como uma consulta de pré-submissão para perguntar se o pacote é apropriado.
   - [Exemplo de resposta a sobreposição](https://github.com/ropensci/software-review/issues/199#issuecomment-375358362). Também considere adicionar alguns pontos sobre pacotes semelhantes ao seu na sua [documentação do pacote](#docs-general).
 
+- O software estatístico deve atender aos requisitos adicionais detalhados em nosso [*Guia de software estatístico*](https://stats-devguide.ropensci.org/).
+  - O software estatístico também *deve* começar com uma consulta pré-submissão.
+
 ### Ciclo de vida
 
 - Não envie vários pacotes ao mesmo tempo: solicitamos que você espere até que um pacote seja aprovado antes de enviar outro.

diff --git a/softwarereview_editor.Rmd b/softwarereview_editor.Rmd
@@ -271,11 +271,16 @@ When these sources of information are not enough,
 
 ##### Tips for reviewer search in Airtable {#tips-for-reviewer-search-in-airtable}
 
-You can use filters, sorting, and search to identify reviewers with particular experience:
+Our Airtable database is linked at the top of our Slack 'editors-only' channel.
+Once you log in to Airtable via that link, you should see "*rOpenSci Software Review Database*" with "*Search Reviewers*" at the top left:
 
-![Screenshot of the Airtable filters interface with a filter on domain expertise that has to include chemistry and technical areas that have to include continuous integration](images/airtable.png)
+![Screenshot of the main Airtable interface with 'Search Reviewers' link](images/airtable.png)
 
-Please check the reviewer's most recent review and avoid anyone who has reviewed anyone in the past six months.
+At the top right, there is a "Filter" button to filter, sort, and search reviewers with particular experience:
+
+![Screenshot of the Airtable filters interface with a filter on domain expertise that has to include chemistry and technical areas that have to include continuous integration](images/airtable-filters.png)
+
+Please check potential reviewers' most recent review and avoid anyone who has reviewed anyone in the past six months.
 Also, please check if a first-time reviewer has indicated that they `require_mentorship`.
 If so, please use the mentorship portion of the email template and be prepared to provide additional guidance.
 
@@ -364,4 +369,4 @@ For package authors who wish to retain their repositories in their original GitH
 
 #### Package promotion {#package-promotion}
 
-- Direct the author to the chapters of the guide about [package releases](#releases), [marketing](#marketing) and [GitHub grooming](#grooming).
+- Direct the author to the chapters of the guide about [package releases](#releases), [marketing](#marketing) and [GitHub grooming](#grooming).
@@ -271,9 +271,10 @@ Cuando estas fuentes de información no sean suficientes,
 
 ##### Consejos para la búsqueda en Airtable {#tips-for-reviewer-search-in-airtable}
 
-Puedes utilizar filtros, clasificación y búsqueda para identificar personas para la revisión con una experiencia concreta:
+Nuestra base de datos de Airtable aparece enlazada en la parte superior de nuestro canal de Slack «*editors-only (solo equipo editorial)».
+Una vez que inicies sesión en Airtable a través de ese enlace, deberías ver «*rOpenSci Software Review Database (Base de datos de reseñas de software de rOpenSci)*» con la opción «*Search Reviewers (buscar revisores)*» en la parte superior izquierda:
 
-![Captura de pantalla de la interfaz de filtros de Airtable con un filtro sobre experiencia en disciplinas que debe incluir química y en conocimientos técnicos que tienen que incluir integración continua](images/airtable.png)
+![Captura de pantalla de la interfaz de filtros de Airtable con un filtro sobre experiencia en disciplinas que debe incluir química y en conocimientos técnicos que tienen que incluir integración continua](images/airtable-filters.png)
 
 Comprueba la revisión más reciente de la persona y evita a cualquiera que haya revisado en los últimos seis meses.
 Asimismo, comprueba si una persona que es nueva revisando ha indicado que requiere tutoría en el campo`require_mentorship`.
@@ -364,4 +365,4 @@ Para aquellas personas que deseen mantener los repositorios de su paquete en sus
 
 #### Promoción de paquetes {#package-promotion}
 
-- Dirige a quién envió el paquete a los capítulos de la guía sobre [versionado y publicación de paquetes](#releases), [marketing](#marketing) y [preparación para GitHub](#grooming).
+- Dirige a quién envió el paquete a los capítulos de la guía sobre [versionado y publicación de paquetes](#releases), [promocionando tu paquete](#marketing) y [gestión de GitHub](#grooming).