softwarereview_author.pt.Rmd

---
aliases: 
  - authors-guide.html
---

# Guia para Autores {#authors-guide}

```{block, type="summaryblock"}
Este guia conciso apresenta o processo de revisão de software por pares, para você como autor de um pacote.
```

## Planejando uma Submissão (ou uma Consulta de Pré-Submissão) {#planning-a-submission-or-a-pre-submission-enquiry}

### 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.
  - [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).

### 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.
- Você pretende manter o seu pacote por pelo menos 2 anos ou ser capaz de identificar uma nova pessoa para mantê-lo?
- Considere o melhor momento de desenvolvimento do seu pacote para enviar sua submissão. Seu pacote deve estar suficientemente maduro para que os revisores possam analisar todos os aspectos essenciais, mas tenha em mente que revisões podem resultar em grandes alterações.
  - Sugerimos enfaticamente que você envie seu pacote para análise *antes de* publicá-lo no CRAN ou antes de enviá-lo para publicação como artigo em um periódico. O _feedback_ da revisão pode resultar em grandes aprimoramentos e atualizações do seu pacote, incluindo renomeações e alterações de funções.
  - Não envie seu pacote para revisão enquanto este ou o manuscrito associado também estiver sendo revisado em outro local, pois isso pode resultar em solicitações conflitantes de alterações.
- Considere também o tempo e o esforço necessários para responder às revisões: pense na sua disponibilidade ou na de seus colaboradores nas próximas semanas e meses após o envio da submissão. Observe que os revisores são voluntários e pedimos que você respeite o tempo e o esforço deles, respondendo de maneira oportuna e respeitosa.
- Se você usa [distintivos do repostatus.org](https://www.repostatus.org/) (o que recomendamos), envie uma submissão quando você estiver pronto para receber um distintivo tipo _Active_ em vez de _WIP_. Da mesma forma, se você usa [distintivos tipo _lifecycle_](https://www.tidyverse.org/lifecycle/) o envio da submissão deverá ocorrer quando o pacote for _Stable_.
- Seu pacote continuará a evoluir após a revisão. O capítulo sobre *Evolução do pacote* [fornece mais orientações sobre este tópico](#evolution).

### Documentação

- Para qualquer envio ou consulta de pré-submissão, o README do seu pacote deve fornecer informações suficientes sobre o pacote (objetivos, uso, pacotes semelhantes) para que os editores avaliem seu escopo sem precisar instalar o pacote. Melhor ainda, crie um website pkgdown para permitir uma avaliação mais detalhada da funcionalidade online.
  - No estágio de envio da submissão, todas as principais funções devem ser estáveis o suficiente para serem totalmente documentadas e testadas; o README deve apresentar uma base segura para o pacote.
  - Seu arquivo README deve assegurar-se em explicar a funcionalidade e os objetivos do seu pacote, presumindo que os leitores tenham pouco ou nenhum conhecimento do domínio. Todos os termos técnicos, inclusive as referências a outros softwares, devem ser esclarecidos.
- Seu pacote continuará a evoluir após a revisão. O capítulo sobre *Evolução do pacote* [fornece mais orientações sobre este tópico](#evolution).

## Preparando para Submissão {#preparing-for-submission}

### Solicitação de ajuda

- Fique à vontade para fazer perguntas sobre o processo ou sobre seu pacote em específico no nosso [Fórum de discussão](https://discuss.ropensci.org).

### Diretrizes

- Leia e siga [nosso guia de estilo de pacotes](#building) e nosso [guia de revisão](#preparereview), para garantir que seu pacote atenda aos nossos critérios de estilo e qualidade.

### Verificações automáticas

- Todas as submissões são verificadas automaticamente pelo nosso [`pkgcheck`](https://docs.ropensci.org/pkgcheck/) para garantir que os pacotes sigam as nossas diretrizes. Espera-se que todas as pessoas autoras tenham executado a [principal função do `pkgcheck`](https://docs.ropensci.org/pkgcheck/reference/pkgcheck.html) localmente para confirmar que o pacote está pronto para ser submetido. Como alternativa, uma maneira ainda mais fácil de garantir que um pacote está pronto para ser submetido é usando [a função `pkgcheck` do GitHub Action](https://github.com/ropensci-review-tools/pkgcheck-action), conforme descrito em [nossa postagem no blog](https://ropensci.org/blog/2022/02/01/pkgcheck-action/).
- Se o seu pacote exigir dependências incomuns de sistema (consulte [*Guia de pacotes*](#pkgdependencies)) para que a _GitHub Action_ seja aprovada, envie um _pull request_ adicionando-as ao [nosso arquivo Dockerfile](https://github.com/ropensci-review-tools/pkgcheck/blob/main/Dockerfile).
  Consulte [esta vinheta `pkgcheck`](https://docs.ropensci.org/pkgcheck/articles/environment.html) para obter detalhes sobre o nosso ambiente de verificação e como modificá-lo para ajudar o seu pacote a passar nas verificações.
- Se houver algum aspecto do `pkgcheck` no qual seu o pacote não possa ser aprovado, explique os motivos no seu modelo de submissão.


### Manuscrito de acompanhamento (opcional)

Se você pretende enviar um manuscrito de acompanhamento para seu o pacote, a rOpenSci tem uma parceria de colaboração com os periódicos [Journal of Open-Source Software] (https://joss.theoj.org/) e [Methods in Ecology and Evolution] (https://besjournals.onlinelibrary.wiley.com/journal/2041210X): 

- Para enviar um pacote ao Journal of Open-Source Software (JOSS), não o envie para consideração do JOSS até que o processo de revisão do rOpenSci tenha terminado: se o seu pacote for considerado dentro do escopo pelos editores do JOSS, apenas o artigo curto que o acompanha será revisado (não o software que terá sido revisado extensivamente pelo rOpenSci até aquele momento). Nem todos os pacotes da rOpenSci atenderão aos critérios do JOSS.
- Para uma submissão ao Methods in Ecology and Evolution (MEE), envie-a ao MEE somente depois que as revisoras e revisores da rOpenSci tiverem enviado suas revisões, antes ou depois de o pacote ter sido aceito. A colaboração de revisão com a MEE foi apresentada em uma [postagem de blog](https://ropensci.org/blog/2017/11/29/review-collaboration-mee/). O tipo de artigo relevante para a MEE é [*Applications*](https://besjournals.onlinelibrary.wiley.com/hub/journal/2041210X/features/applicationpapers) para obter mais detalhes.

## O Processo de Submissão {#the-submission-process}

- Um software é enviado/submetido para revisão através da [abertura de uma nova _issue_](https://github.com/ropensci/software-review/issues/new/choose) no repositório de revisão do software, sendo preenchido o modelo sugerido.
- O modelo sugerido começa com uma seção que inclui diversas variáveis no estilo HTML (`<!---variável--->`). Elas são usadas pelo nosso `ropensci-review-bot` e devem ser deixadas nos seus respectivos lugares, com valores preenchidos entre os pontos de início e fim indicados, assim:

```{bash, eval=F}
<!---variável--->insira valor aqui<!---variável-fim>
```

- A comunicação entre autores, revisores e editores ocorrerá primeiramente no GitHub para que o tópico de revisão possa servir como um registro completo da revisão. Você pode optar por entrar em contato com o editor por e-mail ou Slack se for necessária uma consulta particular (por exemplo, perguntar como responder a uma pergunta de um revisor). Não entre em contato com os revisores fora do tópico (_thread_ do GitHub) sem perguntar a eles de antemão se eles concordam com isso.
- Ao submeter um pacote, certifique-se de que suas notificações do GitHub estão ativadas para que você não perca qualquer comentário relacionado a sua submissão.
- Os pacotes são verificados automaticamente no momento de submissão pelo [nosso `pkgcheck`](https://docs.ropensci.org/pkgcheck), que confirma se um pacote está ou não pronto para ser revisado.
- Os pacotes submetidos podem ser hospedados na ramificação principal/padrão ou em qualquer outra ramificação não padrão. Neste último caso, é recomendável, mas não obrigatório, enviar o pacote por meio de uma ramificação dedicada tipo `ropensci-software-review`.
- Para envios em ramificações (*branches*) que não sejam a padrão, o URL indicado em “Repository” no modelo de envio deve ser o URL completo da ramificação de revisão, como por exemplo: `https://github.com/my/repo/tree/ropensci-software-review`.

## O Processo de Revisão {#the-review-process}

- Um editor [editor](#editors) analisará sua submissão em até 5 dias úteis e responderá com as próximas etapas. O editor poderá atribuir o pacote a revisores, solicitar que o pacote seja atualizado para atender aos critérios mínimos antes da revisão ou rejeitar o pacote devido à falta de adequação ou sobreposição.
- Se o seu pacote atender aos critérios mínimos, o editor designará de 1 a 3 revisores. Eles serão solicitados a fornecer revisões como comentários sobre a sua _issue_ (submissão) dentro de 3 semanas.
- Pedimos que você responda aos comentários dos revisores em até 2 semanas após a última revisão enviada, mas você pode fazer atualizações no seu pacote ou responder a qualquer momento. Sua resposta deve incluir um link para a versão atualizada da sua [NEWS.md](#news) do seu pacote. Aqui está um [exemplo de resposta de autor](https://github.com/ropensci/software-review/issues/160#issuecomment-355043656).  Incentivamos conversas contínuas entre autores e revisores. Consulte a seção [guia de revisão](#reviewerguide) para obter mais detalhes.
- Frequentemente, mudanças no pacote podem alterar os resultados automatizados [das verificações `pkgcheck`](https://docs.ropensci.org/pkgcheck). Para avaliar isso, autores podem solicitar uma nova verificação do pacote com o comando `@ropensci-review-bot check package`.
- Notifique-nos imediatamente se você não puder mais manter o seu pacote ou responder às revisões. Nestes casos, se espera que você retire a submissão ou que encontre mantenedores alternativos para o pacote. Você também pode discutir questões de manutenção na área de trabalho da rOpenSci no Slack.
- Assim que seu pacote for aprovado, forneceremos mais instruções sobre a transferência do seu repositório para o repositório da rOpenSci.

Nosso [código de conduta](#code-of-conduct) é obrigatório para todos os envolvidos em nosso processo de revisão.