Bus factor — por que precisamos de co-mantenedores¶

Diátaxis: explanation. Para se candidatar, abra issue usando o template .github/ISSUE_TEMPLATE/co_maintainer_application.md.

O que é bus factor¶

Bus factor é o número mínimo de pessoas que precisam ser atropeladas por um ônibus para o projeto parar. Bus factor = 1 significa que uma única pessoa detém conhecimento ou acesso crítico — se ela some, o projeto morre.

Anotae está em bus factor = 1 desde o início (Carlos E. F. de Ávila / Sciereli HDC). Isso é um risco para:

Profissionais SUS que dependem do app no dia a dia.
Pacientes cujos vaults ficam órfãos se o mantenedor some.
Reputação de software open-source que se propõe a ser uma ferramenta clínica séria.

Por que ainda estamos em bus factor 1¶

Honestamente: porque o projeto nasceu há pouco tempo (M0 em abril/2026) e o piloto está em uma única regional (APS/DF). Convidar co-mantenedor antes de um produto minimamente funcional seria atrito.

Com v0.9.0-beta4 o produto entrou num platô estável — 660+ testes, 24 PRs de polimento sequenciais, RFC-002/003/004 fechadas. Hora de abrir.

Critérios para co-mantenedor¶

Não é entry-level. Esperamos que o candidato:

Tenha contribuído com pelo menos 3 PRs mesclados em áreas distintas (UI, persistência, docs).
Entenda CLAUDE.md §2 — as restrições invioláveis. Não pode ser flexibilizada por nenhum motivo.
Tenha disponibilidade real (~5h/semana) — bus factor 2 imaginário não conta.
Aceite o DCO em todo commit + chave GPG para assinar tags.
Idealmente, atue ou tenha atuado no SUS — entende o contexto clínico de UBSs.

O que damos¶

Mentoria durante trial de 30 dias.
Permissão de revisar PRs do Anotae.
Após trial, permissão de merge + voz em RFCs.
Atribuição em MAINTAINERS.md (formato kernel-style — área de responsabilidade + GPG fingerprint).

O que esperamos do co-mantenedor¶

Revisão de PR com SLA de 5 dias úteis.
Disponibilidade pra responder issue de segurança em 48h (e encaminhar pra SECURITY.md se for sensível).
Aderência a CODE_OF_CONDUCT.md — o ambiente de trabalho precisa ser bom para outros contribuidores.
Nunca trabalhar com dados reais de paciente em ambientes não-isolados — usar fixtures sintéticas em tests/fixtures/.

O que NÃO esperamos¶

Disponibilidade 24/7.
Conhecimento de toda a stack — bem-vindos especialistas em recortes (só UI, só backend, só docs).
Compromisso financeiro — projeto é OSS não-comercial.

Como nos protegemos enquanto bus factor = 1¶

Mesmo com mantenedor único, mitigamos com:

Auto-merge documentado quando bus factor=1 (CLAUDE.md §2.4): PRs do mantenedor não exigem revisão de outro humano (que não existe), mas precisam passar 100% nos quality gates do CI.
CHANGELOG.md exaustivo: alguém futuro consegue reconstituir decisões e estado.
ADRs em docs/explanation/: contexto de cada decisão grande.
Migrations versionadas + schema.md gerado: schema é fonte única de verdade reproduzível.
Sigstore attestations: releases são auditáveis publicamente via Rekor — mesmo se a chave GPG do mantenedor for comprometida, o histórico é verificável.
Vault 100% local cifrado: dados de usuários nunca dependem de infraestrutura mantenedor-controlada (não há servidor).

Esses fatores mitigam o risco operacional (continuidade do software). Não mitigam o risco humano (overload do mantenedor).

Como se candidatar¶

Leia CLAUDE.md inteiro (especialmente §2 e §10).
Leia CONTRIBUTING.md.
Mande pelo menos 3 PRs em áreas distintas.
Abra issue com template co_maintainer_application.md.

Profissionais SUS têm prioridade mesmo com pouca experiência open-source — damos mentoria. Especialistas em UI, segurança ou DevOps também são bem-vindos.

Quando reabrir esta nota¶

Quando bus factor virar 2 → atualizar CLAUDE.md §0 + esta página + MAINTAINERS arquivo (criar).
Quando bus factor virar 3+ → revisar política de auto-merge, exigir revisão humana em PRs com mudança de schema/cripto/IA local.
Se o número de mantenedores precisar diminuir → documentar saída em CHANGELOG.md e convidar substituto.