[fishtoaster]

I've been working through PRs since around 2011 and I don't think I've ever seen a place where PRs were intentionally used to handle design issues. Occasionally design problems will get brought up in PR, but that's always been considered a failure of earlier planning when it happens.

Depending on the company, the design discussion you're talking about has happened:

1. In verbal discussions with other devs before fingers ever touch keyboards

2. In long-form writing (Text docs, then Google docs, then later Notion)

3. In per-project slack channels

4. Out loud, on a whiteboard.

Right now it's very much #4 because my company is 2 devs and a founder. But even here, I wouldn't expect to get anything non-trivial into pull request before figuring out the overall structure with the other dev verbally or in writing.

[pipes]

For non trivial work do you expect it to be delivered via small incremental changes? Genuine question. Not trying to but pick or win an argument.

[fishtoaster]

When possible, yeah. I imagine some sort of golden rule: "make PRs for others to review that you would like to review yourself." There's plenty of room for exceptions there - my coworker is currently reviewing a 1300-line PR after my apologies for it :)

But yes, we generally break things down into the smallest meaningful chunk possible to deliver. If that chunk is too small to understand the larger work that it's part of (as is usually the case for non-trivial work), we can discuss the larger work in another forum (ad-hoc verbally, via design doc, via meeting, etc).