Exactly. Too often I get a large PR that I call a 'code dump'. at least give a couple paragraphs of explanation behind the changes. Sometimes a conversation can start in a PR, but it's more rare that results in merged code than if there was an issue first.

Yeah, I semi-recently had to fork a library, make some big changes to get it working for us, then made an issue with the main repo basically saying "Hey I needed this and don't have time to do it properly, Here is what I did, and I ham-fistedly ripped out everything i'm not using. Look at these few files for an example of the core change that's needed. I'm willing to help work on a real solution later, but I can't right now"

The maintainer saw what I did, and was able to easily make the change so it conformed to their style, their architecture, and they worked with me later so I could make the doc changes.

I felt like that worked magnitudes better than when someone makes a big PR with a potentially controversial change and lets the maintainer decide what to do with it.

  as a maintainer, I don't like turning down all this work you've done for free

I empathise with that perspective, and I appreciate any work that an open-source maintainer does to contribute to a project, so thank you.

I must confess, I often submit patches without prior warning or discussion. They almost always come out of client work: I've been asked to deliver a requirement, so I do what I have to do to deliver that.

When I have to modify upstream code, I know that my use-case might not be appropriate for everyone (so I try to explain that in my comments). But even if I think it's a patch that isn't going to be accepted, I generally post it anyway: partly for the few people who might share my use-case, but also for me, in my next project, where I may run into the same problem again.

Sometimes my PRs are nothing more than a note-to-self. A lot of the time that's been dictated by client policy: projects where I could only modify third-party code if there was a published upstream patch for the changes. So if I have to modify upstream code, I have to record a patch/PR upstream, to comply with client policy. But I do understand that the answer to the PR may well be "no".

That's pretty much the best scenario, I think. If you won't be offended by the fact that I may not consider the PR appropriate for the codebase, I appreciate the time you took to post it for consideration (and thank you!).