ディスカッション (11件)
GitHubのリポジトリに押し寄せるAI生成のスパムに悩まされていませんか?実は、Gitの「--author」フラグを活用するだけで、非常にシンプルかつ効果的にスパムを撃退できます。もし同様のボット攻撃に困っているなら、ぜひこの方法を試してみてください。自動化されたスパムコメントやプルリクエストを最小限の手間でシャットアウト可能です。
バウンティを提供しているレポジトリにとって、PRスパムは深刻な問題だよ。GitHub側で、提出したPRの95%以上が却下されているようなアカウントについては、一時的にPR作成をブロックするようにすべきじゃないかな。
採用候補者に面白いテスト課題を出すのはやめるべきか?
やめるべき。
.ai ドメインという皮肉。
ELOレーティングのようなシステムを導入して、こうした問題を緩和できないかな。プロジェクトへのPRが正常にマージされた実績や、他のユーザーからの反応によるレスポンスの質、あるいはプロジェクトの重要度などを掛け合わせる感じ。人間かAIかという議論ではなく、実質的にどれだけ貢献したか、あるいはスパムかという評価軸だ。IssueやPRをELOスコアでソートしたりフィルタリングしたりできると良さそう。あくまで「文脈に応じたスコア」という比喩で、厳密なチェスのELOそのままというわけではないけど。
ネガティブなスコアは、スパム行為や的外れなIssue報告で他のユーザーから通報された場合に付く。中立(±0)や、善意は伝わるがマージに至らなかったもの(例えば、Issueは正しいが対象のレポジトリが間違っていた、PRは良いが先行して実装すべき機能があったなど)は、軽微なプラス評価にするとか。
これには見過ごされがちなセキュリティ上のリスクがあるんだ。レポジトリへの貢献者は権限が高く設定されることがあって、例えばフォークからのPRに対して承認不要になる場合がある。GitHubのドキュメントにも警告があるよ。
初回貢献者のみ承認を必須にする設定(最初の2つの設定)の場合、一度でもコミットやPRがマージされたユーザーには承認が不要になる。悪意のあるユーザーは、わざと単純なタイプミスや無害な修正をメンテナンス担当者に承認させて、この要件をクリアできてしまう。
何でもかんでも解決策は猫耳(catgirls)[1]ってことか?結局のところ、プルーフ・オブ・ワークだってメールスパムへの対策だったわけだし。PRスパムなんて、その長い歴史の最新版に過ぎないよ。
これは契約の仕事ではなく、コミュニティへの感謝を示すための任意の手段です。
オンボーディングのドキュメントの書き方に、いかにもAIっぽい特徴(引用文中のダッシュや「AではなくB」という構文)が出てるね。
彼らが「毒を以て毒を制す」つもりなのか、それとも言及されている通り時間がないのかは理解できるよ。それでも、結局どれも中途半端な対策にしか思えないな。
みんなで「AIはコードを書くのがすごい」なんて言いふらしてきた報いだな。最初はAIを売り込みたい連中が火付け役だったけど、なぜか界隈で尊敬されているような独立系開発者たちまでそれに乗っかった。Facebookが人員削減の理由に「AIが優秀すぎるから」と言い出したことで、さらに火に油を注いでいる。今や多くの人が、自分のAIの相棒が素晴らしいコードを吐き出していると信じ込んで、パンク寸前のプロジェクトに大量のPRを送りつけているわけだ。
GitHubがこんな状況を許していることに腹が立つよ。コメントやPR作成に対して最低限の要件を課していれば、こんな事態にはなっていないはずだ。
あと、IssueみたいにPRも削除できるようにしてくれ。
メールアドレスがGitHubアカウントと一致すれば、GitHubはコミットをプロファイルに紐付けて貢献者ステータスを付与する。
記事でメールの一致について触れられていて、貢献者のメールアドレスが変わった時に崩れるんじゃないかと懸念したよ。(数年間でいくつものプロジェクトに貢献してきたけど、もう存在しないメールアドレスを使っていたこともあったし)
ただ、実際には著者の元のGitコミットに記録されたメールアドレスではなく、GitHub側が生成したGitHubユーザーIDやユーザー名を含む一意のアドレスを使っているみたいだね。それなら著者がメールアドレスを変更しても問題なさそうだ。貢献者がアカウントへのアクセス権を失って新しいものを作り直さなきゃいけないならアウトだけど、そんなことは滅多にないだろうしね。