CONTRIBUTING.md

Contribuindo

Como eu faço para ...

• Usar este guia?
• Perguntar ou dizer alguma coisa? 🤔🐛😱
  • Para solicitar ajuda
  • Para relatar um erro ou bug
  • Para solicitar um recurso
• Fazer alguma coisa? 🤓👩🏽‍💻📜🍳
  • Configurar o projeto
  • Contribiur com a Documentação
• Gerenciar alguma coisa?✅🙆🏼💃👔
  • Fornecer suporte para problemas
  • Catalogar problemas em aberto
  • Arquivar Solicitações Antigas
  • Revisar Solicitações
  • Unificar Solicitações
  • Anunciar um lançamento
  • Me Juntar à equipe do projeto
• Adicionar um guia como este para meu projeto?🤖😻👻

Introdução

Muito obrigado pelo seu interesse em contribuir !. Todos os tipos de contribuições são encorajadas e valorizadas. Veja o índice para diferentes maneiras de ajudar e detalhes sobre como este projeto os trata! 📝

Por favor, certifique-se de ler a seção relevante antes de fazer sua contribuição! Isso tornará muito mais fácil para nós, mantenedores, tirar o máximo proveito disso e suavizar a experiência de todos os envolvidos. 💚

A equipe do projeto aguarda suas contribuições.🙌🏾✨

Solicitar ajuda

Se você tiver alguma dúvida sobre este projeto, como usá-lo, ou apenas precisar de esclarecimentos sobre algo:

• Solicite ajuda em https://github.com/elenderg/Portugues-Puro/issues
• Forneça o máximo de informações possíveis sobre o que está acontecendo.
• Forneça versões de projeto e plataforma, dependendo do que parece relevante. Se não souber, procure alguém para fornecer essas informações se os mantenedores solicitarem.

Depois de ter feito isso:

• A equipe do projeto irá rotular o problema.
• Alguém tentará obter uma resposta em breve.
• Se você ou os mantenedores não responderem a um problema por 30 dias, o [problema será fechado](# clean-up-issues-and-prs). Se você quiser voltar a ele, responda (uma vez, por favor) e nós reabriremos o problema existente. Evite registrar novas edições como extensões de uma que você já fez.

Reportar um erro ou bug

Se você encontrar um erro ou bug com o projeto:

• Comunique o problema em https://github.com/elenderg/Portugues-Puro/issues
• Inclua as etapas de reprodução que outra pessoa pode seguir para recriar o bug ou erro por conta própria.
• Forneça as versões de projeto e plataforma, dependendo do que parece relevante. Caso contrário, esteja pronto para fornecer essas informações se os mantenedores solicitarem.

Depois de fazer isso:

• A equipe do projeto irá rotular o problema.
• Um membro da equipe tentará reproduzir o problema com as etapas fornecidas. Se não houver etapas de reprodução ou nenhuma maneira óbvia de reproduzir o problema, a equipe solicitará essas etapas e marcará o problema como não verificado. Bugs com a tag não verificado não serão corrigidos até que sejam identificados e reproduzidos.
• Se a equipe conseguir reproduzir o problema, ele será marcado como preciso de ajuda, bem como possivelmente outras tags (como bug), e o problema será deixado para ser implementado por alguém.
• Se você ou os mantenedores não responderem a um problema por 30 dias, o problema será fechado. Se você quiser voltar a ele, responda (uma vez, por favor) e nós reabriremos o problema existente. Evite registrar novas edições como extensões de uma que você já fez.
• Questões críticas podem ser deixadas em aberto, dependendo da percepção imediata e da gravidade, mesmo após o prazo de 30 dias.

Solicitando um recurso

Se o projeto não fez algo que você precisa ou deseja fazer:

• Comunique sua sugestão de recursp em https://github.com/elenderg/Portugues-Puro/issues
• Forneça o máximo de contexto possível sobre a funcionalidade desejada.
• Tente esclarecer por que os recursos e alternativas existentes não funcionariam para você.

Depois de ter feito isso:

• A equipe do projeto irá rotular o problema.
• A equipe do projeto avaliará a solicitação de recurso, possivelmente fazendo mais perguntas para entender sua finalidade e quaisquer requisitos relevantes. Se o problema for encerrado, a equipe transmitirá seu raciocínio e sugerirá um caminho alternativo a seguir.
• Se a solicitação de recurso for aceita, ela será marcada para implementação com nova funcionalidade, o que pode ser feito por um membro da equipe principal ou por qualquer pessoa da comunidade que deseja contribuir com o código.

Nota: É improvável que a equipe seja capaz de aceitar todas as solicitações de recurso apresentadas. Por favor, entenda se eles precisarem dizer não.

Configuração do projeto

Então você quer contribuir com algum código! Isso é ótimo! Este projeto usa as solicitações do GitHub para gerenciar as contribuições, então leia sobre como bifurcar um projeto GitHub e submeter uma solicitação se você nunca fez isso antes.

Se isso parecer muito difícil ou você não consegue fazer toda essa configuração, você também pode editar os arquivos diretamente sem ter que fazer nenhuma configuração. Sim, até mesmo códiios podem ser editados.

Se você quiser seguir o caminho normal e executar o projeto localmente:

• Faça o fork do projeto

Então, em seu computador abra a pasta do projeto:

• C:\Users\%username%\Documents\GitHub\Portugues-Puro\

E você deve estar pronto para começar!

Contribuir com a documentação

A documentação é uma parte superimportante e crítica deste projeto. Os documentos são como controlamos o que estamos fazendo, como e por quê. É assim que nos mantemos em sintonia com nossas políticas. E é assim que contamos aos outros tudo o que eles precisam para poder usar este projeto - ou contribuir com ele. Então, agradeço antecipadamente.

Contribuições de documentação de qualquer tamanho são bem-vindas! Sinta-se à vontade para registrar um solicitação, mesmo que esteja apenas reformulando uma frase para ser mais claro ou corrigindo um erro de ortografia!

Para contribuir com documentação:

• Configure o projeto.
• Edite ou adicione qualquer documentação relevante.
• Certifique-se de que suas alterações estejam formatadas corretamente e de forma consistente com o restante da documentação.
• Releia o que você escreveu e execute um corretor ortográfico para ter certeza de que não perdeu nada.
• Escreva mensagens de confirmação claras e concisas usando o formato convencional para registro de alterações. Os commits de documentação devem usar docs(<component>): <message>.
• Vá para https://github.com/elenderg/Portugues-Puro/pulls e abra uma nova solicitação pull com suas alterações.
• Se a sua solicitaçãoe estiver relacionada a um problema em aberto, adicione uma linha na descrição da sua solicitação que diga Correção do problema # 123, onde # 123 é o número do problema que você está corrigindo.

Uma vez que você tenha enviado a solicitação:

• Um ou mais mantenedores usarão o recurso de revisão do GitHub para revisar sua solicitação.
• Se o mantenedor solicitar que você faça alguma alteração, edite o que for preciso, e submeta uma nova solicitação..
• Se o mantenedor decidir rejeitar sua solicitação, ele agradecerá pela contribuição e explicará por quais motivos não aceitará as alterações. Sem problemas Ainda apreciamos muito o seu tempo para fazer isso, e não consideramos isso levianamente. 💚
• Se a sua solicitação for aceita, ela será devidamente identificada e incorporada ao "branch" mais recente logo em seguida. Sua contribuição será distribuída para as todos na próxima vez que os mantenedores fizerem um lançamento

Contribuir com Código

Nós gostamos muito de commits de código! Eles são muito úteis e mantêm o projeto em andamento e fazendo o trabalho necessário para ser útil a outras pessoas.

Contribuições de código de praticamente qualquer tamanho são aceitáveis!

A principal diferença entre contribuições de código e contribuições de documentação é que contribuir com o código requer a inclusão de testes relevantes para o código que está sendo adicionado ou alterado. Contribuições sem testes de acompanhamento serão suspensas até que um teste seja adicionado, a menos que os mantenedores considerem os testes específicos impossíveis ou um fardo muito grande para tal contribuição.

Para contribuir com o código:

• Configure o projeto.
• Faça as alterações necessárias no código-fonte.
• Inclua qualquer documentação adicional que as mudanças possam precisar.
• Escreva testes que verifiquem se sua contribuição funciona conforme o esperado.
• Escreva mensagens de confirmação claras e concisas usando formato convencional para registro de alterações.
• Vá para https://github.com/elenderg/Portugues-Puro/pulls e abra uma nova solicitação pull com suas alterações.
• Se a sua solicitação estiver relacionada a um problema aberto, adicione uma linha na descrição da sua solicitação que diga Correção do problema # 123, onde # 123 é o número do problema que você está corrigindo.

Uma vez que você tenha feito isso:

• Exceto em circunstâncias especiais, os mantenedores não revisarão as solicitações até que todas as verificações sejam feitas.
• Um ou mais mantenedores usarão o recurso de revisão do GitHub para revisar a sua solicitação.
• Se o mantenedor solicitar que você faça qualquer alteração, modifique o que for necessário e envie uma nova solicitação. Tags adicionais (como não-testado) serão adicionadas dependendo do nível de análise que foi feito em sua solicitação.
• Se o mantenedor decidir rejeitar sua solicitação, ele agradecerá pela contribuição e explicará por quais motivos ele não aceitou as alterações. Sem problemas! Ainda apreciamos muito o seu tempo para fazer isso, e não consideramos isso levianamente. 💚
• Se a sua solicitação for aceita, ela será identificada e incorporado ao branch mais recente logo em seguida. Sua contribuição será distribuída para todos na próxima vez que os mantenedores realizarem um lançamento

Fornecendo suporte em questões

Necessita de um Colaborador: nenhum

Ajudar outros usuários com suas dúvidas é uma maneira realmente incrível de contribuir com qualquer comunidade. Não é incomum que a maioria dos problemas em projetos de código aberto sejam questões relacionadas ao suporte feitas por usuários que tentam entender algo que encontraram ou encontrar uma maneira de contornar um bug conhecido.

Às vezes, o rótulo preciso-de-ajuda será adicionado a coisas que acabam sendo outras coisas, como bugs ou solicitações de recursos. Nesse caso, descubra os detalhes com a pessoa que registrou o problema original, adicione um comentário explicando qual é o bug e altere o rótulo de preciso-de-ajuda para bug ou recurso. Se você não puder fazer isso sozinho, mencione um mantenedor (usando @) para que ele possa fazer isso.

Para ajudar outras pessoas com suas perguntas:

• Vá para o rastreador de problemas e filtre os problemas abertos pelo rótulo preciso-de-ajuda.
• Leia a lista até encontrar algo com o qual esteja familiarizado o suficiente para dar uma resposta.
• Responda ao problema com todos os detalhes necessários para esclarecer a questão ou obtenha mais detalhes sobre o que está acontecendo.
• Assim que o problema terminar e as coisas forem esclarecidas, feche o problema ou peça ao arquivador original do problema (ou a um mantenedor) para fechá-lo para você.

Algumas notas sobre como identificar problemas de suporte:

• Evite responder a questões que você não sabe se pode responder com precisão.
• Tanto quanto possível, tente referir-se a problemas anteriores usando respostas aceitas anteriormente para o problema em questão. Disponibilize um link para eles a partir de suas respostas com o formato # 123.
• Seja gentil e paciente com os usuários - muitas vezes, as pessoas que se deparam com coisas confusas podem ficar chateadas ou impacientes. Isso é normal. Tente entender de onde eles vêm e, se você se sentir desconfortável com o tom, fique à vontade para ficar longe ou se afastar do assunto. (observação: se o usuário for totalmente hostil ou violar o CdC, consulte o Código de Conduta para resolver o conflito).

Identificação adequada de problemas

Vagas abertas: Rastreador de problemas

Uma das tarefas mais importantes no tratamento de problemas é rotulá-los de forma útil e precisa. Todas as outras tarefas que envolvem problemas dependem, em última análise, de o problema ser classificado de forma que as partes relevantes que procuram realizar suas próprias tarefas possam encontrá-los de forma rápida e fácil.

Para rotular problemas, abra a lista de problemas pendentes e, ** do mais recente ao mais antigo **, leia cada um e aplique os rótulos dos problemas de acordo com a tabela abaixo. Se você não tiver certeza sobre qual rótulo aplicar, pule o problema e tente o próximo: não se sinta obrigado a rotular cada um dos problemas por você mesmo!

Etiqueta	Quando usar	Observações
bug	Esse termo deve ser adicionado a casos em que o código (ou documentação) está se comportando de uma maneira inesperada.	Se algo está acontecendo que surpreende o * usuário *, mas não vai contra a maneira como o código foi projetado, ele deve usar o rótulo aprimoramento.
critical	Esse termo deve ser adicionado aos problemas de bug se o problema descrito torna o código completamente inutilizável em uma situação comum.
documentação	Adicione a problemas ou solicitações de pull que afetam qualquer documentação do projeto.	Pode ser combinado com outros rótulos, como bug ou aprimoramento.
repetido	Esse termo deve ser adicionado a questões ou solicitações que se referem exatamente ao mesmo problema que outro que foi previamente identificado.	Problemas duplicados devem ser marcados e fechados imediatamente, com uma mensagem referindo o problema do qual é uma duplicata (com # 123)
aprimoramento	Esse termo deve ser adicionado a solicitações contendo solicitações de recurso, ou a problemas de documentação que são puramente aditivos: o código ou documentos atualmente funcionam conforme o esperado, mas uma alteração está sendo solicitada ou sugerida.
preciso de ajuda	Esse termo deve ser aplicado por qualquer membro da equipe em problemas e solicitações para os quais eles gostariam de obter ajuda externa. Geralmente, isso significa que é menos prioridade para a equipe de mantenedor implementar, mas que a comunidade é encorajada a se engajar, se assim o desejar
em andamento	Esse termo deve ser aplicado por membros da equipe para solicitações que estão com algum trabalho pendente antes de estarem prontos para revisão.	O responsável pelo envio de RP original deve @mencionar o membro da equipe que aplicou o rótulo assim que a solicitação for atendida.
desempenho	Esse termo deve ser aplicado a problemas que estejam diretamente relacionados à melhoria do desempenho.
refazer	Esse termo deve ser adicionado a solicitações que lidam com a organização ou modificação do projeto para melhorá-lo.
iniciantes	Aplicado por membros da equipe às questões que eles consideram boas introduções ao projeto para pessoas que não contribuíram antes. Eles não são necessariamente "fáceis", mas sim focadas em quanto contexto é necessário para entender o que precisa ser feito para este projeto em particular.	Espera-se que os membros existentes do projeto não foquem neles, a menos que a questão aumente de prioridade.
pergunta	Esse termo deve ser aplicado a perguntas sobre como usar o projeto, esclarecer o motivo do comportamento inesperado ou possivelmente relatar um bug, mas ainda não tem detalhes suficientes para determinar se isso contaria como tal.	O rótulo deve ser alterado para bug se forem fornecidas etapas de reprodução confiáveis. Problemas principalmente com configurações não intencionais do ambiente de um usuário não são considerados bugs, mesmo que causem travamentos.
testes	Esse termo deve ser aplicado a solicitações que adicionem ou sugiram testes ao projeto.	Se uma solicitação estiver com testes pendentes, isso será tratado por meio do processo de revisão de solicitações
sem conserto	Os membros podem aplicar este rótulo a questões que claramente não têm nada a ver com o projeto ou estão totalmente fora de seu escopo / esfera de influência. Os membros da equipe podem aplicar este rótulo e fechar um problema ou solicitação se decidirem rejeitar um problema relevante.	O problema ou solicitação deve ser encerrado assim que o rótulo for aplicado, devendo conter uma explicação clara do motivo pelo qual o rótulo foi usado. Os contribuidores são livres para contestar a rotulagem, mas a decisão final recai sobre os responsáveis pela confirmação de aceitar algo ou não.

Arquivamento de Solicitações antigas

Vagas abertas: Rastreador de problemas

Problemas e solicitações podem ficar obsoletos depois de um tempo. Talvez estejam abandonados. Talvez a equipe simplesmente não tenha tempo para abordá-los tão cedo.

Nesses casos, eles devem ser fechados até que sejam ativados novamente ou a interação seja reiniciada.

Para arquivar problemas e solicitações:

• Pesquise problemas ou PRs no rastreador de problemas e adicione o termo updated:<=YYYY-MM-DD, onde YYYY é o ano atual, MM é o mês e DD o dia. Lembre-se de inserir datas. antigas, com pelo menos 30 dias de diferença da data atual;
• Passe por cada problema * do mais antigo ao mais recente * e feche-os se ** todas as opções a seguir forem verdadeiras **:
  • A solicitação não foi aberta por um mantenedor
  • A solicitação não foi marcadacomo problema crítico
  • A solicitação não foi marcada como iniciante ou dúvida (estas solicitações permanecer por um tempo maior, em geral, pois devem estar disponíveis para outros usuários)
  • A solicitação não contém nenhuma mensagem explícita nos comentários pedindo para ser deixada em aberto
  • A solicitação não pertence a um lançamento específico (1000, 2000, 3000, etc)
• Deixe uma mensagem ao fechar dizendo "Problema obsoleto arquivado. Abra novamente ou envie um ping se e quando você estiver pronto para retomar isso. Consulte https://github.com/elenderg/Portugues-Puro/blob/latest/CONTRIBUTING.md#arquivamento-de-solicitações-antigas para mais detalhes. "

Revisão de Solicitações

Vagas abertas: Rastreador de Problemas

Embora qualquer pessoa possa comentar sobre uma solicitação, adicionar feedback, etc, elas são * aprovados * apenaspor membros da equipe que possuam o cargo Rastreador de Problemas ou que possuam cargos superiores.

As revisões de problemas usam o recurso de revisão do próprio GitHub, que gerencia comentários, aprovação e iteração de revisão.

Algumas observações:

• Você pode pedir pequenas alterações ("nitpicks"), mas considere se elas podem causar problemas durante a unificação (merge):. Tente deixar comentários para aquilo que for aprovado.
• • TODAS AS SOLICITAÇÕES * devem ser cobertoas por um teste: seja por um teste anterior com falha, um teste existente que cobre toda a funcionalidade do código enviado ou novos testes para verificar qualquer comportamento novo / alterado. Todos os testes também devem passar e seguir as convenções estabelecidas. A área de cobertura do teste não deve ser ignorada, a menos que o caso específico seja considerado razoável pelos mantenedores.
• Certifique-se de estar familiarizado com o código ou a documentação que está sendo atualizada, a menos que seja uma pequena alteração (verificação ortográfica, formatação secundária, etc.). Você pode @mencionar outro membro do projeto que você acha que é mais adequado para a revisão, mas ainda assim fornecer sua própria revisão que não aprovou.
• Seja extremamente gentil: as pessoas que enviam contribuições de código / documento estão se colocando em uma posição bastante vulnerável e dedicam tempo e atenção ao que fizeram (mesmo que isso não seja óbvio para você!) - sempre responda com respeito, seja compreensivo, mas também não sinta que precisa sacrificar seus padrões pelo bem deles. Só não se comporte como um idiota quanto a isso.

Unificando solicitações

Vagas abertas: Committer

A ser desenvolvido - preciso escrever mais sobre esse processo.

Anunciando um novo Lançamento

Vagas abertas: Committer

A ser desenvolvido - preciso escrever mais sobre esse processo. A parte mais importante aqui é provavelmente que todos os testes devem ser realizados corretamente e as os números de versão devem usar um método de numeração semântica.

Junte-se à equipe do projeto

Formas de participar

Existem muitas maneiras de contribuir! A maioria deles não exige nenhum status oficial, a menos que seja indicado o contrário. Dito isso, há algumas posições que concedem habilidades de repositório especiais e esta seção descreve como elas são concedidas e o que fazem.

Todos os cargos abaixo são concedidos com base nas necessidades da equipe do projeto, bem como em sua opinião consensual sobre se gostariam de trabalhar com a pessoa e se acham que se encaixariam bem nessa posição. O processo é relativamente informal e é provável que as pessoas que expressam interesse em participar possam apenas receber as permissões que desejam.

Você pode identificar um colaborador no repo procurando pelas tags [Colaborador] ou [Proprietário] ao lado de seus nomes.

Permissão Descrição --- | --- Rastreador de Problemas | Concedido a contribuidores que expressam grande interesse em dedicar tempo a rastrear problemas do projeto. Essas tarefas são principalmente problemas de rotulagem, arquivamento de solicitações e revisão de solicitações , como bem como todas as coisas habituais que os contribuidores não membros da equipe podem fazer. Os rastreadores de problemas não mesclam solicitações, não rotulam lançamentos ou confirmam o código diretamente: isso ainda deve ser feito por meio do processo de solicitação de pull normal. Tornar-se um ratreador de problemas significa que a equipe do projeto confia em você para entender o suficiente do processo e do contexto da equipe para implementá-lo no rastreador de problemas. Committer | Concedido a contribuidores que desejam lidar com as mesclagens reais de solicitação, rotulando novas versões, etc. Os desenvolvedores devem ter um bom nível de familiaridade com a base de código e contexto suficiente para entender as implicações de várias alterações, bem como um bom senso de vontade e expectativas da equipe do projeto. Admin / Proprietário | Concedido às pessoas responsáveis ??pelo projeto, sua comunidade, etc.

Atribuição

Este guia foi gerado usando o gerador WeAllJS CONTRIBUTING.md. Faça o seu aqui!