From d2997dcf34fbf70677a9b6c70db7d8bccb9e2493 Mon Sep 17 00:00:00 2001 From: Yanina Date: Wed, 13 Mar 2024 13:25:03 -0300 Subject: [PATCH] Add PT-BR automatic translation softwarereview_editor.pt.Rmd --- softwarereview_editor.pt.Rmd | 268 +++++++++++++++++++++++++++++++++++ 1 file changed, 268 insertions(+) create mode 100644 softwarereview_editor.pt.Rmd diff --git a/softwarereview_editor.pt.Rmd b/softwarereview_editor.pt.Rmd new file mode 100644 index 000000000..741bdbbb2 --- /dev/null +++ b/softwarereview_editor.pt.Rmd @@ -0,0 +1,268 @@ +--- +aliases: editorguide.html +--- + +# Guia para editores {#editorguide} + +```{block, type="summaryblock"} +A revisão por pares de software na rOpenSci é gerenciada por uma equipe de editores. Estamos testando +um sistema rotativo de Editor-chefe (EiC). + +Este capítulo apresenta as responsabilidades [do Editor-chefe] (#eicchecklist), de [qualquer editor responsável por uma submissão] (#editorchecklist), [como responder a uma submissão fora do escopo] (#outofscoperesponse) e [como gerenciar o lançamento de um guia de desenvolvimento] (#bookrelease). + +Se você for um editor convidado, obrigado por ajudar! Entre em contato com o editor que o convidou para lidar com um envio para esclarecer qualquer dúvida que você possa ter. +``` + +> Sempre presuma que os participantes do sistema de revisão de software (colegas editores, remetentes, revisores) estão fazendo o melhor que podem e comunique-se com elegância, especialmente ao perguntar por que algo está atrasado. + +## Responsabilidades dos editores {#editors-responsibilities} + +- Além de lidar com os pacotes (cerca de 4 por ano), os editores participam das decisões editoriais do grupo, como, por exemplo, se um pacote está dentro do escopo e determinar atualizações em nossas políticas. Geralmente, fazemos isso por meio do Slack, que esperamos que os editores possam verificar regularmente. + +- Também fazemos um rodízio de [Responsabilidades do editor-chefe](#eicchecklist) (decisões de escopo de primeira passagem e designação de editores) entre a diretoria trimestralmente. + +- Você não precisa acompanhar outros envios, mas se notar um problema com um pacote que está sendo tratado por outro editor, sinta-se à vontade para levantar esse problema diretamente com o outro editor ou publicar a preocupação no canal somente para editores no Slack. Exemplos: + + - Você sabe de um pacote sobreposto que ainda não foi mencionado no processo. + - Você vê uma pergunta para a qual tem uma resposta especializada que não foi dada depois de alguns dias (por exemplo, você sabe de uma publicação no blog que aborda como adicionar imagens aos documentos do pacote). + - Preocupações relacionadas, por exemplo, à velocidade do processo devem ser tratadas pelo editor-chefe, portanto, é a ele que você recorreria para essas perguntas. + +## Como lidar com a lista de verificação do editor {#editorchecklist} + +### No momento do envio: {#upon-submission} + +- Se você for o EiC ou o primeiro editor a responder, designe um editor com um comentário de `@ropensci-review-bot assign @username as editor`. Isso também adicionará a tag `1/editor-checks` à edição. +- Para envios estatísticos (identificáveis como "Tipo de envio: Estatísticas" no modelo da edição), adicione o rótulo "stats" à edição. +- O envio gerará automaticamente a saída de verificação de pacote do ropensci-review-bot, que deve ser examinada para verificar se há problemas pendentes (a maioria das exceções precisará ser justificada pelo autor no contexto específico de seu pacote). Se você quiser executar novamente as verificações após qualquer alteração no pacote, poste um comentário `@ropensci-review-bot check package`. +- O sistema de verificação é reconstruído toda terça-feira, às 00:01 UTC, e pode levar algumas horas. Se as verificações automáticas falharem nesse horário, aguarde algumas horas e tente novamente. +- Depois que as verificações automáticas forem lançadas, use o comando [modelo de editor](#editortemplate) para orientar as verificações iniciais e registrar sua resposta ao envio. Você também pode simplificar as verificações do editor usando a função [`pkgreviewr` pacote criado pela editora associada Anna Krystalli](https://docs.ropensci.org/pkgreviewr/articles/editors.html). Esforce-se para concluir as verificações e começar a procurar revisores dentro de 5 dias úteis. +- Verifique se o modelo foi preenchido corretamente. +- Verifique as políticas para [ajuste](#aims-and-scope) e [sobreposição](#overlap). + Inicie a discussão por meio do canal #software-review do Slack, se necessário, para casos extremos que não tenham sido detectados por verificações anteriores da EiC. + Se você rejeitar, consulte [esta seção](#outofscoperesponse) sobre como responder. +- Verifique se as partes obrigatórias do modelo estão completas. Caso contrário, direcione os autores para as instruções apropriadas. +- Para pacotes que precisam de integração contínua em várias plataformas (cf [critérios nesta seção do capítulo sobre CI](#whichci)), certifique-se de que o pacote seja testado em várias plataformas (tendo o pacote criado em vários sistemas operacionais por meio do GitHub Actions, por exemplo). +- Sempre que possível, ao solicitar alterações, direcione os autores para ferramentas automáticas, como [`usethis`](https://usethis.r-lib.org/) e [`styler`](https://styler.r-lib.org/) e para recursos on-line (seções deste guia, seções do [livro de pacotes do R](https://r-pkgs.org/)) para facilitar o uso de seus comentários. [Exemplo de verificações do editor](https://github.com/ropensci/software-review/issues/207#issuecomment-379909739). +- O ideal é que as observações que você fizer sejam resolvidas antes que os revisores comecem a revisar. +- Se as verificações iniciais mostrarem grandes lacunas, solicite alterações antes de designar os revisores. Se o autor mencionar que as alterações podem levar tempo, [aplique o rótulo de retenção digitando `@ropensci-review-bot put on hold`](#policiesreviewprocess). Você receberá um lembrete a cada 90 dias (na edição) para verificar com o(s) autor(es) do pacote. +- Se o pacote levantar um novo problema para a política do rOpenSci, inicie uma conversa no Slack ou abra uma discussão na seção [fórum do rOpenSci](https://discuss.ropensci.org/) para discuti-lo com outros editores ([exemplo de discussão de política](https://discuss.ropensci.org/t/overlap-policy-for-package-onboarding/368)). + +### Procure e designe dois revisores: {#look-for-and-assign-two-reviewers} + +#### Tarefas {#tasks} + +- Comente com `@ropensci-review-bot seeking reviewers`. +- Use o [modelo de e-mail](#reviewrequesttemplate) se necessário, para convidar os revisores + - Ao convidar os avaliadores, inclua algo como "se eu não tiver notícias suas em uma semana, presumirei que você não poderá avaliar", para dar um prazo claro para que você passe a procurar outra pessoa. +- Designe revisores com `@ropensci-review-bot assign @username as reviewer`. `add` também pode ser usado em vez de `assign`, e `to reviewers` (plural) em vez de `as reviewer` (singular). Portanto, o seguinte também é válido: `@ropensci-review-bot add @username to reviewers`. Um comando deve ser emitido para cada revisor. Se necessário posteriormente, remova os revisores com `@ropensci-review-bot remove @username from reviewers`. +- Se você quiser alterar a data de vencimento de uma revisão, use `@ropensci-review-bot set due date for @username to YYYY-MM-DD`. + +#### Como procurar revisores {#how-to-look-for-reviewers} + +##### Onde procurar revisores? {#where-to-look-for-reviewers} + +Como editor (convidado), use + +- as possíveis sugestões feitas pelo(s) remetente(s), (embora os remetentes possam ter uma visão limitada dos tipos de especialização necessários. Sugerimos que você não use mais de um dos revisores sugeridos); +- o banco de dados Airtable de revisores e voluntários (consulte a próxima subseção); +- e os autores de [pacotes rOpenSci](https://ropensci.org/packages/). + +Quando essas fontes de informação não forem suficientes, você poderá usar os pacotes rOpenSci, + +- peça ideias a outros editores no Slack, +- procure usuários do pacote ou da fonte de dados/serviço de upstream ao qual o pacote se conecta (por meio da abertura de problemas no repositório, marcando-o com uma estrela, citando-o em artigos, falando sobre ele no Twitter). +- Você também pode procurar por autores de pacotes relacionados em [r-pkg.org](https://r-pkg.org/). +- R-Ladies tem um [diretório](https://rladies.org/directory/) especificando as habilidades e os interesses das pessoas listadas. +- Você pode publicar uma solicitação de revisores nos canais #general e/ou #software-review no Slack do rOpenSci ou nas mídias sociais. + +##### Dicas para a pesquisa de revisores no Airtable {#tips-for-reviewer-search-in-airtable} + +Você pode usar filtros, classificação e pesquisa para identificar avaliadores com experiência específica: + +![Captura de tela da interface de filtros do Airtable com um filtro de experiência de domínio que deve incluir química e áreas técnicas que devem incluir integração contínua](images/airtable.png) + +Verifique a avaliação mais recente do avaliador e evite qualquer pessoa que tenha avaliado alguém nos últimos seis meses. +Além disso, verifique se um avaliador iniciante indicou que `require_mentorship`. +Em caso afirmativo, use a parte de orientação do modelo de e-mail e esteja preparado para fornecer orientações adicionais. + +##### Critérios para escolher um revisor {#criteria-for-choosing-a-reviewer} + +Aqui estão os critérios que você deve ter em mente ao escolher um revisor. Talvez você precise reunir essas informações pesquisando no CRAN e na página do GitHub do possível revisor e na presença on-line em geral (site pessoal, Twitter). + +- Você não revisou um pacote para nós nos últimos 6 meses. +- Você tem alguma experiência em desenvolvimento de pacotes. +- Alguma experiência de domínio no campo do pacote ou da fonte de dados +- Não [conflitos de interesse](#coi). +- Tente equilibrar sua percepção da experiência do possível revisor com a complexidade do pacote. +- Diversidade - com dois revisores, ambos não devem ser homens brancos cis. +- Alguma evidência de que você está interessado em abertura ou em atividades da comunidade de R, embora não haja problema em enviar e-mails frios. + +Cada envio deve ser revisado por *dois* revisores de pacotes. Embora seja bom que um deles tenha menos experiência em desenvolvimento de pacotes e mais conhecimento do domínio, a revisão não deve ser dividida em dois. Ambos os revisores precisam revisar o pacote de forma abrangente, embora sob suas perspectivas específicas. Em geral, pelo menos um revisor deve ter experiência prévia em revisão e, é claro, convidar um novo revisor amplia nosso grupo de revisores. + +### Durante a revisão: {#during-review} + +- Verifique ocasionalmente com os revisores e autores. Ofereça esclarecimentos e ajuda conforme necessário. +- Em geral, procure enviar 3 semanas para revisão, 2 semanas para + alterações subsequentes e uma semana para a aprovação das alterações pelo revisor. +- Após o envio de cada revisão, + - Escreva um comentário agradecendo ao avaliador com suas palavras; + - Registre a avaliação digitando um novo comentário `@ropensci-review-bot submit review time