---
# System prepended metadata

title: Pauta para Reunião Geral (terça 17/11)
tags: [Bots - Gestão]

---

# Pauta para Reunião Geral (terça 17/11)

###### tags: `Bots - Gestão`
---

* Feedback no meio do período (180°)
    * 
* Wiki
    * 
* Volta à sala
* Reunião de resultados
* Reunião de categorias



# AUXÍLIO TÉCNICO

## Por que auxiliar tecnicamente nos projetos?

## Sugestões de como detectar problemas nos projetos

## Como auxiliar os projetos

* Como vai ocorrer:
 
* Frequência: Mensal
* Contatar o líderes nessa sprint: [Chris/Nogueira/Sobral]
  * Atlas: [Chris/Nogueira/Sobral]
  * Ant:
  * Beetles: 
  * Eletrônica de Combate:
  * LEGO:
  * Sumô 3kg - Laura: 
  * Sumô 3kg - Vinícius: 
  * Sumô mini: 




---


# GITLAB 

## Por que Avaliar os repositórios do GitLab?
Sendo o local fixo que vai armazenar a parte técnica (eletrônica/programação/mecânica) de todos os projetos ao longo de todos os períodos, deve haver um monitoramento para que os líderes e membros sigam uma organização que resista o máximo possível com o passar do tempo sem ficar confuso. 
Além disso, os repositórios acabam tendo peculiaridades porque nenhum projeto é igual ao outro, porém, uma certa essência deve ser mantida. 

> Você: Oks, mas que essência seria essa!?
> Eu: muito boa pergunta! ;p

Para isso que iremos/estamos desenvolver(endo) o modelo de repositório. Ele vai tentar contemplar pontos em comum dos proejtos de modo a deixar organizado. Não só a nível de subgrupos e repositórios, mas a organização dos arquivos e pastas dentro de cada um dos repositórios.

Tendo posse desse modelo, precisamos auxiliar e cobrar os líderes para eles seguirem junto aos membros.

### Periodicidade da Avaliação
Uma vez por mês, em sprints ímpares. Foi escolhido ser sprint sim e sprint não para, em combinação com a tarefa de avaliar wiki dos projetos, toda sprint ter um acompanhamento dos membros no GIT de forma geral. 

### Como usar o Card
Assim que os gestores forem definidos para avaliar seus projetos, seus nomes devem ser escritos na check-list referente ao projeto.
Esse é o gestor responsável por fazer todas as tarefas dessa checklist

## Como vamos avaliar?
Vamos avaliar cada repositório individualmente com base nos critérios listados, usando os comentários nesse card para expor a situação dos repositórios.
Os comentários devem seguir um padrão de colocar o nome do projeto antes de comentário e uma linha marcada para cada critério de avaliação.
Exemplo nos comentários.
Depois do comentário, o responsável deve trocar uma ideia com o líder. Seja cobrando dele um repositório mais bem organizado ou debatendo sobre uma possível mudança no modelo de repositório.
O Resultado dessa conversa deve ser adicionada no comentário referente ao repositório desse projeto. Seja para marcar como "assunto resolvido" ou uma descrição do porque o modelo de repositório deve ser modificado.

## O que devemos avaliar?

- Atividade constante nos repositórios do projeto. Nosso local principal de hospedagem de arquivos técnicos não deve ficar parado. Se não tiver movimentação, quer dizer que o projeto não está avançando.
- Membros participativos, não somente o líder
- Comentários que ajudem a entender o que houve para que, depois, o que foi feito seja compreendido e facilite a volta nesse ponto caso haja algum problema.
- Subgrupos e repositórios no mesmo lugar com "hierarquias" diferentes
  - Subgrupos juntos: [ robo1 | robo2 | placaX ]
  - Jeito certo: [ [ Mecânica > robo1 | robo2 ] [ Eletrônica > placaX ] ]
- Verificar uso do `.gitignore` em cada repositório:
  - Se tem arquivos inúteis só pesando o repositório
  - Se o arquivo `.gitignore` está certo
- [Eletrônica] Se está linkando a biblioteca do Altium
- [Programação] Existência de uma brach master com o mais avançado funcionamento do projeto (mesmo que incompleto) e uma, ou mais, brach para desenvolver o código.
- Aproximação com o [Modelo de Repositório](https://gitlab.com/MinervaBots/modelo), de uma maneira geral.

## Quais Repositórios de categorias devemos avaliar?

- [Ant](https://gitlab.com/MinervaBots/mutant)
- [Beetles](https://gitlab.com/MinervaBots/beetles)
- **Eletrônica de Combate**: [ESC](https://gitlab.com/MinervaBots/coordenacao/eletro-prog/projetos/projeto-escargot) e [Controle](https://gitlab.com/MinervaBots/coordenacao/eletro-prog/projetos/projeto-controle)
- [LEGO](https://gitlab.com/MinervaBots/lego)
- [Sumô 3KGs](https://gitlab.com/MinervaBots/sumo-3kg)
- [Sumô Mini](https://gitlab.com/MinervaBots/ze-pequeno)
- [Trekking](https://gitlab.com/MinervaBots/trekking)



---



# WIKI

## Por que avaliar a wiki dos projetos?
Basicamente é o principal local que vai armazenar as informações do projeto. Sejam elas estáticas e dinâmicas. Assim, esse acompanhamento confirma que as seguintes coisas irão acontecer:
- Qualquer novo membro no projeto terá um suporte muito bom do que está acontecendo (principalmente calouros)
- Auxílio aos membros atuais em algo desenvolvido em períodos anteriores
- Auxílio aos membros quando precisarem revisar algo que eles mesmos fizeram
- O marketing terá um material conciso e organizado para as postagens
- Esse acúmulo de informações, nos farão cometer menos erros bobos por falta de avisos


Assim, sendo o local fixo que vai armazenar a documentação de literalmente tudo (eletrônica/programação/mecânica) de cada projeto ao longo de todos os períodos, deve haver um monitoramento para que os líderes e membros sigam uma organização que resista o máximo possível com o passar do tempo sem ficar confuso. 
Além disso, cada projeto acaba tendo suas peculiaridades porque nenhum projeto é igual ao outro, porém, uma certa essência deve ser mantida. 

> Você: Oks, mas que essência seria essa!?
> Eu: muito boa pergunta! ;p

Para isso que estamos desenvolvendo o modelo de wiki de projeto. Ele vai tentar contemplar pontos em comum dos proejtos de modo a deixar organizado. Não só a nível de documentações estáticas, mas informações dinâmicas também.

Tendo posse desse modelo, precisamos auxiliar e cobrar os líderes para eles seguirem junto aos membros.

### Periodicidade da Avaliação
Uma vez por mês, em sprints ares. Foi escolhido ser sprint sim e sprint não para, em combinação com a tarefa de avaliar os repositórios dos projetos, toda sprint ter um acompanhamento dos membros no GIT de forma geral. 

### Como usar o Card
Assim que os gestores forem definidos para avaliar seus projetos, seus nomes devem ser escritos na check-list referente ao projeto.
Esse é o gestor responsável por fazer todas as tarefas dessa checklist

## Como vamos avaliar?
Vamos avaliar cada wiki individualmente com base nos critérios listados, usando os comentários nesse card para expor a situação das wikis.
Os comentários devem seguir um padrão de colocar o nome do projeto antes de comentário e uma linha marcada para cada critério de avaliação.
Exemplo nos comentários.
Depois do comentário, o responsável deve trocar uma ideia com o líder. Seja cobrando dele uma wiki mais bem organizada e preenchida/ilustrada ou debatendo sobre uma possível mudança no modelo de wiki.
O Resultado dessa conversa deve ser adicionada no comentário referente à wiki desse projeto. Seja para marcar como "assunto resolvido" ou uma descrição do porque o modelo de wiki deve ser modificada.

## O que devemos avaliar?

- Atividade constante nas wikis dinâmicas dos projetos. Como será o relatório de período e as tarefas só podem ser colocadas em validado se tiver uma documentação na wiki, precisa estar constantemente atualizada.
- Participação dos membros:
  - O que cada membro do projeto ficou responsável em documentar na parte estática?
  - Eles estão fazendo?
- Descrições que não estejam incompletas ou sem referências (sempre tem como linkar algo porque agnt nunca tira algo totalmente da nossa cabeça).
- Parte excessivamente de texto (vai desestimular o pessoal de ler)
- Se não tem algo estático faltando:
  - Wiki geral
  - Wiki de cada repositório
- Aproximação com o [Modelo de Wiki](https://gitlab.com/MinervaBots/modelo/wiki/-/wikis/0.-Home), de uma maneira geral.

## Quais wikis devemos avaliar?

- [Ant](https://gitlab.com/MinervaBots/mutant/Documentacao/-/wikis/home)
- [Atlas](https://gitlab.com/MinervaBots/trekking/software/trekking_ws/-/wikis/home)
- [Beetles](https://gitlab.com/MinervaBots/beetles/gerenciamento/-/wikis/0.Home)
- **Eletrônica de Combate**: [ESC](https://gitlab.com/MinervaBots/coordenacao/eletro-prog/projetos/projeto-escargot) e [Controle](https://gitlab.com/MinervaBots/coordenacao/eletro-prog/projetos/projeto-controle)
- [LEGO](https://gitlab.com/MinervaBots/lego/wiki-lego/-/wikis/Wiki-LEGOs)
- [Sumô 3KGs](https://gitlab.com/MinervaBots/sumo-3kg/wiki/-/wikis/home)
- [Sumô Mini](https://gitlab.com/MinervaBots/ze-pequeno/gerenciamento/-/wikis/home)
