[TriangleEdge]

Amazon eng did some research and found the number of comments in a code review is proportional to the number of lines changed. Huge CRs get little comments. Small CRs get a lot of comments. At Amazon, it's common to have a 150 to 300 line limit to changes. It depends on the team.

In your case, I'd just reject it and ensure repo merges require your approval.

[kwk1]

"Inversely proportional" for what it's worth

[senderista]

Also, some teams have CR metrics that can be referenced for performance evaluations.

[ekjhgkejhgk]

Could you please provide a reference? I couldn't find it.

[zukzuk]

That’s a great way to discourage anyone ever doing any large scale refactoring, or any other heavy lifting.

[febusravenga]

That's good. Because large refactorings are usually harmful. They are also usually unplanned, not scoped and based on very unquantifiable observations like "I don't like the code is structured" - let's do ity way.

[Cthulhu_]

That's a good thing, large scale refactorings should be very, very rare. Even automated code style changes can be controversial because of the churn they create. For large and/or important software, churn should be left to a minimum, even at the cost of readability or code cleanliness. I've seen enough open source projects that simply state they won't accept refactoring / reformatting PRs.

[ThiefMaster-]

Large-scale refactoring is not something you want from an external contributed, especially not if unsolicited.

Typically such refactoring is done by the core development team / maintainers, who are very familiar with the codebase. Also because DOING such a change is much easier than REVIEWING it if done by someone else.

[TriangleEdge]

The review bots can be bypassed.

[charlieyu1]

You want to do large scale refactoring without the main team agreeing? Seems like a disaster.

[arachnid92]

Just split up your work across multiple PRs.