If you've already made the changes, then by all means, just send a PR. The worst thing that can happen is that it won't get merged.

If you're considering doing some work, please talk to the maintainer first. Otherwise it might lead to unhappiness all around, because, as a maintainer, I don't like turning down all this work you've done for free any more than you do, but there's not much choice when it's a net negative (for any of the reasons in the article).

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!).