Enquanto dava os retoques finais na primeira versão funcional do bulletty, reparei que o Hacktoberfest — o evento anual organizado pela DigitalOcean onde os participantes ganham t-shirts ao completar com sucesso seis pull requests (PRs) durante outubro — estava a aproximar-se. Pensei que esta poderia ser uma ótima oportunidade para envolver a comunidade, melhorar o leitor de feeds e aumentar a visibilidade do projeto. Para me preparar, organizei a secção de Issues no GitHub, criando uma issue por funcionalidade do roadmap e para bugs, adicionando descrições detalhadas e imagens. Depois, etiquetei-as adequadamente com labels como “Improvements”, “Bugs”, “Good First Issue” e “Hacktoberfest”. Foi elaborado um ficheiro CONTRIBUTING genérico, delineando os procedimentos para submeter alterações, reportar bugs e abrir PRs.\n\nPoucos dias antes de outubro, promovi o projeto nas minhas contas pessoais nas redes X, Bluesky e Mastodon, e também publiquei no subreddit /r/hacktoberfest. Ao descobrir o servidor oficial do Discord do Hacktoberfest, publiquei lá também para recrutar colaboradores. Tentei até o Hacker News, embora tenha gerado menos envolvimento. Em poucos dias, o número de estrelas no GitHub subiu para quase cem, e recebi várias respostas em diferentes plataformas, o que considerei um forte sucesso inicial.\n\nNo entanto, assim que outubro começou, fui rapidamente confrontado com inúmeros pedidos de colaboradores a pedir para lhes serem atribuídas issues sem qualquer discussão prévia. Esta abordagem parecia prematura e arriscada, pois atribuir issues sem compreender o plano do proponente poderia bloquear outros de contribuir. Por isso, atualizei o ficheiro CONTRIBUTING com diretrizes claras a enfatizar que os colaboradores devem primeiro envolver-se numa discussão sobre a implementação pretendida. Só após diálogo suficiente atribuiria issues. Para correções de bugs, permiti submeter PRs sem discussão prévia desde que os colaboradores explicassem as suas alterações detalhadamente.\n\nUma interação em particular destacou-se quando um utilizador a pedir atribuição mencionou um “conhecimento”, o que me levou a suspeitar da utilização de algum fluxo de trabalho assistido por IA ou “vibe-coding”. Após confirmação, revisei ainda mais as diretrizes do CONTRIBUTING para abordar código gerado por IA. Declarei que não baniria a IA completamente, mas que PRs puramente gerados por IA não seriam aceites. Os colaboradores devem divulgar o uso de IA, assumir responsabilidade pelas suas submissões e estar preparados para revisões rigorosas do código. O uso não divulgado de IA seria considerado desonesto e levaria ao encerramento do PR. Partilhei a minha visão de que, embora eu próprio use ferramentas de IA, delegar implementações inteiras à IA sem compreensão genuína é problemático.\n\nEsta suspeita foi reforçada quando o utilizador submeteu um PR que não compilava, carecia de formatação adequada apesar das instruções explícitas, continha commits com títulos pobres e inconsistências como mudar o nome de um método sem atualizar a definição do seu trait. Estes sinais apontavam para uma tentativa automatizada de geração de código. Fechei o PR e pedi contribuições mais cuidadosas. Além disso, algumas issues receberam “planos de ataque” vagos que pareciam gerados por IA e sem sentido, destacando um desafio em filtrar entradas de baixa qualidade.\n\nRefletindo sobre o feedback de outros mantenedores, parece que o Hacktoberfest frequentemente atrai PRs spam focados em alterações triviais, como correções de erros tipográficos ou simples alterações de comentários. Com o avanço dos modelos de IA capazes de reescrever grandes secções de código, manter projetos open source está a tornar-se mais complexo. Embora a IA possa lidar bem com tarefas simples, grandes refatorações conduzidas por IA correm o risco de introduzir bugs difíceis de detetar e obscurecer a semântica do código. Ao contrário dos programadores humanos, a IA não tem a compreensão conceptual do software como “construção de teoria”, uma noção enfatizada por Peter Naur. Além disso, a comunidade tem dificuldade em concordar sobre o que constitui trabalho gerado por IA versus humano, complicando a moderação.\n\nApesar destes desafios, houve contribuições valiosas durante o Hacktoberfest. Após o influxo inicial de PRs questionáveis, colaboradores mais empenhados submeteram melhorias significativas. Um exemplo notável foi a adição de navegação para o próximo e anterior no leitor, uma funcionalidade crítica anteriormente ausente. A implementação ensinou-me também sobre o uso do Rc<T> do Rust para contagem de referências, enriquecendo o meu entendimento.\n\nNo geral, o Hacktoberfest trouxe tanto oportunidades como obstáculos. Catalisou o envolvimento da comunidade e acelerou o desenvolvimento de funcionalidades, mas também introduziu complexidades relacionadas com a qualidade das contribuições, especialmente com a codificação assistida por IA. Comunicação clara, diretrizes rigorosas e processos de revisão vigilantes provaram ser essenciais para manter a integridade do projeto durante o evento.
