Comment by moosedev
As a reviewer... it really, really depends on how trivial or gnarly the PR is.
If it's a simple change that is obviously correct, I'll try to unblock the author ASAP - often within minutes, even if it interrupts my flow.
If it's a giant PR with lots of risky changes in vital code, an awkward-to-unreadable diff, and/or maddeningly questionable design/coding decisions that require me to think a lot and compose some nuanced, reasoned comments to steer you in a better direction, then, well, you might find yourself nagging me for a review 2 days later. (And I'll probably ask you to split up PRs like this in future, e.g. to separate major refactoring from any logic changes.)
This x1000. It's not about the org, really. It's about what's being changed.
Yes, a lot of large codebases have things that look wrong. They're not always wrong. Trying to clean up what look like cobwebs at the core of a large codebases often means removing things that are there for a reason. The reason is usually counterintuitive and could be documented better. But often only a few people can really evaluate the change.
A small PR is likely to be accepted quickly, and a large PR is likely to take awhile. No one gets upset by that, though.
The flip side is that a small PR to a critical part of the codebase is also likely to take awhile and be treated as "default to no". It's often hard to see that from the "outside", though.
With that said, trying to go the extra mile and make things clear, concise, and better documented than before goes a long way in getting an MR reviewed quickly.