|
| 1 | +# Contribuindo |
| 2 | + |
| 3 | +Nós adoramos a sua contribuição! Queremos deixar o processo de contribuir para este repositório o mais fácil e transparente possível, independente se é para: |
| 4 | +- Reportar um bug |
| 5 | +- Discutir o estado atual do código |
| 6 | +- Enviar uma correção |
| 7 | +- Propor novas funcionalidades |
| 8 | +- Se tornar um mantenedor |
| 9 | + |
| 10 | +## Nós Desenvolvemos com o Github |
| 11 | +Usamos o GitHub para hospedar o código, rastrear issues e solicitações de recursos e aceitar Pull Requests. |
| 12 | + |
| 13 | +## Reporte Bugs usando os [issues](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues) do GitHub |
| 14 | + |
| 15 | +Se você encontrar bugs, erros ou inconsistências no código ou nos documentos deste projeto, informe-nos [abrindo um novo issue](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues/new), mas considere pesquisar os problemas existentes primeiro para verificar se o problema já foi relatado. Se tiver, nunca é demais adicionar um rápido "+1" ou "Eu também tenho esse problema". Isso ajuda a priorizar os problemas e solicitações mais comuns. |
| 16 | + |
| 17 | +### Escreva Relatórios de Bug com Detalhes, Contexto e Código de Amostra |
| 18 | + |
| 19 | +[Este é um exemplo](http://stackoverflow.com/q/12488905/180626) de um bom relatório de bug por @briandk. Aqui está [outro exemplo de craig.hockenberry](http://www.openradar.me/11905408). |
| 20 | + |
| 21 | +**Ótimos relatórios de bug** tendem a ter: |
| 22 | + |
| 23 | +- Um resumo e/ou contexto rápido |
| 24 | +- Passos para reproduzir |
| 25 | + - Seja específico! |
| 26 | + - Forneça um código de amostra, se puder. [O relatório de bug do StackOverflow](http://stackoverflow.com/q/12488905/180626) inclui código de amostra que *qualquer pessoa* com uma configuração básica de R pode executar para reproduzir o que eu estava vendo |
| 27 | +- O que você esperava que acontecesse |
| 28 | +- O que realmente acontece |
| 29 | +- Observações (possivelmente incluindo por que você acha que isso pode estar acontecendo ou coisas que você tentou que não funcionaram) |
| 30 | + |
| 31 | +As pessoas *adoram* relatórios de bug completos. Sem brincadeira. |
| 32 | + |
| 33 | +## Envie Alterações de Código por meio de Pull Requests |
| 34 | + |
| 35 | +Pull Requests simples para corrigir erros de digitação, documentar ou corrigir pequenos bugs são sempre bem-vindas. |
| 36 | + |
| 37 | +Pedimos que melhorias mais significativas para o projeto sejam propostas, antes que alguém comece a programar, como um [issue](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues) ou como uma [Pull Request de rascunho](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/pulls), que é um [novo recurso interessante](https://github.blog/2019-02-14-introducing-draft-pull-requests/) que dá a outros contribuidores a chance de apontar a direção certa, dar feedback sobre o design e talvez discutir se o trabalho relacionado já está em andamento. |
| 38 | + |
| 39 | +### Use um Estilo de Programação Consistente |
| 40 | + |
| 41 | +* Recuamos usando dois espaços (soft tabs) |
| 42 | +* SEMPRE colocamos espaços após os itens da lista e parâmetros do método ([1, 2, 3], não [1,2,3]), ao redor dos operadores (x + = 1, não x + = 1) e ao redor de setas hash. |
| 43 | +* Este é um software de código aberto. Considere as pessoas que lerão seu código e faça com que ele tenha uma boa aparência para elas. É como dirigir um carro: talvez você adore fazer zerinhos quando está sozinho, mas com os passageiros o objetivo é tornar a viagem o mais suave possível. |
| 44 | + |
| 45 | +### Use [Github Flow](https://guides.github.com/introduction/flow/index.html) para Pull Requests |
| 46 | + |
| 47 | +Usamos [Github Flow](https://guides.github.com/introduction/flow/index.html). Ao enviar Pull Requests, por favor: |
| 48 | + |
| 49 | +1. Faça um fork do repo e crie seu branch a partir do `master`. |
| 50 | +2. Se você adicionou um código que deve ser testado, adicione testes. |
| 51 | +3. Se você alterou APIs, atualize a documentação. |
| 52 | +4. Certifique-se de que o conjunto de testes seja aprovado. |
| 53 | +5. Certifique-se de que seu código passe por um lint. |
| 54 | +6. Emita essa Pull Request! |
| 55 | + |
| 56 | +### Envie Sob a Licença de Patente BSD-2-Clause Plus |
| 57 | + |
| 58 | +Resumindo, quando você envia alterações de código, seus envios são considerados disponíveis sob a mesma licença [CC-BY](../LICENSE-CC-BY-4.0.md) que cobre o projeto. Também pedimos que todos os contribuidores de código do GPG assinem o [Contrato de Licença de Contribuidor (CLA.md)](../CLA.md) para proteger futuros usuários deste projeto. Sinta-se à vontade para entrar em contato com os mantenedores se isso for um problema. |
| 59 | + |
| 60 | +## Referências |
| 61 | + |
| 62 | +Partes deste documento CONTRIBUTING.md foram adotadas a partir das melhores práticas de uma série de projetos de código aberto, incluindo: |
| 63 | +* [Rascunho do Facebook](https://github.com/facebook/draft-js/blob/a9316a723f9e918afde44dea68b5f9f39b7d9b00/CONTRIBUTING.md) |
| 64 | +* [Contribuição de IPFS](https://github.com/ipfs/community/blob/master/CONTRIBUTING.md) |
0 commit comments