GitHub Projects — como cada time usa

GitHub Projects é nossa ferramenta de visualização cross-empresa. Cada empresa tem sua ferramenta interna pra gestão detalhada (1BMG=Jira, Creator Reply/Beats=Notion, etc.), mas todas as Issues importantes também aparecem num Project unificado que só o Fred vê por completo.

O que é

Um Project no GitHub é um kanban/roadmap que cruza todos os repos da organização. Acessa em:

→ github.com/orgs/emotionstudios-git/projects/1

Tem views prontas:

Kanban por empresa — agrupa Issues/PRs por empresa
Roadmap — linha do tempo visual (Gantt)
Bloqueados — filtrados por label blocked
Deadlines dessa semana — filtrados por data

Pra que serve cada empresa

Cada empresa usa sua ferramenta interna pra granularidade:

Empresa	Ferramenta	Pra quê
1BMG	Jira (`emotionstudios.atlassian.net`)	Tarefas detalhadas, sub-tasks, tempo
Creator Reply + Beats	Notion	Backlog leve, discussão abierta
Oinc	(a definir)	—
AdsVenture	(a definir)	—
Skopia	(a definir)	—

GitHub Projects NÃO substitui essas ferramentas. Serve pra:

👀 Fred visualizar tudo de uma vez (cross-empresa)
🔗 Linkar código a tarefa (PR referencia Issue do Project)
⚠️ Alinhamento cross-empresa (dependência Oinc → 1BMG, por exemplo)

Fluxo: Issue → Project → PR

1. Cria Issue no repo da tua empresa

Pra cada “unidade de trabalho” que vai consumir tempo/atenção, cria Issue no repo da empresa (não no Project diretamente — Issue vira item no Project).

Exemplo — Paulo vai trabalhar em fix do Apollo:

Via navegador: github.com/emotionstudios-git/1bmg/issues/new

Via Claude Code:

Abre Issue no repo 1bmg: "Fix paginação Apollo no sdr_engine".
Descrição: "API retorna 422 quando page=501. Adicionar exit
condition. Afeta: outbound diário."
Adiciona labels "bug" e "priority-high".

Template mental da Issue:

Título curto (até ~60 chars)
O que é + por que importa
Referência a tarefa externa se houver (Jira: 1BMG-42, Notion: link)
Labels: priority-high | priority-medium | priority-low, blocked, bug, feature, etc.

2. Issue entra no Project automaticamente

Graças a auto-add rules configuradas, toda Issue nova de qualquer repo vai pro Project “eMotion Studios — Portfolio” com:

Empresa preenchida automaticamente (1bmg, oinc-filmes, etc.)
Status inicial: ”📋 Todo”

Você não precisa adicionar manualmente.

3. Trabalha no código, abre PR

Cria branch, faz mudança, abre PR. Referencia a Issue na descrição do PR:

## O que é
Fix paginação Apollo no sdr_engine.

## Relacionado
Closes #42  ← isso linka Issue 42 com o PR

O Closes #42 tem poder: quando PR mergear, Issue #42 fecha automaticamente.

4. Move no Project

Pode mover o card no kanban via drag&drop ou assim:

Via UI:

Abre o Project
Arrasta o card de “Todo” pra “In Progress” ou “In Review”

Via Claude Code:

Move Issue #42 do 1bmg pra "In Review" no Project.

5. Fred vê o panorama

Fred abre Project, vê:

Quantas Issues abertas por empresa
Quais tão bloqueadas
Quais PRs esperando review
Deadlines chegando

Resolve alinhamentos em 5min sem precisar abrir 6 ferramentas diferentes.

Templates de Issue por empresa

1BMG (onde Paulo + Thalita mantêm código Python)

## Tarefa
<1-2 linhas descritivas>

## Contexto
<qual sub-projeto — outbound/inbound/claimradar/etc.>

## Critério de sucesso
<como vamos saber que tá feito>

## Jira relacionado
<se aplicável — ex: 1BMG-42>

## Prioridade estimada
- [ ] Alta (entra essa semana)
- [ ] Média (entra próximas 2 semanas)
- [ ] Baixa (backlog)

Oinc (Silas com conteúdo)

## O que entregar
<ex: "Template briefing Nike revisado">

## Pra qual cliente/canal
<ex: 3Palavrinhas, Nike, etc.>

## Deadline
<data se houver>

## Referências
<links pros docs/briefings existentes>

Creator Reply / Beats (João, produto novo)

## Hipótese / tarefa
<o que vamos testar/construir>

## Por que agora
<como isso encaixa no MVP roadmap>

## Output esperado
<entregável concreto>

## Notion relacionado
<link pro card do Notion se existir>

AdsVenture (Filipe, quando tiver tempo)

## Proposta
<descrição>

## ADR relacionado
<se tem decisão técnica — link pra knowledge-base/adrs/>

## Urgência
<típico: baixa, Filipe atua pontualmente>

Skopia (Fred gere por ora)

## Tarefa
<descrição>

## Impact federal contracts
<como afeta monitoramento SAM.gov>

Campos customizados no Project

Cada Issue no Project tem campos extras visíveis só lá (não no repo):

Campo	Valores	Quem preenche
Empresa	1BMG, Oinc, AdsVenture, Creator-Reply, Creator-Beats, Skopia, Holding	Auto-preenchido baseado no repo
Status	📋 Todo, 🔄 In Progress, 👀 In Review, ✅ Done, ⛔ Blocked	Você move manualmente
Priority	🔥 Urgent, ⬆️ High, ➖ Medium, ⬇️ Low	Você define ao abrir
Target date	Data	Opcional
Effort (days)	Número	Opcional — ajuda planejamento

Views pré-configuradas

Ao abrir o Project, as 4 views estão prontas:

📊 Kanban por empresa

Colunas: Todo → In Progress → In Review → Done

Pra quê: ver o trabalho em andamento de todo mundo.

🗺️ Roadmap

Linha do tempo visual. Issues com target date aparecem na linha do tempo.

Pra quê: planejar entregas dos próximos 30-90 dias.

⛔ Bloqueados

Filtra só Issues com status Blocked ou label blocked.

Pra quê: Fred identifica destravos urgentes.

📅 Deadlines dessa semana

Filtra Issues com target date nos próximos 7 dias.

Pra quê: priorização semanal.

Boas práticas

✅ Faça

Uma Issue por tarefa (não várias tarefas no mesmo Issue)
Fecha Issue via PR (Closes #42 na descrição)
Marca como blocked quando tá travado — Fred vê imediatamente
Atualiza target date quando a tarefa mudar de escopo
Consulta o Project antes de começar nova tarefa

❌ Não faça

Criar Issue só pra lembrar algo depois (isso é TODO pessoal, usa Jira/Notion da empresa)
Deixar Issue em In Progress semanas sem update — move pra Blocked ou fecha
Fechar Issue sem fechar PR relacionado (ou vice-versa)

Notificações

Você recebe email/notificação quando:

Alguém menciona você numa Issue (@silas)
Alguém atribui Issue a você
Alguém comenta em Issue que você criou ou tá participando

Ajusta em github.com/settings/notifications.

Dúvida comum

“Tenho que usar Jira E GitHub Projects?”

Sim, mas cada um tem papel distinto:

Jira (1BMG) — detalhe fino: sub-tasks, tempo estimado, comentários internos, workflow Agile
GitHub Projects — alto nível cross-empresa: Fred e coordenação vê o que importa

Regra: toda tarefa grande (vai consumir dia ou mais) vira Issue no repo. Tarefas pequenas (1h-algumas horas) podem ficar só no Jira/Notion sem replicar.

Próximos

→ Ritmo do time — rituais da semana/mês