RFC-005: Processo de Code Review e SLAs

Campo	Valor
Status	Draft
Author	Time de Tecnologia
Created	2026-02-05
Updated	2026-02-05
Reunião	A ser agendada
Deciders	Todo o time técnico

Status

🟡 Draft - RFC em elaboração, aguardando apresentação

Contexto e Problema

Processo de code review documentado em docs/development/code-review.md, mas falta:

SLAs formais para tempo de resposta
Número mínimo de aprovadores por tipo de mudança
Processo de escalação quando SLA não é cumprido
Métricas e tracking de efetividade do processo
Quality gates automatizados no GitHub

Por que resolver isso agora?

PRs ficam esperando review por dias
Bloqueio de trabalho (waiting on review)
Inconsistência em quem aprova o quê
Falta clareza sobre urgência
Time crescendo, necessidade de processo escalável

Impacto de não resolver

Frustração do time com wait times
Trabalho bloqueado desnecessariamente
PRs grandes acumulam (ninguém quer revisar)
Qualidade inconsistente de reviews
Bottlenecks em pessoas específicas

Documentação relacionada: - docs/development/code-review.md - Processo atual detalhado - docs/development/git-workflow.md - Workflow de PRs - docs/getting-started/team-agreements.md - Acordos do time

Proposta de Solução

Formalizar SLAs de code review com enforcement via métricas e automação.

SLAs por Prioridade

P0 - Crítico (Hotfix): - Primeiro feedback: < 2 horas - Aprovação final: < 4 horas - Aprovadores: 1 senior/lead - Notificação: Slack + menção direta

P1 - Alta (Feature importante, bug crítico): - Primeiro feedback: < 8 horas (mesmo dia útil) - Aprovação final: < 24 horas - Aprovadores: 1 aprovador - Notificação: Slack

P2 - Normal (Feature regular, refactor): - Primeiro feedback: < 24 horas - Aprovação final: < 48 horas - Aprovadores: 1 aprovador - Notificação: GitHub notifications

P3 - Baixa (Docs, typos): - Primeiro feedback: < 48 horas - Aprovação final: < 72 horas - Aprovadores: 1 aprovador - Notificação: GitHub notifications

Número de Aprovadores

1 Aprovador: - Bug fixes - Features normais - Refatorações pequenas/médias - Docs - Testes

2 Aprovadores: - Mudanças arquiteturais - Breaking changes em APIs - Mudanças em segurança (auth, permissions) - Migrations de banco (production) - Mudanças em CI/CD crítico

Todo o time (consenso): - Mudanças em processo (deve passar por RFC) - Escolha de tecnologias principais - Mudanças em infraestrutura core

Tamanho de PR

Pequeno (< 200 linhas): - ✅ Ideal, review rápido - SLA normal

Médio (200-400 linhas): - ⚠️ Ok, pode demorar mais - SLA +50%

Grande (400-600 linhas): - ⚠️ Considere quebrar - SLA +100% - Requer justificativa no PR

Muito Grande (> 600 linhas): - ❌ Deve ser quebrado - Exceções: migrations geradas, código gerado, refactor mecânico - Requer aprovação de lead para merge

Processo de Escalação

Se SLA não cumprido:

+4h após deadline: Bot comenta no PR lembrando reviewers
+8h após deadline: Menção em canal Slack #tech
+24h após deadline: Escalar para Tech Lead
+48h após deadline: Tech Lead faz review ou designa reviewer

Exceções: - Fins de semana não contam - Feriados não contam - Reviewer em férias (auto-assign outro)

Automação GitHub

Required checks:

# Branch protection rules
Required reviews: 1
Dismiss stale reviews: true
Require review from code owners: false (usar CODEOWNERS para áreas específicas)
Require status checks:
  - lint
  - tests
  - coverage-check

CODEOWNERS:

# Áreas críticas requerem review específico
/app/security/**           @tech-lead @security-team
/infrastructure/**         @devops-team
/app/payments/**          @tech-lead @backend-senior
/.github/workflows/**     @devops-team
/migrations/**            @tech-lead

GitHub Actions (SLA monitoring):

name: PR Review SLA Check

on:
  pull_request:
    types: [opened, ready_for_review]
  schedule:
    - cron: '0 */4 * * *'  # Every 4 hours

jobs:
  check-sla:
    runs-on: ubuntu-latest
    steps:
      - name: Check PR age
        run: |
          # Calculate time since PR opened
          # Comment if SLA exceeded
          # Mention reviewers in Slack

Checklist de Review

Funcionalidade: - [ ] Código funciona conforme descrito - [ ] Edge cases cobertos - [ ] Erros tratados apropriadamente

Qualidade: - [ ] Código legível e bem estruturado - [ ] Nomes claros de variáveis/funções - [ ] Sem duplicação desnecessária - [ ] Segue padrões do projeto

Testes: - [ ] Testes adequados adicionados - [ ] Coverage não diminuiu - [ ] Testes são determinísticos

Segurança: - [ ] Sem secrets hardcoded - [ ] Input validado - [ ] Autenticação/autorização ok

Performance: - [ ] Sem N+1 queries óbvias - [ ] Queries otimizadas

Tipos de Comentários

[nit] - Sugestão menor, não bloqueante

[question] - Pergunta para entender

[suggestion] - Sugestão de melhoria

[blocker] - Deve ser resolvido antes do merge

[praise] - Reconhecer código bom!

Métricas

Tracking mensal: - Tempo médio para primeiro feedback - Tempo médio para aprovação final - % de PRs dentro do SLA - Tamanho médio de PR - Número de ciclos de review por PR

Dashboards: - GitHub Insights - Métricas customizadas via GitHub API - Alertas no Slack para SLAs quebrados

Alternativas Consideradas

Opção 1: SLAs mais agressivos (< 4h first response)

Prós: - PRs movem mais rápido - Menos bloqueio

Contras: - Interrupção constante - Difícil de cumprir para time pequeno - Burnout de reviewers

Por que não escolhemos: 24h é mais realista e sustentável.

Opção 2: Sempre 2+ aprovadores

Prós: - Mais olhos, mais qualidade - Conhecimento distribuído

Contras: - Muito lento - Bottleneck - Overhead desnecessário para mudanças simples

Por que não escolhemos: 1 aprovador é suficiente para maioria dos casos.

Opção 3: Aprovação automática após X dias

Prós: - Garante que PR não fica bloqueado indefinidamente

Contras: - Código ruim pode passar - Remove accountability - Não resolve problema real

Por que não escolhemos: Processo de escalação é melhor solução.

Análise de Impacto

Impacto Técnico

PRs movem mais rápido (menos bloqueio)
Reviewers têm expectativas claras
Automação reduz carga manual
Métricas permitem melhoria contínua

Impacto em Negócio

✅ Velocity aumentada
✅ Menos frustração do time
✅ Qualidade mantida/melhorada
✅ Onboarding (processo claro)
⚠️ Setup inicial de automação

Riscos

Risco: SLAs criam pressão e reviews apressados

Mitigação: SLAs são para primeiro feedback, não aprovação. Reviews ruins são identificados em métricas.

Plano de Implementação

Fase 1: Configuração (Semana 1)

Configurar branch protection rules
Criar CODEOWNERS
Setup de automação (SLA bot)
Documentar processo

Fase 2: Pilot (Semanas 2-3)

Aplicar SLAs em modo soft (avisar mas não bloquear)
Coletar feedback
Ajustar thresholds

Fase 3: Enforcement (Semana 4)

Ativar enforcement
Monitorar métricas
Escalar quando necessário

Fase 4: Otimização (Mês 2-3)

Analisar métricas
Identificar bottlenecks
Ajustar processo conforme dados

Métricas de Sucesso

Após 1 mês: - ✅ 80%+ PRs dentro do SLA - ✅ Tempo médio de review reduzido em 30% - ✅ Zero PRs bloqueados > 72h

Após 3 meses: - ✅ 90%+ PRs dentro do SLA - ✅ Tamanho médio de PR < 300 linhas - ✅ Satisfação do time com processo (+20%)