improve reviewing guide

booknews.Rmd

@@ -2,6 +2,8 @@
 
 ## dev version
 
+- 2025-04-10, replace the link to the Mozilla Code Review guide with explicit items (#835)
+
 - 2025-04-03, document how to put the system on vacation(#865)
 
 - 2025-04-03, add details about MEE process and structure the author guide a bit more (`@robitalec`, #862)

softwarereview_reviewer.Rmd

@@ -42,16 +42,17 @@ All submissions trigger a detailed report on package structure and functionality
 
 To review a package, please begin by copying our [review template](#reviewtemplate) (or our [review template in Spanish](#reviewtemplatees)) and using it as a high-level checklist.  In addition to checking off the minimum criteria, we ask that you provide general comments addressing the following:
 
-- Does the code comply with general principles in the [Mozilla reviewing guide](https://mozillascience.github.io/codeReview/review.html)?
 - Does the package comply with the [rOpenSci packaging guide](#building)?
-- Are there improvements that could be made to the code style?
+- Are there improvements that could be made to the code style and to code patterns? For instance, do functions need to be broken down into smaller helper functions and is the role of each helper function clear?
 - Is there code duplication in the package that should be reduced?
+- Are there functions in base R or lightweight dependency that provide the same interface as some helper functions in the package?
 - Are there user interface improvements that could be made?
 - Are there performance improvements that could be made?
 - Is the documentation (installation instructions/vignettes/examples/demos) clear and sufficient? Does it use the principle of *multiple points of entry* i.e. takes into account the fact that any piece of documentation may be the first encounter the user has with the package and/or the tool/data it wraps?
 - Were functions and arguments named to work together to form a common, logical programming API that is easy to read, and autocomplete?
 - If you have your own relevant data/problem, work through it with the package. You may find rough edges and use-cases the author didn't think about.
 
+
 Please be respectful and kind to the authors in your reviews. Our [code of conduct](#code-of-conduct) is mandatory for everyone involved in our review process. We expect you to submit your review within 3 weeks, depending on the deadline set by the editor. Please contact the editor directly or in the submission thread to inform them about possible delays.
 
 We encourage you to use automated tools to facilitate your reviewing.  These include:
@@ -64,6 +65,8 @@ We encourage you to use automated tools to facilitate your reviewing.  These inc
 
 Reviewers may also re-generate package check results from `@ropensci-review-bot` at any time by issuing the single comment in a review issue: `@ropensci-review-bot check package`.
 
+Some items in our checklist were inspired by the [Mozilla code review guide](https://mozillascience.github.io/codeReview/review.html).
+
 ### Off-thread interactions {#off-thread-interactions}
 
 If you interact with the package authors and talked about the review outside a review thread (in chats, DMs, in-person, issues in the project repository), please make sure that your review captures and/or links to elements from these conversations that are relevant to the process.

softwarereview_reviewer.es.Rmd

@@ -38,8 +38,9 @@ Para revisar un paquete, empieza por copiar nuestra [plantilla de revisión](#re
 
 - ¿Cumple el código con los principios generales de la [Guía de revisión de Mozilla](https://mozillascience.github.io/codeReview/review.html)?
 - ¿Cumple el paquete con la [guía de empaquetado de rOpenSci](#building)?
-- ¿Puede mejorarse el estilo del código?
+- ¿Pueden mejorarse el estilo y los patrones del código? Por ejemplo, ¿es necesario dividir las funciones en funciones auxiliares más pequeñas y está claro el papel de cada función auxiliar?
 - ¿Puede reducirse el código duplicado, de haberlo?
+- ¿Existen funciones en R base o en dependencias ligeras que proporcionen la misma interfaz que algunas funciones auxiliares del paquete?
 - ¿Podría mejorarse la interfaz de usuario?
 - ¿Podría mejorarse el rendimiento?
 - ¿La documentación (instrucciones de instalación, viñetas, ejemplos, demos) es clara y suficiente? ¿Utiliza el principio de *múltiples puntos de entrada*? Es decir, ¿tiene en cuenta que cualquier parte de la documentación puede ser la primera exposición de una persona con el paquete y/o la herramienta o datos que utiliza?
@@ -59,7 +60,9 @@ Te recomendamos usar herramientas automatizadas para facilitar tu revisión. És
 
 Puedes volver a correr la comprobación del paquete de `@ropensci-review-bot` en cualquier momento enviando un comentario en el *issue* de revisión con el contenido "`@ropensci-review-bot check package`".
 
-### Interacciones fuera del hilo {#off-thread-interactions}
+Algunos elementos de nuestra lista de verificación se inspiran en la [guía de revisión de código de Mozilla](https://mozillascience.github.io/codeReview/review.html).
+
+### Interacciones fuera del hilo en el _issue_ {#off-thread-interactions}
 
 Si interactúas con quienes desarrollaron el paquete y hablas de la revisión fuera de un *issue* de revisión (en chats, DMs, en persona, issues en el repositorio del proyecto), asegúrate de que tu revisión refleje y/o enlace los elementos de estas conversaciones que sean relevantes para el proceso.
 

softwarereview_reviewer.pt.Rmd

@@ -37,10 +37,10 @@ Todos os envios criam um relatório detalhado, gerado pelo nosso pacote [`pkgche
 
 Para revisar um pacote, comece copiando o nosso [modelo de revisão](#reviewtemplate) (ou o nosso [modelo de revisão em espanhol](#reviewtemplatees)) e use ele como uma lista de verificações que precisam ser feitas.  Além de marcar os critérios mínimos, pedimos que você forneça comentários gerais abordando o seguinte:
 
-- O código está em conformidade com os princípios gerais do [Guia de revisão da Mozilla](https://mozillascience.github.io/codeReview/review.html)?
 - O pacote está de acordo com os requisitos do [Guia de pacotes da rOpenSci](#building)?
-- Há melhorias que poderiam ser feitas no estilo do código?
+- Há melhorias que poderiam ser feitas no estilo e nos padrões de código? Por exemplo, as funções precisam ser divididas em funções auxiliares menores e o papel de cada função auxiliar está claro?
 - Há duplicação de código no pacote que deveria ser reduzida?
+- Existem funções no R básico ou na dependência leve que fornecem a mesma interface que algumas funções auxiliares no pacote?
 - Há melhorias na interface do usuário que poderiam ser feitas?
 - Existem melhorias de desempenho que podem ser feitas?
 - A documentação (instruções de instalação, *vignettes*, exemplos e demonstrações) é clara e suficiente? O princípio de *vários pontos de entrada* está sendo usado? Ou seja, a documentação leva em conta o fato de que qualquer parte da documentação pode ser o primeiro encontro do usuário com o pacote e/ou com as ferramentas e os dados que ele contém?
@@ -59,6 +59,8 @@ Incentivamos você a usar ferramentas automatizadas para facilitar a revisão. I
 
 Os(as) revisores(as) também podem gerar novamente os resultados da verificação de pacotes a partir de `@ropensci-review-bot` a qualquer momento, emitindo um único comentário em um *issue* de revisão: `@ropensci-review-bot check package`.
 
+Alguns elementos de nossa lista de verificação são inspirados no [guia de revisão de código da Mozilla] (https://mozillascience.github.io/codeReview/review.html).
+
 ### Interações feitas fora dos canais oficiais {#off-thread-interactions}
 
 Se você interagiu com os(as) autores(as) do pacote e falou sobre a revisão fora de um tópico de revisão (como em _chats_, mensagens diretas, pessoalmente ou *issues* no repositório do projeto), certifique-se de que sua revisão capture e/ou referencie elementos dessas conversas que sejam relevantes para o processo.