|
1 | | -# Guia de contribuintes |
| 1 | +# Guia de contribuidores |
2 | 2 |
|
3 | | -Por favor, leia e compreenda o guia de contribuição antes de criar um issue ou pull request. |
| 3 | +Por favor, leia e compreenda o guia de contribuição antes de criar uma issue ou pull request. |
4 | 4 |
|
5 | 5 | ## Etiqueta |
6 | 6 |
|
7 | | -Este projeto é de código aberto e, como tal, os mantenedores dar o seu tempo livre para construir e manter o código fonte mantido dentro. Eles fazem o código disponível gratuitamente na esperança de que ele vai ser de utilidade para outros desenvolvedores. Seria extremamente injusto para eles sofrem abusos ou raiva pelo seu trabalho árduo. |
| 7 | +Este projeto é de código aberto e, como tal, os mantenedores dão o seu tempo livre para construir e manter o código fonte. Eles fazem o código disponível gratuitamente na esperança de que ele será de utilidade para outros desenvolvedores. Seria extremamente injusto para eles serem derespeitados pelo seu trabalho árduo. |
8 | 8 |
|
9 | | -Por favor, ser atencioso para com os mantenedores ao levantar questões ou apresentar pedidos de puxar. Vamos mostrar ao mundo que os desenvolvedores são pessoas civilizadas e altruístas. |
| 9 | +Por favor, seja atencioso com os mantenedores ao criar uma issue ou pull request. Vamos mostrar ao mundo que os desenvolvedores são pessoas civilizadas e altruístas. |
10 | 10 |
|
11 | | -É o dever do mantenedor para garantir que todos os envios para o projeto são de qualidade suficiente para beneficiar o projeto. Muitos desenvolvedores têm diferentes conjuntos de habilidades, pontos fortes e fracos. Respeitar a decisão do mantenedor, e não ficar chateado ou abusivo, se a sua submissão não é usado. |
| 11 | +É o dever do mantenedor garantir que todos os envios para o projeto são de qualidade suficiente para beneficiar o projeto. Muitos desenvolvedores têm diferentes conjuntos de habilidades, pontos fortes e fracos. Respeitar a decisão do mantenedor e não ficar chateado, se a sua submissão não é usada. |
12 | 12 |
|
13 | 13 | ## Viabilidade |
14 | 14 |
|
15 | | -Ao solicitar para a apresentação de novos recursos, em primeiro lugar considerar se ele pode ser útil para os outros. projetos de código aberto são usados por muitos desenvolvedores, que podem ter necessidades completamente diferentes para o seu próprio. Pense se ou não o seu recurso é susceptível de ser utilizado por outros usuários do projeto. |
| 15 | +Ao solicitar a apresentação de novos recursos, em primeiro lugar, considerar se ele pode ser útil para os outros. Projetos de código aberto são usados por muitos desenvolvedores, que podem ter necessidades completamente diferentes do seu. Pense se o seu recurso é suscetível de ser utilizado por outros usuários do projeto. |
16 | 16 |
|
17 | 17 | ## Procedimento |
18 | 18 |
|
19 | | -Antes de aplicar por uma questão: |
| 19 | +Antes de criar uma issue: |
20 | 20 |
|
21 | | -- Tentativa de replicar o problema, para garantir que ele não era um incidente coincidência. |
22 | | -- Verifique se a sua sugestão recurso já não está presente dentro do projeto. |
23 | | -- Verifique a guia pedidos de recebimento para garantir que o bug não tem uma correção em andamento. |
24 | | -- Verifique a guia pedidos de recebimento para garantir que o recurso não está já em andamento. |
| 21 | +- Tente replicar o problema, para garantir que ele não era um incidente ocasional. |
| 22 | +- Verifique se a sua sugestão de feature, já não está presente dentro do projeto. |
| 23 | +- Verifique a aba de pull requests para garantir que o bug não tem uma correção em andamento. |
| 24 | +- Verifique a aba de pull requests para garantir que a feature não está em andamento. |
25 | 25 |
|
26 | | -Antes de apresentar uma solicitação de recebimento: |
| 26 | +Antes de solicitar um pull request: |
27 | 27 |
|
28 | 28 | - Garantir que a sua submissão é [viável](#viabilidade) para o projeto. |
29 | | -- Verifique a base de código para garantir que o recurso ainda não existir. |
30 | | -- Verifique as solicitações de recebimento para garantir que outra pessoa já não tenha apresentado o recurso ou correção. |
| 29 | +- Verifique a base de código para garantir que o recurso ainda não existe. |
| 30 | +- Verifique os pull requests para garantir que outra pessoa já não tenha apresentado a feature ou fix. |
31 | 31 |
|
32 | 32 | ## Requisitos |
33 | 33 |
|
|
0 commit comments