Processos.md

@@ -20,45 +20,56 @@
 
 Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira como o time se organizou e trabalha.
 
-## Sumário
+## 🔖 Sumário
 
-- [xxx](#git-workflow)
-- [xxx](#code-freezing)
-- [Definition of Ready](#definition-of-ready)
-- [Definition of Done](#definition-of-done)
-- [Padrões utilizados](#padrões-utilizados)
+- [Git Workflow](#git-workflow)
+    - [Definition of Ready](#definition-of-ready)
+    - [Definition of Done](#definition-of-done)
+- [Padrões Utilizados](#padrões-utilizados)
     - [Branches](#branches)
     - [Commits](#commits)
     - [Merge Requests](#merge-requests)
+- [Code Freezing](#code-freezing)
+
 
 ---
 
-### Definition of Ready
+# 🚂 Git Workflow
+
+Para que os trabalhos no repositório sigam um fluxo organizado de trabalho, vamos adotar o **Git Flow** um fluxo de trabalho que consiste em duas principais branches:
+- Main: A branch principal, tendo todo o código final, validado e testado;
+- Development: A branch de desenvolvimento, onde irá organizar os trabalhos realizados.
+
+---
+
+### 🚦 Definition of Ready
 
 Para que uma tarefa seja considerada pronta para desenvolvimento, ela deve seguir as seguintes condições:
-- Qualquer tarefa da qual ela tenha dependência.
-- O ambiente de desenvolvimento local deve estar devidamente setado.
+- Não possuir nenhuma outra tarefa que dependa dela;
+- Comunicar e organizar com os colegas que estão vinculados à tarefa;
+- Possuir o ambiente de desenvolvimento configurado de acordo com as regras. Mais detalhes em [Instalação](https://tools.ages.pucrs.br/planline/wiki/-/wikis/instalacao).
 
 ---
 
-### Definition of Done
+### 🏁 Definition of Done
 
 Para que uma tarefa seja considerada concluída ela deve seguir as seguintes condições:
-- O merge request da branch em que a tarefa foi desenvolvida para a develop deve ter sido concluída.
-- O código deve ter sido revisado e aprovado.
-- O código deve ter testes unitários e ter sido testado manualmente.
-- Qualquer documentação necessária deve ter sido escrita (payloads, endpoints, ...).
+- O código deve estar funcional;
+- Toda possível documentação deve ser criada (payloads, endpoints, ...);
+- Todas revisões devem ter sido informadas e corrigidas;
+- O merge request da tarefa deve ter sido revisado e aprovado por um AGES III;
 
 ---
 
-# Padrões utilizados
+# 🛠️ Padrões Utilizados
 
-#### Idioma padrão
+#### 🌐 Idioma padrão
 
-Como acordo, todas as branches, commits e MR devem ser descritos em inglês.
+Como acordo, todas as branches, commits e merge requests devem ser descritos em **inglês**.
 
-### Branches
+---
 
+### 🔱 Branches
 
 Para criar uma branch e começar a trabalhar nela, 3 comandos git serão essenciais, vejamos abaixo quais são eles:
 
@@ -68,7 +79,7 @@ git pull # Puxa as modificações remotas.
 git checkout -b <NOME_DA_SUA_BRANCH_AQUI> # Cria uma nova branch.
 ```
 
-Utilizando os comandos acima, você estará indo para a branch ‘develop’, puxando todas as modificações remotas e criando uma nova branch a partir de ‘develop’. Você então passará a trabalhar na nova branch criada.
+Nos comandos acima, você estará trocando para a branch ‘develop’, puxando todas as modificações remotas, e criando uma nova branch a partir da branch ‘develop’, e também, a branch em uso passa a ser a criada. Você então passará a trabalhar na nova branch criada.
 
 Os nomes das branches devem seguir o formato ```<tipo>/<código>```, onde os ```<tipo>``` são os mesmos tipos usados nas tarefas cadastradas no Trello, e o ```<código>``` é o card number, que pode ser encontrado logo abaixo do título do card, seguido de um "#".
 
@@ -87,7 +98,7 @@ Ser o mais sucinto possível no nome da branch, caso necessite seja mais descrit
 
 ---
 
-## Commits
+### 📦️ Commits
 
 Para tornar mais consistentes as mensagens de commit, usamos o padrão Conventional Commits. Para seguir esse padrão, as mensagens, em geral, devem escritas seguindo no formato `<tipo>[escopo]: <descrição>`, em que:
 - o `<tipo>`, obrigatório, é um dos tipos possíveis de commit;
@@ -100,7 +111,7 @@ Exemplos do uso:
 - `docs: Describe commit patterns.`
 - `build: dependencies updates.`
 
-A descrição é escrita de acordo com a vontade do desenvolvedor. O escopo não é pré-definido, mas o grupo deve procurar usar o mesmo nome quando falando da mesma coisa; o escopo deve sempre ser um substantivo.
+A descrição é escrita de acordo com a vontade do desenvolvedor. O escopo não é pré-definido, mas o grupo deve procurar usar o mesmo nome quando falando do mesmo contexto/componente/etc; o escopo deve sempre ser um substantivo.
 
 Os tipos são limitados; o Conventional Commits especifica dois -- "`fix`", que identifica uma correção em algo já existente, e "`feat`", que indica a adição de uma funcionalidade nova --, mas o time pode especificar outros, desde que use-os de forma consistente.
 
@@ -118,8 +129,9 @@ Para commits onde teve participação de mais de um autor. Siga o exemplo abaixo
 
 `Co-Authored-By: Nome Sobrenome <[email protected]>`
 
+---
 
-## Merge Requests
+### 🤝 Merge Requests
 
 Merge request(MR) deve ser criado apenas ao finalizar a task com todos seus objetivos atingidos. Ao criar o MR, o responsável entende que seu código está pronto para ser entregue em produção.
 
@@ -128,3 +140,12 @@ Cada projeto terá seu template de MR que deverá ser usado para descrever as mu
 Ao analisar um MR, caso o revisor note alguma correção a ser feita no código, o autor será avisado pelo canal de MRs do discord, iremos marcar o usuário no discord para enviar uma notificação. Uma vez que forem corrigidos os pontos levantados, o autor deve reagir à marcação feita no canal do discord com um emoji :white_check_mark: para sinalizar que o MR está pronto para reavaliação.
 
 ---
+
+# ⛄ Code Freezing
+
+É estabelecido um tempo onde se encerram os trabalhos de desenvolvimento antes de uma entrega, para garantir a qualidade da entrega, evitando possíveis bugs e problemas que possam surgir.
+
+Foi determinado às **4h da manhã da quinta-feira**, antes da entrega.
+
+---
+