Desejamos criar um ambiente convidativo para contribuições nesse projeto. Para isso, nós seguimos um código de conduta simples e pedimos que os contribuintes façam o mesmo.
Para contribuir com o Test Unit, antes de mais nada deve-se iniciar uma discussão com o time do TST (donos desse repositório) sobre a alteração ou melhoria que você deseja ver no projeto via issue.
Essa discussão deverá seguir seu curso até que o time do TST aceite que a alteração/melhoria discutida deva ser incorporada ao projeto, nos termos acertados na discussão da issue.
Neste momento, a issue já deverá ter sido movida para o quadro do projeto, para a coluna To do.
Em seguida, você (o proponente da alteração/melhoria) deverá trabalhar em uma feature branch com a issue referenciada em seu nome (ex.: EVENTO_9999_ISSUE_99), que deverá ser enviada ao repositório tão logo esteja funcional e apta a ser incorporada ao projeto:
- Com testes suficientes para validar as regras/lógica introduzidas;
- Sem falhar os testes existentes;
- Construindo no travis-ci sem erros (https://travis-ci.org/);
- Documentada, na própria issue ou com alguma entrada no Readme.
Neste momento, a issue deverá se encontrar na coluna In progress no quadro do projeto.
Após enviar a branch sendo trabalhada ao repositório (push), você deverá abrir um pull request. Isso deixará a alteração/melhoria em estado de revisão.
Neste momento, a issue deverá se encontrar na coluna Review no quadro do projeto.
Lembrando que a revisão poderá implicar em alguns ciclos de correção/adaptação até que a branch possa ser aceita e incorporada (merged).
Finalmente, a issue se encontrará na coluna Done no quadro do projeto.
Vamos revisar os principais passos:
- Iniciar discussão em uma nova issue;
- Trabalhar em uma nova feature branch;
- Subir a branch para o repositório e abrir um pull request;
- Iterar sobre a branch com ajustes e correções até que seja aceita;
Ao final, se tudo correr como esperado, a issue será encerrada e a alteração/melhoria estará devidamente incorporada ao projeto.
Caso você esteja interessando em contribuir, tenha alguma dúvida ou sugestão, por favor abra uma issue que iremos responder o mais rápido possível.
Recomendamos o uso da branch master como versão mais estável. Estamos aderentes ao semantic versioning.
Caso queira acompanhar os trabalhos diários, sugerimos verificar as branchs ou verificar se existe uma issue já aberta com as mesmas dúvidas.
Trate as mensagens de commit como mensagens de email que descrevem a alteração e o porquê.
A primeira linha de um commit deve ser tratada como o assunto de um email. Ela deve ser estritamente menor que 50 caracteres. O assunto deve ser autocontido e ter um sentido próprio e não apenas referenciar números de issues ou bugs externos.
A segunda linha deverá ser deixada em branco.
A terceira linha severá ser iniciada com o corpo da mensagem do commit (um ou dois parágrafos) descrevendo os detalhes do commit. Os parágrafos devem ser separados por linhas em branco e, caso sejam maiores que 76 caracteres, devem ser quebrados para melhor legibilidade.
As referências externas podem ficar na última parte da mensagem de commit (e.g. que issues foram tratadas ou corrigidas).