bullettyの最初の動作バージョンに最終調整を加えているときに、DigitalOceanが主催する年次イベントであるHacktoberfestが近づいていることに気づきました。このイベントでは、参加者が10月中に6つのプルリクエスト（PR）を成功させるとTシャツがもらえます。これはコミュニティを巻き込み、フィードリーダーを改善し、プロジェクトの認知度を高める絶好の機会だと思いました。準備として、GitHubのIssuesセクションを整理し、ロードマップの各機能とバグごとに1つのIssueを作成し、詳細な説明と画像を追加しました。その後、「Improvements」「Bugs」「Good First Issue」「Hacktoberfest」などのラベルで適切にタグ付けしました。変更の提出、バグ報告、PRの開設手順を概説した一般的なCONTRIBUTINGファイルも作成しました。\n\n10月の数日前に、X、Bluesky、Mastodonの個人ソーシャルアカウントでプロジェクトを宣伝し、/r/hacktoberfestサブレディットにも投稿しました。公式のHacktoberfest Discordサーバーを見つけ、そこでも投稿して貢献者を募集しました。Hacker Newsも試しましたが、反応は最も少なかったです。数日でGitHubのスター数はほぼ100に達し、さまざまなプラットフォームで多くの反応を得て、初期の成功と考えました。\n\nしかし10月が始まると、事前の議論なしにIssueの割り当てを求める多くの貢献者からのリクエストにすぐに直面しました。この方法は早計でリスクがあり、提案者の計画を理解せずにIssueを割り当てると他の貢献者の参加を妨げる可能性がありました。そこで、CONTRIBUTINGファイルを更新し、貢献者はまず実装予定について議論に参加する必要があることを明確にしました。十分な対話の後にのみIssueを割り当てます。バグ修正については、変更を十分に説明すれば事前の議論なしにPRを提出することを許可しました。\n\n特に印象的だったのは、割り当てを求めるユーザーが「knowledge」という言葉を使い、AI支援や「バイブコーディング」ワークフローの関与を疑ったことです。確認後、AI生成コードに対応するためにCONTRIBUTINGガイドラインをさらに改訂しました。AIを全面的に禁止はしませんが、純粋にAI生成のPRは受け付けないと明記しました。貢献者はAI使用を開示し、提出物に責任を持ち、厳密なコードレビューに備える必要があります。開示なしのAI使用は不誠実とみなされPRは閉鎖されます。私は自身もAIツールを使いますが、真の理解なしに実装全体をAIに任せるのは問題だと考えています。\n\nこの疑いは、ユーザーがビルドできず、明確な指示にもかかわらずフォーマットが不適切で、コミットタイトルも不適切、メソッド名を変更してもトレイト定義を更新しないなどの不整合を含むPRを提出したことで強まりました。これらは自動コード生成の試みを示していました。私はPRを閉じ、より慎重な貢献を求めました。さらに、一部のIssueにはAI生成と思われる曖昧で意味不明な「攻撃計画」が寄せられ、低品質な入力をフィルタリングする課題を浮き彫りにしました。\n\n他のメンテナからのフィードバックを振り返ると、Hacktoberfestはしばしば誤字修正や単純なコメント変更などの些細な変更に焦点を当てたスパム的なPRを引き寄せる傾向があります。大規模なコードを書き換えられる高度なAIモデルの登場により、オープンソースプロジェクトの維持はより複雑になっています。AIは単純な作業は得意でも、大規模なAI駆動のリファクタリングは検出困難なバグやコードの意味の不明瞭化を招くリスクがあります。人間の開発者とは異なり、AIはPeter Naurが強調した「理論構築」としてのソフトウェアの概念的理解を欠いています。さらに、コミュニティはAI生成と人間の作業の区別に合意できず、モデレーションが困難です。\n\nこれらの課題にもかかわらず、Hacktoberfest中には価値ある貢献もありました。疑わしいPRの初期の流入の後、より熱心な貢献者が意味のある改善を提出しました。特に、以前欠けていたリーダーの次へ・前へナビゲーションの追加は重要な機能であり、RustのRc<T>を使った参照カウントの理解も深まりました。\n\n総じて、Hacktoberfestは機会と障害の両方をもたらしました。コミュニティの関与を促進し機能開発を加速させましたが、特にAI支援コーディングに関連する貢献の質の複雑さももたらしました。明確なコミュニケーション、厳格なガイドライン、厳重なレビュー体制がイベント全体でプロジェクトの整合性を維持するために不可欠でした。
