Add section on challenges (non-responding reviewers) (#955)

* Add section on challenges (non-responding reviewers)

Also move text on non-responding authors to this section

* Add DeepL ES and PT translations

* Update softwarereview_editor.Rmd

Co-authored-by: Maëlle Salmon <[email protected]>

* Update softwarereview_editor.Rmd

Co-authored-by: Maëlle Salmon <[email protected]>

* Update softwarereview_editor.Rmd

* Update translations

* Apply suggestions from code review

Co-authored-by: Yanina Bellini Saibene <[email protected]>
Co-authored-by: Beatriz Milz <[email protected]>

* add news item

---------

Co-authored-by: Maëlle Salmon <[email protected]>
Co-authored-by: Yanina Bellini Saibene <[email protected]>
Co-authored-by: Beatriz Milz <[email protected]>

Author: 4 people

booknews.Rmd

@@ -2,6 +2,8 @@
 
 ## dev version
 
+- 2025-09-23, Add section on challenges (non-responding reviewers). Also move text on non-responding authors to this section. (#955).
+
 - 2025-07-11, document better when the pkgdown websites of rOpenSci packages are re-built (#919).
 
 - 2025-07-11, add minimal mention of example datasets (#868).

softwarereview_editor.Rmd

@@ -105,10 +105,18 @@ Each submission should be reviewed by *two* package reviewers. Although it is fi
 - Upon each review being submitted,
   - Write a comment thanking the reviewer in your own words.
   - Record the review via typing a new comment `@ropensci-review-bot submit review <review-url> time <time in hours>`. E.g. for the review [https://github.com/ropensci/software-review/issues/329#issuecomment-809783937](https://github.com/ropensci/software-review/issues/329#issuecomment-809783937) the comment would be `@ropensci-review-bot submit review https://github.com/ropensci/software-review/issues/329#issuecomment-809783937 time 4`.
-- 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, thank them once again for their work, and make a note in our database to assign them to a submission with high chances of smooth software review next time (e.g. a package author who has already submitted packages to us).
 - Upon changes being made, change the review status tag to `5/awaiting-reviewer-response`, and request that reviewers indicate approval with the [reviewer approval template](#approval2template).
 - If the authors intend to submit an accompanying [Applications](https://besjournals.onlinelibrary.wiley.com/hub/journal/2041210X/features/applicationpapers) manuscript at [Methods in Ecology and Evolution](https://besjournals.onlinelibrary.wiley.com/journal/2041210X), indicate to the authors can submit their manuscript after the review has been completed. 
 
+#### Challenges during review {#challenges-during-review}
+
+-   **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 (e.g. a package author who has already submitted packages to us).
+-   **If a reviewer is late with review or stops responding**, send a reminder after 1 week, and again after 2 weeks. The first reminding can be a `@tag` on GitHub. After that use email or other direct communication. If after 3 weeks there is still no response, determine how best to move ahead without them:
+    -   If the reviewer has already submitted their primary review, and another reviewer is active and providing substantial feedback, the editor can proceed with the review process, and should take the role of the absent reviewer in determining if the authors' changes are sufficient.
+    -   If the absent reviewer has not submitted their review, the editor should try to find a new reviewer, and proceed with the review process once two reviews are in. At this point, the editor should prioritize finding experienced reviewers who can commit to a quick turnaround. Be sure to ping other editors on Slack.
+        - At their discretion, the editor _may_ opt to act as the second reviewer themselves, but should only do so after multiple failed attempts to find a new reviewer, and if the editor has sufficient expertise to do so. We discourage editors from doing this with any frequency, as it increases workload and reduces the diversity of views brought into the community by reviewers.
+        - Make a comment thanking the original reviewer in any case, and remove them with `@ropensci-review-bot remove @username from reviewers`.
+
 ### After review: {#after-review}
 
 - `@ropensci-review-bot approve <package-name>`

softwarereview_editor.es.Rmd

@@ -105,10 +105,17 @@ En general, al menos una debe tener experiencia previa en revisiones y, por supu
 - Una vez enviada cada revisión,
   - Escribe un comentario agradeciendo a quien hizo la revisión con tus palabras;
   - Registra la reseña escribiendo un nuevo comentario `@ropensci-review-bot submit review <review-url> time <time in hours>`. Por ejemplo, para la reseña [https://github.com/ropensci/software-review/issues/329#issuecomment-809783937](https://github.com/ropensci/software-review/issues/329#issuecomment-809783937) el comentario sería `@ropensci-review-bot submit review https://github.com/ropensci/software-review/issues/329#issuecomment-809783937 time 4`.
-- Si quien presentó el paquete deja de responder, consulta [las políticas](#policies) y/o notifica al resto del equipo editorial en el canal Slack para discutirlo. Es importante que, si se asignó una persona para hacer la revisión a un issue que se cerró, te pongas en contacto con esa persona al cerrar el issue para explicarle la decisión, agradecerle una vez más su trabajo y tomar nota en nuestra base de datos para asignarle la próxima vez un envío con altas posibilidades de que la revisión del software se realice sin problemas (por ejemplo, una persona que ya nos haya enviado paquetes).
 - Una vez realizados los cambios, cambia la etiqueta de estado de revisión a `5/awaiting-reviewer-response` y pide a las personas a cargo de la revisión que indiquen su aprobación con la \[plantilla de aprobación de revisión\]{#approval2template}.
 - Si quién presentó el paquete tiene la intención de presentar un [artículo científico](https://besjournals.onlinelibrary.wiley.com/hub/journal/2041210X/features/applicationpapers) en [Methods in Ecology and Evolution](https://besjournals.onlinelibrary.wiley.com/journal/2041210X), indicale que pueden presentarlo una vez finalizada la revisión. 
 
+#### Desafíos durante la revisión {#challenges-during-review}
+
+- **Si quien presentó el paquete deja de responder**, consulta [las políticas](#policies) y/o notifica al resto del equipo editorial en el canal Slack para discutirlo. Es importante que, si se asignó una persona para hacer la revisión a un issue que se cerró, te pongas en contacto con esa persona al cerrar el issue para explicarle la decisión, agradecerle una vez más su trabajo. Informa al equipo editorial en el canal de Slack para asignarle la próxima vez un envío con altas posibilidades de que la revisión del software se realice sin problemas (por ejemplo, una persona que ya nos haya enviado paquetes).
+- **Si una persona que está revisando se retrasa en la revisión o deja de responder** envía un recordatorio al cabo de 1 semana, y de nuevo al cabo de 2 semanas. El primer recordatorio puede ser un `@tag` en GitHub. Después utiliza el correo electrónico u otro tipo de comunicación directa. Si al cabo de 3 semanas sigue sin haber respuesta, determina cuál es la mejor manera de seguir adelante sin esa persona:
+  - Si una persona ya ha enviado su revisión principal y la otra persona revisora está activa y proporcionando comentarios sustanciales, el/la editor/a puede seguir adelante con el proceso de revisión y debe asumir la tarea de revisión complementaria para determinar si los cambios realizados por los y las autoras son suficientes.
+  - Si la persona revisora ausente no ha enviado su revisión, la persona responsable de la edición debe intentar encontrar una nueva persona para realizar la revisión y proceder con el proceso de revisión una vez que haya dos revisiones. En este punto, el/la editor/a debe dar prioridad a la búsqueda de revisores/as con experiencia que puedan comprometerse a una entrega rápida. Asegúrate de hacer ping al equipo editorial en Slack.
+    - A su discreción, la persona editora *puede* optar por actuar como segunda persona revisora, pero sólo debe hacerlo tras múltiples intentos fallidos de encontrar una nueva persona revisora, y si la persona editora tiene experiencia suficiente para hacerlo. Desaconsejamos al equipo editor que hagan esto con frecuencia, ya que aumenta la carga de trabajo y reduce la diversidad de puntos de vista aportados a la comunidad por las personas que revisa.
+    - Haz un comentario de agradecimiento a la persona revisora original en cualquier caso y elimínala de la revisión con `@ropensci-review-bot remove @username from reviewers`.
 
 ### Después de la revisión: {#after-review}
 

softwarereview_editor.pt.Rmd

@@ -101,10 +101,18 @@ Cada submissão deve ser revisada por *dois* revisores de pacotes. Embora seja a
 - Após o envio de cada revisão,
   - Escreva um comentário agradecendo ao revisor;
   - Registre a revisão digitando um novo comentário `@ropensci-review-bot submit review <review-url> time <time in hours>`. Por exemplo, para a revisão [https://github.com/ropensci/software-review/issues/329#issuecomment-809783937](https://github.com/ropensci/software-review/issues/329#issuecomment-809783937) o comentário seria `@ropensci-review-bot submit review https://github.com/ropensci/software-review/issues/329#issuecomment-809783937 time 4`.
-- Se o autor deixar de responder, consulte [as políticas de uso](#policies) e/ou envie um _ping_ para os outros editores no canal de discussão do Slack. É importante ressaltar que, se um revisor tiver sido atribuído a um _issue_ fechado, entre em contato com ele ao fechar o _issue_ para explicar a decisão, agradeça-o mais uma vez por seu trabalho e faça uma anotação em nosso banco de dados para atribuí-lo a uma submissão com grandes chances de um processo de revisão de software mais tranquilo da próxima vez (por exemplo, de um autor de pacote que já tenha enviado pacotes para nós anteriormente).
 - Quando as alterações forem feitas, altere a _tag_ de status da revisão para `5/awaiting-reviewer-response` e solicite que os revisores indiquem a aprovação usando o [modelo de aprovação do revisor](#approval2template).
 - Se as pessoas autoras tiverem a intenção de enviar um manuscrito de acompanhamento do tipo [*Applications*](https://besjournals.onlinelibrary.wiley.com/hub/journal/2041210X/features/applicationpapers) no periódico [Methods in Ecology and Evolution](https://besjournals.onlinelibrary.wiley.com/journal/2041210X), indique que o envio do manuscrito pode ser feito após a conclusão da revisão. 
 
+#### Desafios durante a revisão {#challenges-during-review}
+
+- **Se o(a) autor(a) parar de responder** consulte [as políticas](#policies) e/ou envie uma mensagem para a equipe de editores(as) no canal do Slack para discussão. É importante ressaltar que, se uma pessoa for atribuída como revisora a uma Issue fechada, entre em contato com ela ao fechar a Issue para explicar a decisão e agradeça mais uma vez pelo trabalho.  Informe as outras pessoas editoras no canal Slack para que elas (revisoras) sejam consideradas para um pacote no futuro, com grandes chances de uma revisão de software tranquila (por exemplo, um(a) autor(a) de pacote que já tenha enviado pacotes para nós).
+- **Se um(a) revisor(a) estiver atrasado(a) na revisão ou parar de responder** envie um lembrete após uma semana e novamente após duas semanas. O primeiro lembrete pode ser um `@tag` no GitHub. Depois disso, use o e-mail ou outra forma de comunicação direta. Se depois de três semanas você ainda não tiver recebido resposta, determine a melhor maneira de seguir em frente sem o(a) revisor(a):
+  - Se o(a) revisor(a) já tiver enviado sua primeira revisão e outro(a) revisor(a) estiver ativo(a) e fornecendo feedback substancial, o(a) editor(a) poderá prosseguir com o processo de revisão e deverá assumir a função do(a) revisor(a) ausente para determinar se as alterações dos(as) autores(as) são suficientes.
+  - Se o(a) revisor(a) ausente não tiver enviado sua revisão, o(a) editor(a) deve tentar encontrar uma nova pessoa revisora e prosseguir com o processo de revisão assim que duas revisões forem recebidas. Nesse ponto, o(a) editor(a) deve priorizar a busca de revisores(as) experientes que possam se comprometer com uma resposta rápida. Não se esqueça de enviar mensagens para outros(as) editores(as) no Slack.
+    - A seu critério, o(a) editor(a) *pode* optar por atuar como segundo(a) revisor(a), mas só deve fazê-lo após várias tentativas fracassadas de encontrar um(a) novo(a) revisor(a) e se o(a) editor(a) tiver experiência suficiente para isso. Não recomendamos que os(as) editores façam isso com frequência, pois isso aumenta a carga de trabalho e reduz a diversidade de pontos de vista trazidos à comunidade pelos(as) revisores(as).
+    - Em qualquer caso, faça um comentário agradecendo ao revisor(a) original e remova-o(a) com `@ropensci-review-bot remove @username from reviewers`.
+
 ### Após a revisão: {#after-review}
 
 - `@ropensci-review-bot approve <package-name>`.