GitHub、長大なpull requestの「マージを妨げるもの」をページ最上部に集約
GitHub New pull request overview page in public preview
GitHubがpull requestの新しいOverviewページをオプトインのパブリックプレビューとして公開した。長いpull requestでマージボックスまでスクロールする手間をなくすため、マージ状況と次に取るべきアクションをコンパクトなサマリーとしてページ上部に配置。マージボックスは同じ情報を半分以下のスペースに収めるよう再設計された。未解決の会話や自分のコメントでの絞り込み、新しい順の並べ替え、右上のアクティビティ要約も追加されている。
マージボックスを単に上へ移動するのではなく、同じ情報を半分以下のスペースで表示できるよう再設計しました。
HNでの議論
128- capevace
私たちは独自のレビューパイプラインを構築してきました。自動レビューガイドやリスク検出なども含まれています。
コードレビュー周りにはやるべきことが山ほどあるのに、GitHubがもっとやらないのがとても不思議です。
彼らにはすでにリーチがあり、何年分もの実際のレビューデータもあります。なのに、PR自体はより効率的なレビューのために新しく利用可能になった手法を何も使っていません。
エージェントがPRをばんばん量産しているのに、私はまだ35個のPRの生のdiffを眺めていて、挙げ句の果てにボトルネック呼ばわりされるのです。
- gz09
むしろPRに関するリグレッションの修正を先にやってほしい…
例えば、最近導入された厄介なバグがあって、「Merge when ready」をクリックしても、実際にマージキューに送られる確率は60〜70%程度しかないようです。それが起きた場合、通常は翌日になってもマージされていないことで気づきます。
サポートは1ヶ月以上前にこの問題を認識したと認めましたが、今のところ修正はありません。
- habosa
これは大きな改善ですが、まだ素晴らしいとは言えません。私は6年以上前にCodeApprove（https://codeapprove.com）を作りましたが、それはGitHubのPRページがあまりにひどく、改善したいという衝動に駆られたからです。
私の意見では、正しい設計はとてもシンプルです：
- すべてを1ページに、情報密度高く
- コードと未解決の議論に焦点を当て、CIチェックもあれば良い
- キーボードナビゲーション
Graphiteはかなり近いです！しかし年々雑然としてきました。CodeApproveも完璧には程遠いです（UXにあまり手を入れて久しいです）が、GitHubにはもう少し頑張ってほしいと思います。
- locallylinear
正直、PRのステータス（失敗したチェックや未解決のコメントなど）はエージェントに聞けばいいだけです。
でもこれはこれで悪くないと思います。
どちらかというと、UXを改善すべきはコードレビュー、それもレビューを依頼する前に「自分の」（エージェントの）コードをレビューする方だと思います。IDEから離れてターミナルアプリやデスクトップアプリでコーディングする世界に移行しつつある中で、GitHubに上がるまでコードを目にすることすらよくありません。それでも、特に重要な部分はレビューすべきだという感覚をまだ手放せずにいます。
そして、1年前の自分が今の私の発言を聞いたらショックを受けるでしょう。
- johnnypangs
コメントスレッドの順序を逆にしたのに、プレビューを表示するネイティブな方法を用意しなかったのが気に入りません。今では、マージボタンを見るために一番下までスクロールする代わりに、プレビューを見るために一番下までスクロールしなければなりません。
- verst
数週間使っていますが、あまり好きになれません。PRのディスカッションやコメントに移動するのにクリックが多すぎるのが気に入りません。
- pscanf
試してみましたが、基本的には同じ古いUIにいくつかのマイナーなレイアウト変更を加えただけなのに、なぜこんなに騒がれているのか理解できません。AI開発ワークフローのニーズには間違いなく応えていません。
- ethin
UIをきれいに見せることよりも、プラットフォームを再び堅牢にすることをGHには望みます。