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

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

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

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