Métricas de baseline

Calculadas a partir de 500 PRs mergeados em getsentry/sentry ao longo de uma janela de 90 dias.

Distribuição do tempo até o merge

Percentil	Tempo até o merge (horas)
Mediana (P50)	4,98
P75	22,72
P90	70,54
Média	22,12

A razão P90/mediana de 14,2x revela uma cauda longa: enquanto a maioria dos PRs é mergeada em poucas horas, os 10% mais lentos levam quase 3 dias. A média (22,12h) sendo puxada bem acima da mediana (4,98h) confirma essa assimetria à direita.

Atividade de revisão

Métrica	Valor
Mediana de eventos de revisão por PR	2,0
Média de eventos de revisão por PR	3,46
Taxa formal de CHANGES_REQUESTED	0,2%
Mediana de rodadas de revisão	0,0
Média de rodadas de revisão	0,0

A taxa quase nula de CHANGES_REQUESTED é notável. A cultura de revisão do Sentry parece favorecer comentários inline e aprovação com comentários, em vez de solicitações formais de mudança. Isso significa que a contagem de eventos de revisão isoladamente subestima o atrito real de revisão — o sinal verdadeiro está no conteúdo dos comentários, não nos estados de revisão.

Distribuição de tamanho dos PRs

Métrica	Valor
Mediana de arquivos alterados	2,0
P90 de arquivos alterados	9,0
Mediana de churn (linhas)	51,5
P90 de churn (linhas)	344,0

A maioria dos PRs do Sentry é pequena: a mediana altera apenas 2 arquivos com cerca de 52 linhas de churn.

Segmentação por tamanho

Os PRs são segmentados em três faixas:

Segmento	Definição	Contagem	Participação	Mediana do tempo até o merge	Mediana de revisões
Pequeno	≤3 arquivos E ≤80 de churn	261	52,2%	1,66h	1,0
Grande	≥10 arquivos OU ≥400 de churn	68	13,6%	22,52h	5,0

Observações principais:

• PRs grandes levam 13,6x mais tempo para serem mergeados do que PRs pequenos (22,52h contra 1,66h)
• PRs grandes recebem 5x mais eventos de revisão (mediana de 5,0 contra 1,0)
• Mais da metade (52,2%) de todos os PRs é pequena, sugerindo que o fatiamento de PRs já é prática comum
• Os 13,6% de PRs grandes provavelmente respondem por uma parcela desproporcional do esforço total de revisão

Atrito por tipo de mudança

Usando prefixos de conventional commits extraídos dos títulos dos PRs:

Tipo	Contagem	Taxa de alto atrito
feat	166	38,6%
perf	12	25,0%
ref	98	22,4%
fix	131	17,6%
chore	42	14,3%
test	8	12,5%

PRs de funcionalidade têm 2,2x mais probabilidade de serem de alto atrito do que PRs de correção. Isso está alinhado com a expectativa de que novas funcionalidades introduzem mais discussão de design do que correções pontuais de bugs.

Atrito por engajamento de revisores

Faixa	Contagem	Taxa de alto atrito
0-1 eventos de revisão	varia	9,8%
2-3 eventos de revisão	varia	varia
4-6 eventos de revisão	varia	varia
7+ eventos de revisão	varia	mais alta

A relação entre engajamento de revisão e atrito é mecânica (a contagem de revisões é um componente do score de atrito), mas a segmentação por tamanho mostra que o tamanho determina o atrito mais do que qualquer outro fator: 57,4% dos PRs grandes são de alto atrito contra apenas 9,8% dos PRs minúsculos.

Resumo

A baseline conta uma história clara: o processo de revisão do Sentry é eficiente para PRs pequenos e bem escopados (mediana de 1,66h de tempo até o merge), mas tem dificuldades com mudanças grandes e complexas (mediana de 22,52h de tempo até o merge). A taxa formal quase nula de CHANGES_REQUESTED sugere que o atrito se manifesta por meio de threads de comentários em vez de estados formais de revisão — razão pela qual a análise de temas do conteúdo real dos comentários é essencial para entender as verdadeiras fontes de atrito de revisão.