Resumo Técnico: SentTrack – Detecção de Gargalos Baseada em Sentimento em Repositórios de Issues do GitHub

Declaração do Problema

Equipes de engenharia de software dependem cada vez mais de threads de issues do GitHub para coordenar o trabalho, relatar bugs e negociar decisões técnicas. No entanto, as ferramentas existentes de saúde de repositório focam predominantemente em métricas de código, tratando as discussões de issues como secundárias. Os métodos atuais para identificar fricção no fluxo de trabalho — como retrospectivas periódicas ou curadoria manual de labels — são reativos e lentos para detectar problemas emergentes. Além disso, a análise automatizada de issues do GitHub enfrenta dois desafios específicos:

1. Metadados Inconsistentes: As labels do repositório (ex: bug, enhancement) são frequentemente esparsas, inconsistentes ou carecem de contexto sobre por que as issues permanecem não resolvidas.
2. Ruído de Mídia Mista: As threads de issues contêm um "ruído gerado por máquina" significativo (rastreios de pilha/stack traces, despejos de logs, trechos de código) que domina o volume de texto, mas não carrega intenção do usuário, fazendo com que modelos de linguagem padrão extraiam tópicos baseados em artefatos de código em vez de preocupações dos desenvolvedores.

Este artigo aborda a lacuna na identificação de gargalos sócio-técnicos ao responder a três perguntas de pesquisa (RQs):

• RQ1: Como um framework automatizado pode identificar ineficiências de fluxo de trabalho usando dados conversacionais em tempo real?
• RQ2: A análise de sentimento pode revelar sinais de risco mais cedo do que o gerenciamento tradicional baseado em labels?
• RQ3: Como a narrativa humana pode ser efetivamente isolada do ruído gerado por máquina para garantir que a extração de tópicos reflita a intenção real do desenvolvedor?

Metodologia: O Framework SentTrack

O SentTrack é um framework de lente dupla aplicado ao repositório de código aberto AvaloniaUI (aproximadamente 9.000 threads de issues). Ele combina um pipeline horizontal para modelagem de tópicos global e um pipeline vertical para análise de interação por thread.

1. Pipeline Horizontal (Modelagem de Tópicos)

Este pipeline processa o título e o corpo da issue para identificar tendências macro e temas técnicos recorrentes.

• Sumarização Focada em Intenção: Um Modelo de Linguagem de Grande Escala (LLM) traduz o texto bruto da issue em resumos limpos. O LLM é instruído a manter a intenção do desenvolvedor enquanto suprime artefatos de máquina (caminhos de arquivos, códigos hexadecimais, stack traces).
• Extração de Tópicos Contextualizada: A partir dos resumos limpos, o pipeline extrai frases de preocupação de nível médio (frases nominais de 3 a 6 palavras). Estas são guiadas por um perfil estático do projeto para garantir relevância de domínio (ex: "Rendering", "Cross-platform input") e situam-se em um nível de abstração entre labels genéricas e tokens de erro específicos.
• Agrupamento Semântico: As frases extraídas são incorporadas (embedded) usando um codificador ajustado por instrução, reduzidas via UMAP e agrupadas usando HDBSCAN. Esta abordagem identifica clusters de densidade sem exigir uma contagem pré-definida de clusters.

2. Pipeline Vertical (Dinâmica de Threads)

Este pipeline trata cada issue como uma sequência cronológica de comentários, em vez de um único documento.

• Classificação ABCDE: Cada comentário é classificado em uma das cinco categorias de interação baseadas no framework de interação colaborativa:
  • A (Agree/Concordar): Confirmação ou convergência.
  • B (Build/Construir): Evidência adicionada, proposta de correção ou explicação.
  • C (Chat/Conversar): Texto neutro ou que move a tarefa fracamente.
  • D (Different Perspective/Perspectiva Diferente): Desacordo, preocupação ou bloqueio.
  • E (Elicit/Induzir): Pergunta ou pedido de esclarecimento.
• Inferência de Resultado: O resultado da thread é determinado pela última interação na sequência. Sequências que terminam em A ou B são classificadas como resolvidas; D ou E como estagnadas; e C como neutras.

3. Mecanismo de Detecção de Gargalos

Um mecanismo de pontuação ponderada funde dados de ambos os pipelines para gerar um escore de gargalo ($B_i$) interpretável para cada issue:
$$B_i = 0.35N_i + 0.30S_i + 0.25R_i + 0.10L_i$$
Onde:

• $N_i$: Negatividade agregada (média, máxima e razão de comentários negativos).
• $S_i$: Indicador binário de estagnação.
• $R_i$: Pontuação de lacuna de resolução (resolution gap).
• $L_i$: Comprimento da thread normalizado.

O mecanismo também atribui categorias compostas de gargalo (ex: Negativo, Estagnado, Longo, Não Resolvido) para ajudar os mantenedores na priorização da triagem.

Principais Resultados

Aplicado ao corpus do AvaloniaUI, o SentTrack produziu os seguintes achados:

• Agrupamento de Tópicos: A partir das primeiras 3.608 issues, o pipeline gerou 613 clusters semânticos. No entanto, uma análise de taxa de descoberta revelou uma limitação estrutural: o LLM gerou aproximadamente duas variantes únicas de tópicos por issue (ex: "falha de inicialização do previewer XAML" vs. "crash do processo designer"), resultando em mais de 1.800 clusters para o corpus completo. Isso sugere que o pipeline produz um número de ordens de magnitude maior de clusters do que o acionável para mantenedores, indicando a necessidade de restrições de vocabulário ou um passo de redução de tópicos.
• Resultados de Threads: Em todo o corpus, 49% das threads terminaram em estagnação (D ou E), 38% em comentários neutros e apenas 13% alcançaram resolução (A ou B).
• Sinais de Gargalo: A lacuna de resolução foi identificada como o sinal de gargalo dominante. Embora a negatividade seja um fator, a categoria de gargalo composto mais frequente foi "Estagnado e Longo e Não Resolvido". Isso indica que o risco primário não é a negatividade emocional, mas sim discussões prolongadas e sem direção que falham em convergir.
• Métricas Diagnósticas: A Taxa de Resolução de Perguntas (QRR) e a Taxa de Captura de Preocupações (CCR) foram menores do que o desejado, indicando que perguntas e preocupações frequentemente aparecem nas threads, mas não são seguidas por uma resolução construtiva.

Significância e Alegações

O artigo alega que o SentTrack demonstra com sucesso que dados conversacionais em tempo real podem revelar a fricção no fluxo de trabalho que as labels tradicionais e as revisões periódicas não detectam.

• Abordagem à RQ3: O framework isola com sucesso a narrativa humana do ruído de máquina através da sumarização de intenção focada em LLM, permitindo que a extração de tópicos subsequente reflita as preocupações dos desenvolvedores em vez de artefatos de código.
• Abordagem às RQ1 & RQ2: O pipeline vertical prova que a classificação ABCDE simples, baseada em regras, pode produzir sinais interpretáveis ao nível da thread sem inferência pesada de LLM, revelando que a estrutura da conversa é tão crítica quanto o conteúdo do texto para a confiabilidade.
• Sinal Unificado: A principal contribuição é um pipeline de ponta a ponta interpretável que vincula tópicos técnicos, resultados de threads e escores de risco de gargalo. Isso fornece aos mantenedores uma visão unificada de o que está quebrando e onde na comunidade isso está acontecendo.

Os autores concluem que, embora a implementação atual sofra com a fragmentação excessiva de tópicos, a premissa central se mantém: combinar a modelagem de tópicos horizontal com a análise vertical de threads gera sinais mais precoces e interpretáveis de quebra de fluxo de trabalho do que métricas de código ou labels manuais isoladamente. O caminho imediato envolve a consolidação do espaço de clusters através de uma fase dedicada de redução de tópicos.