Como contribuir?
Se você é um usuário externo ao time de desenvolvimento do IndicaAi e quer contribuir com a nossa proposta você deve fazer um fork do repositório e seguir os passos a frente. Para quem já faz parte do nosso time de desenvolvimento, basta seguir esses passos:
- Criar sua issue
- Criar uma branch
- Fazer seus commits
- Abrir um Pull Request
Política de Issues
- As issues devem possuir um nome simples que descreva com poucas palavras o seu propósito;
- A descrição da issue deve relatar mais a funcionalidade ou bug a ser solucionado. Não é obrigatório inserir uma descrição se o nome da issue já consegue descrever bem o objetivo, mas nós recomendamos colocar sempre :)
- Lembre-se sempre de identificar a issue com as labels referentes. Isso ajuda o nosso trabalho na hora de mapear quais são as demandas de cada área do projeto.
Issues para novas funcionalidades
- Novas funcionalidades devem ser descritas como user stories, conforme a metodologia aplicada no nosso projeto;
- Essas issues devem ser acompanhadas de uma lista de critérios de aceitação que garantem que o ao implementar o objetivo será atendido, tanto em termos de funcionalidade, usabilidade, design e qualidade de código;
- No nosso repositório nós já disponibilizamos um templete básico para essas issues, com alguns critérios comuns a maioria das funcionalidades.
-
Para melhor identificar essas issues o nome deve seguir o seguinte padrão:
US - Nome da Issue
Issues para histórias técnicas
- Histórias técnicas devem ser descritas conforme o padrão definido na metodologia desse projeto;
-
Para melhor identificar essas issues o nome deve seguir o seguinte padrão:
TS - Nome da Issue
Política de Branchs
Branch master
A branch master é a branch estável do projeto, onde estará o código de produção. Commits e pushes para essa branch estarão bloqueados. Somente serão aceitos pull requests para essa branch oriundos da branch devel.
Branch devel
A branch devel será a branch de desenvolvimento, na qual será unificado novas funcionalidades e correções no código visando gerar uma nova versão estável.
Nomenclatura das branchs
Os nomes das branchs devem estar em inglês e serem objetivos e claros, especificando em poucas palavras a intenção da branch. Além do mais, devem referenciar a issue relacionada no início do nome, conforme o seguinte padrão:
x-branch-name
Onde x refere-se ao número da issue.
Branchs de Documentação
Branchs cujo foco seja unicamente atualizar a documentação do repositório devem seguir o seguinte padrão:
documentation/x-branch-name
Branchs de novas funcionalidades
Branchs cujo foco seja inserir uma nova funcionalidade no sistema, em geral relacionadas as user stories devem seguir o seguinte padrão:
feature/x-branch-name
Branchs para correção de bugs
Branchs cujo foco seja corrigir funcionalidade no sistema, em geral relacionadas as user stories devem seguir o seguinte padrão:
bugfix/x-branch-name
Branchs para refatoração de código
Branchs cujo foco seja refatorar uma funcionalidade no sistema, em geral relacionadas as techical stories devem seguir o seguinte padrão:
refactor/x-branch-name
Branchs para problemas críticos em produção
Branchs cujo foco seja corrigir algum problema crítico em produção, o qual não possa esperar até a próxima release devem seguir o seguinte padrão:
hotfix/x-branch-name
Branchs para lançamento de versão
release/stable-x.x.x
Onde x.x.x refere-se ao número da versão que será lançada.
Política de Commits
Mensagem do Commit
A descrição dos commits deve estar em inglês e ser sucinta e objetiva, representando claramente o que está sendo alterado naquele commit. A mensagem deve estar acompanhada do número da issue relacionada, como no exemplo abaixo:
git commit -m'#X my message'
Onde X representa o número da issue relacionada.
Commits com pareamento
Quando houver pareamento o commit deve vir acompanhado da mensagem: Co-authored-by: CoAuthorName <coauthoremail@mail.com>. Para tal deve-se seguir os seguintes passos:
git commit -s- Inserir a descrição do commit na primeira linha
- Na linha seguinte inserir a mensagem
Co-authored-by: CoAuthorName <coauthoremail@mail.com>, com os respectivos dados do co-autor.
Política de Pull Requests
Os Pull Requests devem possuir a descrição em inglês e seguir as seguintes recomendações:
-
Pull Requests originados de branchs classificadas como feature, documentation e bugfix devem ser abertos para a branch devel.
-
Pull Requests originados de branchs hotfix devem ser abertos direto para branch master.
Pull Requests em progresso
Pull Requests que ainda não estão prontos para serem aceitos devem conter a sinalização WIP - Work in Progress logo no início do nome. Exemplo:
WIP: my pull request
Condições para aprovação do Pull Request
Para que o pull request seja aceito nas branchs oficiais ele deve atender os seguintes pontos:
- Funcionalidade, correção ou refatoração completa;
- Build de integração contínua passando;
- Manter a cobertura do código acima de 90%;
- Estar de acordo com as métricas de qualidade de código descritas no plano de qualidade.
Pull Requests de Lançamento de Versão
Lançamentos de novas versões a partir devel deve ser realizado seguindo os seguintes passos:
- Criar uma branch release a partir da devel com o número da nova versão
- Lançar a tag do nova release
- Atualizar a master com a nova release