Plano de Contribuição

1. Introdução

Este Plano de Contribuição determina as regras para submissão de códigos e contribuições nos repositórios do Projeto PUMA no semestre 2023-1.

2. Issues

Todas as contribuições devem estar vinculadas a uma única issues, e todas as issues devem ser criadas e preenchidas de acordo com os templates disponíveis no repositório.

Cada issue também deve possuir Assignees, responsáveis por desenvolvê-la, e labels para indicar o tipo de issue.

3. Commits

Os commits devem ser na língua inglesa, curtos e simples, de forma a expor objetivamente o trabalho que foi feito naquele commit.

Caso o commit seja resultado de um trabalho em equipe, deve-se utilizar o Co-authored-by:

Visando uma melhor padronização, utilizaremos o commit semântico, que pode ser conferido e acessado através deste link.

Como utilizar

Os commits semânticos possuem um esqueleto padrão que consiste em partes opcionais que podem ou não ser acrescentadas.

<tipo>: <descrição>

Exemplo:
Fix: Fix user redirection upon sign up

A primeira e principal descrição de um commit semântico é o Tipo. Tem como finalidade dizer o que aquele commit está realizando. Os tipos se resumem em feat, fix, refactor, style, chore, doc e test [1].

Feat: Utilizado quando feita qualquer adição ao código.O foco dele é ser usado quando houver uma nova implementação de funcionalidade no sistema.
Fix: Utilizado quando existem erros no código que estão causando bugs.
Refactor: Utilizado na refatoração de código mas que não altere sua funcionalidade.
Style: Utilizado quando feita uma alteração no estilo e formatação do código.
Chore: Utilizado na atualização para mudanças em ferramentas, configurações e bibliotecas. Atualizações que não ocasionam em alteração no código de produção.
Doc: Utilizado quando é adicionado ou atualizado alguma documentação no projeto.
Test: Utilizado quando feita qualquer alteração em relação aos testes do projeto.

4. Pull Requests

Os pull requests devem estar obrigatoriamente vinculados a uma issue. É necessário também a inclusão de Reviewers, responsáveis por verificar a conclusão da issue e a validade do pull request. O pull request só poderá ser mergeado com a aprovação de pelo menos dois Reviewers.

5. Branches

Com exceção das branches principais (main, gh-pages, devel), cada branch deve estar vinculada a uma única issue. Após a conclusão da issue e fechamento do pull request associado, a branch referente não pode ser apagada, porque ela será utilizada para organização de pacotes de entregas para a release. Para uma correta padronização das branchs e fluxo, utilizaremos o Gitflow [2].

Para manter o padrão criaremos a branch bem parecido com o commit, sendo adotado os seguintes padrões:

<tipo>/<descrição>

Exemplo:
feature/orm-migration
fix/user-redirection
hotfix/password-redirection


feature: Utilizado quando feita qualquer nova implementação de funcionalidade no sistema.
fix: Utilizado quando é necessário abrir uma branch de correção de uma funcionalidade já existente no sistema.
refactor: Utilizado quando é necessário abrir uma branch de refatoração de código mas que não altere sua funcionalidade.
documentation: Utilizado quando é necessário abrir uma branch de documentação no projeto.
hotfix: Utilizado quando é necessário abrir uma branch de correção de um bug em produção no projeto.

6. Referência

[1] O que são Commits Semânticos e como utilizo?. Disponível em: https://www.letscode.com.br/blog/o-que-sao-commits-semanticos-e-como-utilizo. Acesso em: maio, 2023.

[2] Fluxo de trabalho de Gitflow. Disponível em: https://www.atlassian.com/br/git/tutorials/comparing-workflows/gitflow-workflow#:~:text=O%20que%20%C3%A9%20o%20Gitflow,por%20Vincent%20Driessen%20no%20nvie.. Acesso em: maio, 2023.

7. Histórico de Revisão

Data	Versão	Modificação	Autor
05/05/2023	0.1	Abertura do documento.	Abner Filipe
05/05/2023	0.2	Correção e revisão do documento	Rafael Leão
18/05/2023	0.3	Correção dos exemplos	Juliana Valle
27/05/2023	0.4	Refatoração da estrutura do documento	Juliana Valle