What happens to things that effectively need large PRs? To use an example: ray-tracing where (most) of it was a single feature that couldn't be broken down? Some of these statements are definite, so maybe they should note where it's a requirement.

suggestion: I agree with @Vecvec that an unqualified "if big, straight to jail /s" rule is not easy for an external contributor to reason about. I also think that we need to disentangle (1) making aligned changed from (2) the art of making review easier, which are related but distinct. I think our intent would be better communicated with something like this instead:

WGPU is a complex codebase, and contributing to it is often nontrivial. To best ensure that your contributions are accepted, we have some recommendations to consider before you get started:

• Large efforts that are ultimately rejected tend to burn contributors out on both sides of a review. To avoid this, we strongly encourage you to validate time-consuming contributions by engaging maintainership before you invest yourself too heavily.
• File the smallest PRs that make sense on their own. Using atomic commits is also encouraged, since they facilitate review on both sides.

issue: This information is technically duplicative with information in the "What can I work on"? as a new contributor? section.

suggestion: Keeping this dedicated section and linking to it from others would reconcile this.

Yyyyeah, I think there's also a bit of a trust issue here. Based on my experiences in this very repo, when someone says "Oh, I couldn't possibly break this up", I am very skeptical. There have been several times when someone was swearing that their PR had to be landed as a unit, it couldn't possibly be broken up - but then in review I was totally able to break it up into smaller pieces that made sense, if not fully independently, at least serially.

Technically, any PR can be split up - by writing ridiculous code. But that kind of absurdity doesn't help reviewers, and is a waste of time. I'm claiming that in practice, large PRs almost always have reasonable subdivisions.

Counterpoints:

• When you're doing a massive rename, that obviously has to be a single PR.

• Switching wgpu to dynamically dispatched hal objects probably needed to be a massive PR. We could have done it one hal type at a time, but that wouldn't really make it any easier to review.

What's hard to review is when the PR has some big substantive change (like dynamic hal dispatch, say), but also contains cleanups and refactors that pave the way for that substantive change. Those cleanups and refactors can often be broken out into their own steps. They may not seem motivated, in the absence of the main change, but if they're neutral then that's fine.

I can expand on this point, but I do want to put a lot of pressure on authors, because our past experiences have been so bad.

Maybe like this?

otherwise it could confuse beginners (which I am assuming this is for) if they see a large project.

Context: This conversation branches out from the previous one: #6879 (comment)

I didn't set that comment up properly to suggest.

suggestion: Let's use backticks (i.e., `Assigned`) instead of double quotes to make it clear that this is content that somebody would write.

This feedback applies to other references to fields or suggested content fragments.

I made the suggested change. I kind of think <code> should be reserved for things people type, but "assigned" is just a label on the GitHub page. But I don't feel too strongly about it.

Personally I think this should be in the PR template to stop people (like me) forgetting about it. Maybe even in the template text (not just a comment) to act as a default (I would assume it would be squash). I also think a default would be especially useful for beginners too.