Quais Foram As Contribuições

Entendendo contribuições em projetos colaborativos

Quando alguém entra num projeto — seja código aberto, pesquisa acadêmica ou até um wiki — a primeira pergunta que surge costuma ser: quais foram as contribuições de cada pessoa envolvida? A resposta nunca é simples. Contribuição pode ser código, documentação, revisão de pull requests, tradução, reporte de bugs, mentoring ou simplesmente manter o projeto vivo quando ninguém mais responde nos issues. Eu já perdi tempo conta demais tentando rastrear quem fez o quê usando só o log do git. O resultado foi sempre incompleto porque committers de merge aparecem como autores de mudanças que não escreveram, e contribuidores que enviaram patches via issues são esquecidos completamente.

quais foram as contribuições e como rastrear de fato

O método mais direto começa no repositório. Abre o terminal, navega até a pasta do projeto e roda: git log --pretty=format:"%an" | sort | uniq -c | sort -rn Isso te dá uma lista ordenada por quantidade de commits. Funciona para uma visão geral rápida, mas tem limitações sérias. Um único commit enorme de refatoração pesa o mesmo que dez correções de typo. E commits de merge distorcem tudo. Para corrigir isso, usa: git log --pretty=format:"%an" --no-merges | sort | uniq -c | sort -rn Agora os merges somem da contagem. Ainda assim, contribuidores externos que enviaram patches sem commit direto no repositório não aparecem. Aí entra o GitHub Contributions Graph ou ferramentas como gh-api, que cruzam dados de PRs, issues e reviews. Na prática, eu uso um script que junta três fontes: commits diretos, pull requests abertos e fechados, e mentions em issues. O script consulta a API do GitHub com curl e processa JSON com jq. O resultado leva uns 40 segundos pra rodar num repo médio, mas a precisão é muito melhor do que olhar só os logs. O que ninguém te conta é que contribuições não lineares valem tanto quanto código. Uma pessoa que revisou 200 pull requests em seis meses tem impacto maior do que outra que fez 50 commits próprios e sumiu. O gráfico do GitHub mostra apenas o segundo caso. Por isso, ao responder quais foram as contribuições de uma equipe, inclua métricas qualitativas: tempo de resposta em reviews, qualidade das revisões, manutenção de issues abertas há anos. Um problema que encontrei na prática foi com projetos que migraram de SVN para Git. O histórico de migração veio quebrado e cerca de 30% dos autores antigos desapareceram das estatísticas. A solução foi usar o git-svn com a opção --show-custom-props para recuperar os autores originais do SVN e mesclar com os dados do git. Depois de rodar, identifiquei os autores perdidos exportando o arquivo authors-transform.txt e comparando com a base antiga.

Ferramentas úteis e seus pontos cegos

Existem plataformas como All Contributors, thatcontributed.to e Open Hub. Todas ajudam, mas nenhuma é perfeita. O All Contributors depende de pessoas adicionarem tags manualmente nos PRs, o que raramente acontece direito. O Open Hub calcula horas baseado em volume de código, o que penaliza fortemente trabalho de documentação e revisão. Se você quer algo rápido e gratuito, a própria interface do GitHub com o filtro de autores em Insights > Contributors já resolve 80% dos casos. Clique no link de cada autor para ver o perfil completo de atividades. Para projetos maiores com múltiplos repositórios, considere usar o GitHub Organization analytics ou o Ghstats, que agrega dados de múltiplas orgs. O setup leva cerca de 15 minutos e rodar consultas simples gasta créditos da API rapidamente se você não usar cache.

Pegadinhas comuns

Não confie cegamente em números brutos de commits. Um contributor com 500 commits pode ter sido o único com acesso de write e apenas fiz merge do trabalho alheo. Verifique o autenticidade dos commits com git log --author e confira se há padrões de co-autoria. Outro erro é ignorar contribuições fora do repositório principal. Many projects receive help via discussões em forum, traduções em plataformas externas, ou patches enviados por email. Essas contribuições não aparecem em nenhum gráfico. Anote manualmente essas fontes quando relevantes. Quando projetistas pedem quais foram as contribuições sem especificar o escopo, a tendência é dar uma lista genérica. Seja específico. Diga o período, o repositório, a métrica usada e as limitações conhecidas. Isso evita mal-entendidos e mostra que você entendeu a complexidade por trás dos números.