From 115b687e8cce6bffeb854aa0617eaf79795ac371 Mon Sep 17 00:00:00 2001
From: Noam Ross <noam.ross@gmail.com>
Date: Mon, 8 Sep 2025 16:19:26 -0400
Subject: [PATCH 1/6] Add section on challenges (non-responding reviewers)

Also move text on non-responding authors to this section
---
 softwarereview_editor.Rmd | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/softwarereview_editor.Rmd b/softwarereview_editor.Rmd
index ee4c04889..62ac012d0 100644
--- a/softwarereview_editor.Rmd
+++ b/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, 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).
+-   **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 sufficent 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>`

From 9fda79ba04a1f0d633b8539906f3d5cf68511da8 Mon Sep 17 00:00:00 2001
From: Noam Ross <noam.ross@gmail.com>
Date: Mon, 8 Sep 2025 16:39:48 -0400
Subject: [PATCH 2/6] Add DeepL ES and PT translations

---
 softwarereview_editor.es.Rmd |  9 ++++++++-
 softwarereview_editor.pt.Rmd | 10 +++++++++-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/softwarereview_editor.es.Rmd b/softwarereview_editor.es.Rmd
index f68cc7820..476c3bde1 100644
--- a/softwarereview_editor.es.Rmd
+++ b/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. 
 
+#### Retos durante la revisión {#challenges-during-review}
+
+- **Si el autor deja de responder** remítete a [las políticas](#policies) y/o ponte en contacto con los demás editores en el canal Slack para debatir. Es importante que, si se asignó un revisor a un tema cerrado, te pongas en contacto con él al cerrar el tema 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 a un envío con altas posibilidades de que la revisión del software se realice sin problemas (por ejemplo, un autor de paquetes que ya nos haya enviado paquetes).
+- **Si un revisor 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 ellos.
+  - Si el revisor ya ha enviado su revisión principal, y otro revisor está activo y proporcionando comentarios sustanciales, el editor puede seguir adelante con el proceso de revisión, y debe asumir el papel del revisor ausente para determinar si los cambios de los autores son suficientes.
+  - Si el revisor ausente no ha enviado su revisión, el editor debe intentar encontrar un nuevo revisor, y proceder con el proceso de revisión una vez que haya dos revisiones. En este punto, el editor debe dar prioridad a la búsqueda de revisores experimentados que puedan comprometerse a una entrega rápida. Asegúrate de hacer ping a otros editores en Slack.
+    - A su discreción, el editor *puede* optar por actuar él mismo como segundo revisor, pero sólo debe hacerlo tras múltiples intentos fallidos de encontrar un nuevo revisor, y si el editor tiene experiencia suficiente para hacerlo. Desaconsejamos a los editores 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 los revisores.
+    - Haz un comentario de agradecimiento al revisor original en cualquier caso, y elimínalo con `@ropensci-review-bot remove @username from reviewers`.
 
 ### Después de la revisión: {#after-review}
 
diff --git a/softwarereview_editor.pt.Rmd b/softwarereview_editor.pt.Rmd
index 481b53d9b..d8bc74c40 100644
--- a/softwarereview_editor.pt.Rmd
+++ b/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 autor parar de responder** consulte [as políticas](#policies) e/ou envie um ping para os outros editores no canal do Slack para discussão. É importante ressaltar que, se um revisor tiver sido atribuído a um problema fechado, entre em contato com ele ao fechar o problema para explicar a decisão, agradeça-o mais uma vez pelo trabalho e faça uma anotação em nosso banco de dados para atribuí-lo a uma submissão com grandes chances de uma revisão de software tranquila da próxima vez (por exemplo, um autor de pacote que já tenha enviado pacotes para nós).
+- **Se um revisor estiver atrasado 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 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 eles.
+  - Se o revisor já tiver enviado sua revisão primária e outro revisor estiver ativo e fornecendo feedback substancial, o editor poderá prosseguir com o processo de revisão e deverá assumir a função do revisor ausente para determinar se as alterações dos autores são suficientes.
+  - Se o revisor ausente não tiver enviado sua revisão, o editor deve tentar encontrar um novo revisor e prosseguir com o processo de revisão assim que duas revisões forem recebidas. Nesse ponto, o editor deve priorizar a busca de revisores experientes que possam se comprometer com uma resposta rápida. Não se esqueça de enviar mensagens para outros editores no Slack.
+    - A seu critério, o editor *pode* optar por atuar como segundo revisor, mas só deve fazê-lo depois de várias tentativas fracassadas de encontrar um novo revisor e se o editor tiver experiência suficiente para isso. Não recomendamos que os 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 revisores.
+    - Em qualquer caso, faça um comentário agradecendo ao revisor original e remova-o com `@ropensci-review-bot remove @username from reviewers`.
+
 ### Após a revisão: {#after-review}
 
 - `@ropensci-review-bot approve <package-name>`.

From 563ae99166b3d245ef1a6ab68d9316f32063b3e8 Mon Sep 17 00:00:00 2001
From: Noam Ross <noam.ross@gmail.com>
Date: Tue, 9 Sep 2025 18:38:19 -0400
Subject: [PATCH 3/6] Update softwarereview_editor.Rmd
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Maëlle Salmon <maelle.salmon@yahoo.se>
---
 softwarereview_editor.Rmd | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/softwarereview_editor.Rmd b/softwarereview_editor.Rmd
index 62ac012d0..dfbfde279 100644
--- a/softwarereview_editor.Rmd
+++ b/softwarereview_editor.Rmd
@@ -111,7 +111,7 @@ Each submission should be reviewed by *two* package reviewers. Although it is fi
 #### 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, 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).
--   **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 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 sufficent 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.

From fee1939d306d24f538d8d3cf09c2aa123ee91b22 Mon Sep 17 00:00:00 2001
From: Noam Ross <noam.ross@gmail.com>
Date: Tue, 9 Sep 2025 18:38:29 -0400
Subject: [PATCH 4/6] Update softwarereview_editor.Rmd
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Maëlle Salmon <maelle.salmon@yahoo.se>
---
 softwarereview_editor.Rmd | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/softwarereview_editor.Rmd b/softwarereview_editor.Rmd
index dfbfde279..418a4661e 100644
--- a/softwarereview_editor.Rmd
+++ b/softwarereview_editor.Rmd
@@ -114,7 +114,7 @@ Each submission should be reviewed by *two* package reviewers. Although it is fi
 -   **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 sufficent 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.
+        - 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}

From 13b935c9f50af930587f93e349c6007ab182e334 Mon Sep 17 00:00:00 2001
From: Noam Ross <noam.ross@gmail.com>
Date: Tue, 9 Sep 2025 18:44:21 -0400
Subject: [PATCH 5/6] Update softwarereview_editor.Rmd

---
 softwarereview_editor.Rmd | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/softwarereview_editor.Rmd b/softwarereview_editor.Rmd
index 418a4661e..f8f81cb60 100644
--- a/softwarereview_editor.Rmd
+++ b/softwarereview_editor.Rmd
@@ -110,7 +110,7 @@ Each submission should be reviewed by *two* package reviewers. Although it is fi
 
 #### 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, 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).
+-   **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.

From ea07fc36c4887c2f1bf7f5d25ab7aec2cebd28db Mon Sep 17 00:00:00 2001
From: Noam Ross <noam.ross@gmail.com>
Date: Tue, 9 Sep 2025 18:49:17 -0400
Subject: [PATCH 6/6] Update translations

---
 softwarereview_editor.es.Rmd | 6 +++---
 softwarereview_editor.pt.Rmd | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/softwarereview_editor.es.Rmd b/softwarereview_editor.es.Rmd
index 476c3bde1..45a315c05 100644
--- a/softwarereview_editor.es.Rmd
+++ b/softwarereview_editor.es.Rmd
@@ -108,10 +108,10 @@ En general, al menos una debe tener experiencia previa en revisiones y, por supu
 - 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. 
 
-#### Retos durante la revisión {#challenges-during-review}
+#### Desafíos durante la revisión {#challenges-during-review}
 
-- **Si el autor deja de responder** remítete a [las políticas](#policies) y/o ponte en contacto con los demás editores en el canal Slack para debatir. Es importante que, si se asignó un revisor a un tema cerrado, te pongas en contacto con él al cerrar el tema 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 a un envío con altas posibilidades de que la revisión del software se realice sin problemas (por ejemplo, un autor de paquetes que ya nos haya enviado paquetes).
-- **Si un revisor 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 ellos.
+- **Si el autor deja de responder** remítete a [las políticas](#policies) y/o ponte en contacto con los demás editores en el canal Slack para debatir. Es importante que, si se asignó un revisor a una cuestión cerrada, te pongas en contacto con él al cerrar la cuestión para explicarle la decisión y agradecerle de nuevo su trabajo.  Informa a los demás editores en el canal de Slack para que les tengan en cuenta para un paquete en el futuro con altas posibilidades de revisión de software sin problemas (por ejemplo, un autor de paquetes que ya nos haya enviado paquetes).
+- **Si un revisor 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 ellos:
   - Si el revisor ya ha enviado su revisión principal, y otro revisor está activo y proporcionando comentarios sustanciales, el editor puede seguir adelante con el proceso de revisión, y debe asumir el papel del revisor ausente para determinar si los cambios de los autores son suficientes.
   - Si el revisor ausente no ha enviado su revisión, el editor debe intentar encontrar un nuevo revisor, y proceder con el proceso de revisión una vez que haya dos revisiones. En este punto, el editor debe dar prioridad a la búsqueda de revisores experimentados que puedan comprometerse a una entrega rápida. Asegúrate de hacer ping a otros editores en Slack.
     - A su discreción, el editor *puede* optar por actuar él mismo como segundo revisor, pero sólo debe hacerlo tras múltiples intentos fallidos de encontrar un nuevo revisor, y si el editor tiene experiencia suficiente para hacerlo. Desaconsejamos a los editores 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 los revisores.
diff --git a/softwarereview_editor.pt.Rmd b/softwarereview_editor.pt.Rmd
index d8bc74c40..00b799a0e 100644
--- a/softwarereview_editor.pt.Rmd
+++ b/softwarereview_editor.pt.Rmd
@@ -106,11 +106,11 @@ Cada submissão deve ser revisada por *dois* revisores de pacotes. Embora seja a
 
 #### Desafios durante a revisão {#challenges-during-review}
 
-- **Se o autor parar de responder** consulte [as políticas](#policies) e/ou envie um ping para os outros editores no canal do Slack para discussão. É importante ressaltar que, se um revisor tiver sido atribuído a um problema fechado, entre em contato com ele ao fechar o problema para explicar a decisão, agradeça-o mais uma vez pelo trabalho e faça uma anotação em nosso banco de dados para atribuí-lo a uma submissão com grandes chances de uma revisão de software tranquila da próxima vez (por exemplo, um autor de pacote que já tenha enviado pacotes para nós).
-- **Se um revisor estiver atrasado 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 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 eles.
+- **Se o autor parar de responder** consulte [as políticas](#policies) e/ou envie um ping para os outros editores no canal do Slack para discussão. É importante ressaltar que, se um revisor foi atribuído a um problema fechado, entre em contato com ele ao fechar o problema para explicar a decisão e agradecê-lo mais uma vez pelo trabalho.  Informe os outros editores no canal Slack para que eles sejam considerados para um pacote no futuro com grandes chances de uma revisão de software tranquila (por exemplo, um autor de pacote que já tenha enviado pacotes para nós).
+- **Se um revisor estiver atrasado 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 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 eles:
   - Se o revisor já tiver enviado sua revisão primária e outro revisor estiver ativo e fornecendo feedback substancial, o editor poderá prosseguir com o processo de revisão e deverá assumir a função do revisor ausente para determinar se as alterações dos autores são suficientes.
   - Se o revisor ausente não tiver enviado sua revisão, o editor deve tentar encontrar um novo revisor e prosseguir com o processo de revisão assim que duas revisões forem recebidas. Nesse ponto, o editor deve priorizar a busca de revisores experientes que possam se comprometer com uma resposta rápida. Não se esqueça de enviar mensagens para outros editores no Slack.
-    - A seu critério, o editor *pode* optar por atuar como segundo revisor, mas só deve fazê-lo depois de várias tentativas fracassadas de encontrar um novo revisor e se o editor tiver experiência suficiente para isso. Não recomendamos que os 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 revisores.
+    - A seu critério, o editor *pode* optar por atuar como segundo revisor, mas só deve fazê-lo após várias tentativas fracassadas de encontrar um novo revisor e se o editor tiver experiência suficiente para isso. Não recomendamos que os 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 revisores.
     - Em qualquer caso, faça um comentário agradecendo ao revisor original e remova-o com `@ropensci-review-bot remove @username from reviewers`.
 
 ### Após a revisão: {#after-review}