Alors que je mettais la touche finale à la première version fonctionnelle de bulletty, j'ai remarqué que Hacktoberfest — l'événement annuel organisé par DigitalOcean où les participants gagnent des t-shirts en réalisant avec succès six pull requests (PR) durant le mois d'octobre — approchait. J'ai pensé que cela pourrait être une excellente occasion d'impliquer la communauté, d'améliorer le lecteur de flux et d'accroître la visibilité du projet. Pour me préparer, j'ai organisé la section Issues sur GitHub, créant une issue par fonctionnalité de la feuille de route et pour les bugs, ajoutant des descriptions détaillées et des images. Je les ai ensuite étiquetées de manière appropriée avec des labels comme « Améliorations », « Bugs », « Bonne première issue » et « Hacktoberfest ». Un fichier CONTRIBUTING générique a été rédigé, décrivant les procédures pour soumettre des modifications, signaler des bugs et ouvrir des PR.\n\nQuelques jours avant octobre, j'ai promu le projet sur mes comptes sociaux personnels sur X, Bluesky et Mastodon, et j'ai également posté sur le subreddit /r/hacktoberfest. En découvrant le serveur Discord officiel de Hacktoberfest, j'y ai aussi posté pour recruter des contributeurs. J'ai même essayé Hacker News, bien que cela ait généré le moins d'engagement. En quelques jours, le nombre d'étoiles GitHub est monté à près de cent, et j'ai reçu de nombreuses réponses sur diverses plateformes, ce que j'ai considéré comme un fort succès initial.\n\nCependant, une fois octobre commencé, j'ai rapidement été confronté à de nombreuses demandes de contributeurs souhaitant se voir attribuer des issues sans aucune discussion préalable. Cette approche m'a semblé prématurée et risquée, car attribuer des issues sans comprendre le plan du proposant pouvait bloquer d'autres contributions. J'ai donc mis à jour le fichier CONTRIBUTING avec des directives claires insistant sur le fait que les contributeurs doivent d'abord engager une discussion sur leur implémentation prévue. Ce n'est qu'après un dialogue suffisant que j'attribuerais les issues. Pour les corrections de bugs, j'ai autorisé la soumission de PR sans discussion préalable tant que les contributeurs expliquaient leurs modifications en détail.\n\nUne interaction particulière s'est démarquée lorsqu'un utilisateur demandant une attribution a mentionné une « connaissance », ce qui m'a fait suspecter l'implication d'un flux de travail assisté par IA ou de « vibe-coding ». Après confirmation, j'ai révisé davantage les directives CONTRIBUTING pour aborder le code généré par IA. J'ai indiqué que je ne bannirais pas l'IA complètement, mais que les PR purement générées par IA ne seraient pas acceptées. Les contributeurs doivent divulguer l'utilisation de l'IA, assumer la responsabilité de leurs soumissions et être prêts à des revues de code approfondies. L'utilisation non divulguée de l'IA serait considérée comme malhonnête et entraînerait la fermeture de la PR. J'ai partagé mon point de vue selon lequel, bien que j'utilise moi-même des outils d'IA, déléguer des implémentations entières à l'IA sans compréhension réelle est problématique.\n\nCe soupçon a été renforcé lorsque l'utilisateur a soumis une PR qui ne compilait pas, manquait de formatage correct malgré des instructions explicites, contenait des commits mal intitulés et des incohérences telles que le changement d'un nom de méthode sans mise à jour de sa définition de trait. Ces signes indiquaient une tentative de génération automatique de code. J'ai fermé la PR et demandé des contributions plus réfléchies. De plus, certaines issues ont reçu des « plans d'attaque » vagues qui semblaient générés par IA et dénués de sens, soulignant un défi pour filtrer les contributions de faible qualité.\n\nEn réfléchissant aux retours d'autres mainteneurs, il semble que Hacktoberfest attire souvent des PR spammeuses axées sur des changements triviaux, comme des corrections de fautes de frappe ou des modifications simples de commentaires. Avec l'essor des modèles d'IA avancés capables de réécrire de larges sections de code, la maintenance des projets open source devient plus complexe. Bien que l'IA puisse gérer efficacement des tâches simples, les refactorings importants pilotés par IA risquent d'introduire des bugs difficiles à détecter et d'obscurcir la sémantique du code. Contrairement aux développeurs humains, l'IA manque de compréhension conceptuelle du logiciel comme « construction de théorie », notion soulignée par Peter Naur. De plus, la communauté peine à s'accorder sur ce qui constitue un travail généré par IA versus humain, compliquant la modération.\n\nMalgré ces défis, il y a eu des contributions précieuses durant Hacktoberfest. Après l'afflux initial de PR douteuses, des contributeurs plus engagés ont soumis des améliorations significatives. Un exemple notable fut l'ajout de la navigation suivante et précédente dans le lecteur, une fonctionnalité critique auparavant manquante. L'implémentation m'a aussi appris l'utilisation de Rc<T> en Rust pour le comptage de références, enrichissant ma compréhension.\n\nDans l'ensemble, Hacktoberfest a apporté à la fois opportunités et obstacles. Il a catalysé l'implication communautaire et accéléré le développement des fonctionnalités, mais a aussi introduit des complexités liées à la qualité des contributions, notamment avec le codage assisté par IA. Une communication claire, des directives strictes et des processus de revue vigilants se sont avérés essentiels pour maintenir l'intégrité du projet tout au long de l'événement.
