本文へ
ハクソク

世界を動かす技術を、日本語で。

あなたのPRはもういらない

元記事: 原文(dpc.pw)

概要

  • PRのマージ を断る理由と背景の説明
  • LLM（大規模言語モデル）活用 による開発スタイルの変化
  • 貢献方法の転換 と価値あるサポートの提案
  • 具体的な協力方法 の提示
  • フォーク推奨 による開発効率化の促進

コントリビューションの見直しとPRをマージしない理由

  • あなたの貢献 に感謝しつつ、現状のコラボレーション方法を再考したい意向
  • 見知らぬコントリビューター のコードには悪意ある変更が混入しているリスクが常につきまとう
  • コードの書き方やスタイル に対する個人的なこだわりや主観的な側面の違い
  • レビューやCI、マージコンフリクト など、調整作業の手間とタイムゾーンの違いによる非効率
  • PRのやりとり が開発スピードを遅延させる要因
  • LLMの進化 により、コード実装自体の価値が相対的に低下
  • LLM生成コード は悪意のリスクが低く、スタイルも自動化しやすいため、自己完結型開発が容易
  • 他者との調整不要 で、自分のペースで開発可能

ソフトウェア開発の本質的な変化

  • ソースコード は「ソース」ではなく「中間成果物」としての性格が強まる
  • 自動生成が容易 になり、設計やレビューに価値がシフト
  • LLMの活用 で設計・レビュー・理解が主なボトルネックに
  • 他人のPR は設計や理解、レビュー面であまり助けにならない
  • 今後は自分でLLMを活用し実装 する方が効率的

価値ある貢献方法の提案

  • フィードバック提供
    • 実装者は利用やリサーチの時間が限られるため、ユーザー視点の改善点や良い点の共有が有益
  • アイデアの議論
    • 多様な経験や視点を持つ人との議論が設計や方向性決定に役立つ
  • バグ報告・調査
    • 再現手順や発生箇所の特定、解決案の議論まで含めた良質なバグ報告は極めて価値が高い
  • 変更のプロトタイプ提示
    • 参考実装や生成プロンプトの共有は、実際にマージしなくても設計の参考資料として有用
  • コードレビューと指摘
    • レビュー負荷の軽減や見落とし防止に貢献
  • フォークして独自開発
    • 自分のニーズに合わせて自由に改変し、アップストリームと独立したペースで開発可能
    • 設計の多様性や新たな学びにつながる可能性

今後の協力のあり方

  • コードの直接的なPR提出 は控え、上記のような多様な形でサポートを検討
  • フォーク・独自実装 も歓迎し、相互に学び合う開発コミュニティ形成を志向

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

これ、まあ…大丈夫そう？プロジェクトでバグに遭遇したら、自分で直しちゃうことが多いから、直さなきゃいけないし。バグをPRと一緒に書いてメンテナーに送るのは、普通の礼儀だと思うんだよね。もしマージされれば、アップデートの時にフォークしたりパッチ当てたりしなくて済むし、ウィンウィンだと思う。でも、メンテナーがPRを受け取りたくないなら、それも全然いいよね。自分でやった方が楽な時もあるし。

提出者がLLMを使ってPRを作ってるなら、著者がそのプロンプトを自分で実行するのも納得だよね。プロンプトを共有すればいいだけだし（実際にLLM用のプロンプトとしてフォーマットされてるかどうかは別として）、他の名前の機能リクエストとあまり変わらないし。

└

+1

└

これには同意だな。もしかしたら、提案された仕様でPRを作るところから始めて、メンテナーがそれを実装するエージェントを使うべきかも。これは、仕事で始めたことに似てる。PRをレビューする最初の段階は、仕様に合意することなんだ。コードを書くことやレビューすることは、ほとんど trivial な部分だよ。

└

LLMを一回きりのプロンプトで使ってるなら、きっと新しいんだね。

└

そうだね。今は、望んだ結果を出すプロンプトの方が、PRの結果コードよりも役立つよ。実際、コードはバイナリの特性を持ち始めてる。

すべてのメンテナーは、他の人にどう貢献してほしいかを言えるべきだと思う。でも、インターネット全体からのパッチは、ほとんどの場合、手間がかかるだけであまり価値がないってのは常に真実だった気がする。人々がそれを受け入れる理由は、パッチ自体のためじゃなくて、新しい貢献者を得るためなんだよね。最終的には役に立つようになるし。

└

記事の著者はこの点を見落としてると思う。実際に人と一緒に働いて、みんながコードベースの似たようなメンタルモデルを持つと、人間同士のコミュニケーションはLLMよりずっと効果的だよ。ランダムな貢献には当てはまらないけどね。

└

でも、インターネット全体からのパッチは、ほとんどの場合、価値に見合う以上のトラブルを引き起こすのは常に真実だった気がする。ああ、15年前にオープンソースプロジェクト（ちょっとしたフリーミアムプロジェクト）に機能を追加したくて、プロのソフトウェア開発の経験もなければ、プルリクエストの理解もなかった。自分がやろうとしていることを説明して、プロジェクトにとって良い機能だと思うって言ってPRを送ったんだ。今思うと、彼らは盲目的にマージすべきじゃなかったけど、実際にマージされて、めちゃくちゃになった。あの日、貴重な教訓を学んだよ、ハハ。

これ、両方の立場を経験したことがある。ghidra-delinker-extensionのメンテナーとして、非トリビアルなPR（オブジェクトファイルフォーマットやISAアナライザーの追加みたいな）が来ると、嬉しいんだよね。それに、ツールチェインをインストールしたり、使い方を学んだり（MSVC…）、いろんなナンセンスやドキュメントのないことを理解したり（COFF…）、必要ならバイナリファイルツールキットの中でバイトパーフェクトなラウンドトリップパーサー/シリアライザーとテストを書いたり、ゴールデンGhidraデータベースを準備したり、ユニットテストを書いたり、リンク解除したものが再リンクされたときにちゃんと動くか確認したり、自分の基準やリンターをクリアして、クリーンなGit履歴を持つことになる。だいたい、彼らのブランチを取って、自分でその作業をする方が楽だし（適切なときにコミットに著作権を付与しながら）、マスターブランチにプッシュしてPRをクローズする方が、GitHubのコメントで遠くの誰かにやらせるよりも簡単だと思う。逆に、仕事ではMbed-TLSの中でPKCS#7証明書チェーンのサポートを実装して、上流にPRを提出してた。正確で、コメントもドキュメントもテストも完璧だったのに、開発者の一人が暗黙のうちに認めてくれた。今でもオープンのままで（もちろんマージコンフリクトはあるけど）、同じ機能のために5つくらいのオープンPRがある。これを見ると、無理に主張するつもりはないし、次のJiraタスクに進むよ。

└

「マスターブランチにプッシュしてPRを閉じる方が、地球の反対側にいる誰かをGitHubのコメントで操るよりマシだ」 この気持ちは分かるけど、15年以上前にオープンソースに関わるようになったことには感謝してる。なぜなら、メンテナーたちが「操ってくれた」おかげで、後で自分一人では学びにくいプロジェクトのさまざまなプロセスをたくさん学べたから。

└

普段は、彼らのブランチを取って、自分でその作業を全部やる方が楽だと思う（適切なときにはコミットに著作権を付与して）、マスターブランチにプッシュしてPRを閉じる方が、GitHubのコメントで遠くの誰かを操るよりもずっと簡単だよ。オープンソースへの貢献で最もネガティブな経験はそういう感じだった。私のパッチがマスターに入るまで関わってくれた唯一のメンテナーとのやり取りは、今までのオープンソース貢献の中で最高の経験だった。開発者と関わることを「遠くの誰かをGitHubのコメントで操ること」と見なすのは悲しいね…。

Hacker Newsで議論の続きを見る