Metodologia

Como os dados foram extraídos, tratados e investigados — passo a passo, com as fontes e as decisões que tornam a análise reprodutível e auditável.

Por que "individual" é a maior fatia?

No filtro por stream (mapa e todo o app), 'individual' é a maior fatia — e isso é esperado. Quase todo Internet-Draft nasce como submissão individual (draft-<autor>-tema). Só uma minoria é ADOTADA por um WG (IETF) ou RG (IRTF), sendo então republicada como draft-ietf-<wg>-… ou draft-irtf-<rg>-…. 'IETF'/'IRTF' contam apenas os drafts que já estão num grupo. Como a adoção é o grande gargalo (a 'mortalidade'), os individuais não-adotados são a maioria: ~21,5 mil de 35 mil (61%). O IRTF é pequeno (~300) porque pesquisa é uma fração da atividade. Portanto, individual ≫ IETF+IRTF é o próprio achado central do estudo, não um erro de dados.

Passo a passo: da coleta ao app

1. Fonte dos dados
Tudo vem do IETF Datatracker (base pública), via sua API REST. Recorte: Internet-Drafts de 2005 até a data da coleta. Endpoints usados: doc/document, docevent, documentauthor, relateddocument, group/group, group/rolehistory, e meeting/*.
2. Coleta (download bruto)
Princípio central: separar download de processamento. Baixa-se tudo cru primeiro e processa-se depois. Coletores idempotentes. Paginação estável com order_by=id (sem isso, a API derivava entre páginas e gerava duplicatas/omissões).
3. Parsing
Os JSONs crus viram tabelas colunares (parquet): drafts, authors, events, groups, roles, meetings, sessions, presentations, became_rfc e replaced_by.
4. Enriquecimento (a base por draft)
Junta-se tudo por documento: stream (com fallback por prefixo), nº de autores e organizações, país e continente do 1º autor (ISO2 + ccTLD), academia, revisões, is_wg/adopted, has_leader, presented, e marcadores LATAM/Brasil.
5. Classificação de desfecho
Cinco estados: virou RFC, foi substituído, expirou, foi descontinuado ou segue ativo. 'Morto' e 'substituído' são estados (não eventos); olha-se a transição mais recente. Expiração automática após ~185 dias.
6. Análises descritivas
Mortalidade por área, stream, continente e diversidade de organizações; o funil (submetido → adotado → RFC); as rotas até a RFC; e o recorte Brasil/LATAM.
7. Sobrevivência e modelos
Incidência cumulativa por Aalen-Johansen (riscos concorrentes), curvas Kaplan-Meier IETF×IRTF, Cox (hazard ratios) e regressão logística (odds ratios de adoção e de fracasso). Alimenta a página Estatística.
8. Tabela BI e carga
Tudo é achatado em uma tabela única (bi_drafts): uma linha por draft, ~30 colunas derivadas. Carregada no Supabase (Postgres), que serve o app.
9. Bases derivadas e agregação no servidor
No Postgres, funções (RPCs) agregam sob demanda — o navegador recebe só o resultado, não as 35 mil linhas. E tabelas auxiliares para análises que o bi_drafts não cobre (autoria, país, curvas e coeficientes).
10. Série de WGs/RGs ativos (dois métodos)
A contagem de grupos ativos por ano usa duas fontes emendadas. De 2011 em diante: estado oficial do charter no Datatracker (group/grouphistory + estado atual), datando a saída do estado 'active' pela hora real da transição — um grupo encerrado em 2016 deixa de ser contado a partir de 2016. Antes de 2011 o grouphistory não tem cobertura confiável, então 2005–2010 usam uma estimativa por atividade de documentos (grupos com nova submissão/revisão no ano). Consequência: há um degrau visível em 2010→2011, porque o proxy roda um pouco acima do oficial e 2011 é o ponto mais fraco do método oficial (a cobertura do histórico começa no meio daquele ano, subcontando o estado de fim de 2011). A série é, portanto, uma referência de ordem de grandeza da população de grupos, não um censo exato ano a ano.

Decisões de tratamento

Classificação de stream (por que existe 'individual')

Stream é o fluxo/dono do documento (IETF, IRTF, IAB, Independent/ISE, ou individual). Para a maioria dos drafts individuais o campo vem vazio.
Quando vazio, classificamos pelo prefixo do nome: draft-ietf-* → IETF, draft-irtf-* → IRTF, draft-iab-* → IAB, senão 'individual'.
'Individual' = submissão que não foi adotada por um grupo. É a categoria mais numerosa por definição do processo — ver a nota acima.

Inferência de geografia (país/LATAM/Brasil)

O país do 1º autor vem do campo país e, como reforço, do ccTLD do e-mail. Normalizamos variações ('US', 'United States', 'P.R. China'…) para um código ISO.
É um PISO: só ~59% dos drafts têm país identificado; quem usa e-mail genérico sem país não é detectado. A participação real é maior.
Descartamos ccTLDs 'vanity' (.io, .ai, .tv…) que não representam participação daquele território.

Recorte temporal e censura

A censura das análises de sobrevivência usa 31/12/2025; o app mostra a data da coleta como referência de observação.
Borda direita: drafts recentes ainda sem desfecho não são fracasso — só não tiveram tempo (anos recentes não são comparáveis para conversão).
Borda esquerda: 2005 (início do recorte) fica inflado, pois acumula documentos antigos cujo registro no Datatracker só aparece a partir dali.

Limitações conhecidas

Geografia é um piso; 'dead' é um piso; 'replaced' depende da relação replaces.
Correlação ≠ causalidade: revisões, liderança e apresentação estão associados ao sucesso, mas parte da seta causal aponta no sentido inverso.

Bases construídas (Supabase)

bi_drafts — Base principal — 1 linha por draft (~35 mil), ~30 colunas derivadas.
bi_country · bi_draft_country — País do 1º autor: agregado e por-draft (alimenta o mapa e o clique→lista).
bi_survival · bi_models — Curvas de incidência cumulativa e coeficientes dos modelos (odds/hazard ratios).
bi_persistence · bi_attempts · bi_learning · bi_funnel — Vínculo de autoria (persistência) e o funil de adoção (cadeia replaces).
RPCs (bi_dashboard, bi_insights, bi_map, bi_agg…) — Agregação feita no Postgres, sob demanda, respeitando os filtros.

Fonte: IETF Datatracker. Pipeline reprodutível em Python (coleta → parsing → enriquecimento → análises → sobrevivência → tabela BI), com diário de decisões.