Feature Request: Better tooling for large PRs

[DanL]

A frequent issue my teams and I run into is dealing with large PR reviews. The solution is usually to break it down into several smaller PRs, but that seems like a workaround for GitHub's PR review system not having adequate tooling for large changesets.

The closest solution I can think of would be giving authors the ability to group changes/files together, so you could easily delineate logically separate parts of a PR as belonging together. With this system, you could have a reviewer sign off on a subset of the PR, without feeling obligated to review absolutely everything.

[mpetitdant]

It feels to me that the developper should split the work in commits and this is what I logged in #5303
But I also agree the reviewer may not have the same mental model as the committer leading to frustration over the large reviews.

[iandunn]

👍🏻

IMO commits should be atomic, and only do "1 thing", in the same way that functions should only do 1 thing. ( How "1 thing" is defined is relative to the situation, of course )

I'd rather have 1 large PR than several interdependent ones, and I don't mind a larger PR if the commits are logical and organized. The problem for me is when there's a dozen "WIP" commits that can't be meaningfully viewed in isolation, but viewing all the changes files is overwhelming.

Related: #6089

[WORMSS]

We have a situation where we are migrating from cypress (due to them committing bad practices into their npm library), so migrated to playwright. This is "one piece of work"

[parhamfh]

In my experience the file overview can get a bit hard to navigate. For various reasons you can end up in a state where many files listed alphabetically might not be the ideal way to review those files, even with proper git commit discipline. (Example from Python code base would be src/ and tests/ being sorted separately while the contents of the modules are strongly correlated and perhaps mirrored)

I greatly appreciate the new tools that allow you to un/check files you've reviewed and a jump-to-file option, going further and allowing grouping would be even more great! 🤩

[nickofthyme]

I would agree this is no normal and in most cases PRs should be small. But in some cases like large refactoring (~3k file changes) it's very much needed. Moving, renaming files and paths can add up quick.

You may get away with reviewing all files and marking them as view and eventually GitHub will load things with maybe a few refreshes. What is harder, if not impossible, is trying to filter files on such large PRs, particularly for codeower files (~50 files in 3k). You would think this would be easier on GitHub to load less but it actually struggles more and results in a failure to load altogether. This is true even when using the query params, not the UI, to trigger file filtering.

This is good example https://github.com/elastic/kibana/pull/202830/files