Inhalt
Als ich die letzten Handgriffe an der ersten funktionierenden Version von bulletty vornahm, bemerkte ich, dass Hacktoberfest – das jährliche Event von DigitalOcean, bei dem Teilnehmer durch das erfolgreiche Abschließen von sechs Pull Requests (PRs) im Oktober T-Shirts verdienen – näher rückte. Ich dachte, dies könnte eine großartige Gelegenheit sein, die Community einzubeziehen, den Feed-Reader zu verbessern und die Sichtbarkeit des Projekts zu erhöhen. Zur Vorbereitung organisierte ich den Issues-Bereich auf GitHub, erstellte für jede Funktion aus der Roadmap und für Bugs jeweils ein Issue mit detaillierten Beschreibungen und Bildern. Anschließend versah ich sie mit passenden Labels wie „Verbesserungen“, „Bugs“, „Good First Issue“ und „Hacktoberfest“. Eine generische CONTRIBUTING-Datei wurde entworfen, die die Verfahren für das Einreichen von Änderungen, das Melden von Bugs und das Öffnen von PRs beschreibt.\n\nEinige Tage vor Oktober bewarb ich das Projekt auf meinen persönlichen Social-Media-Kanälen auf X, Bluesky und Mastodon und postete auch im /r/hacktoberfest Subreddit. Nachdem ich den offiziellen Hacktoberfest Discord-Server entdeckt hatte, postete ich dort ebenfalls, um Mitwirkende zu gewinnen. Ich versuchte es sogar bei Hacker News, was jedoch die geringste Resonanz brachte. Innerhalb weniger Tage stieg die Anzahl der GitHub-Sterne auf fast hundert, und ich erhielt zahlreiche Rückmeldungen auf verschiedenen Plattformen, was ich als starken ersten Erfolg wertete.\n\nAls der Oktober begann, wurde ich jedoch schnell mit zahlreichen Anfragen von Mitwirkenden konfrontiert, die ohne vorherige Diskussionen um die Zuweisung von Issues baten. Dieser Ansatz erschien mir verfrüht und riskant, da die Zuweisung von Issues ohne Verständnis des Plans des Antragstellers andere Beiträge blockieren könnte. Daher aktualisierte ich die CONTRIBUTING-Datei mit klaren Richtlinien, die betonen, dass Mitwirkende zuerst eine Diskussion über ihre geplante Umsetzung führen müssen. Erst nach ausreichendem Dialog würde ich Issues zuweisen. Für Bugfixes erlaubte ich das Einreichen von PRs ohne vorherige Diskussion, sofern die Mitwirkenden ihre Änderungen ausführlich erklärten.\n\nEine besondere Interaktion fiel auf, als ein Nutzer, der eine Zuweisung anfragte, von „Wissen“ sprach, was mich vermuten ließ, dass ein KI-unterstützter oder „Vibe-Coding“-Workflow im Spiel war. Nach Bestätigung überarbeitete ich die CONTRIBUTING-Richtlinien weiter, um KI-generierten Code zu adressieren. Ich erklärte, dass ich KI nicht komplett verbieten würde, aber rein KI-generierte PRs nicht akzeptiert werden. Mitwirkende müssen die Nutzung von KI offenlegen, Verantwortung für ihre Einreichungen übernehmen und sich auf gründliche Code-Reviews einstellen. Nicht offengelegte KI-Nutzung würde als unehrlich betrachtet und zum Schließen des PR führen. Ich teilte meine Ansicht, dass ich selbst KI-Tools nutze, aber die komplette Delegation von Implementierungen an KI ohne echtes Verständnis problematisch ist.\n\nDieser Verdacht wurde bestätigt, als der Nutzer einen PR einreichte, der nicht kompiliert, trotz expliziter Anweisungen schlecht formatiert war, schlecht betitelte Commits enthielt und Inkonsistenzen wie die Änderung eines Methodennamens ohne Aktualisierung der Trait-Definition aufwies. Diese Anzeichen deuteten auf einen automatisierten Code-Generierungsversuch hin. Ich schloss den PR und forderte durchdachtere Beiträge an. Zudem erhielten einige Issues vage „Angriffspläne“, die KI-generiert und unsinnig wirkten, was die Herausforderung verdeutlicht, minderwertige Beiträge herauszufiltern.\n\nRückblickend auf Feedback anderer Maintainer scheint Hacktoberfest oft Spam-PRs anzuziehen, die sich auf triviale Änderungen wie Tippfehlerkorrekturen oder einfache Kommentaränderungen konzentrieren. Mit dem Aufkommen fortschrittlicher KI-Modelle, die große Codeabschnitte umschreiben können, wird die Pflege von Open-Source-Projekten komplexer. Während KI einfache Aufgaben gut bewältigen kann, bergen große KI-gesteuerte Refaktorisierungen das Risiko, schwer erkennbare Bugs und unklare Code-Semantik einzuführen. Im Gegensatz zu menschlichen Entwicklern fehlt KI das konzeptuelle Verständnis von Software als „Theoriebildung“, ein von Peter Naur betontes Konzept. Zudem fällt es der Community schwer, sich darauf zu einigen, was als KI-generierte versus menschliche Arbeit gilt, was die Moderation erschwert.\n\nTrotz dieser Herausforderungen gab es während Hacktoberfest wertvolle Beiträge. Nach dem anfänglichen Zustrom fragwürdiger PRs reichten engagiertere Mitwirkende sinnvolle Verbesserungen ein. Ein bemerkenswertes Beispiel war die Ergänzung der Navigation für „nächste“ und „vorherige“ im Reader, eine zuvor fehlende wichtige Funktion. Die Umsetzung lehrte mich auch den Umgang mit Rusts Rc für Referenzzählung und erweiterte mein Verständnis.\n\nInsgesamt brachte Hacktoberfest sowohl Chancen als auch Hindernisse. Es förderte die Community-Beteiligung und beschleunigte die Feature-Entwicklung, brachte aber auch Komplexitäten hinsichtlich der Beitragsqualität, insbesondere bei KI-unterstütztem Coding. Klare Kommunikation, strenge Richtlinien und sorgfältige Review-Prozesse erwiesen sich als essenziell, um die Integrität des Projekts während des Events zu wahren.
