[akerl_]

The post calls out major changes as deserving a chat first. My primary workflow that results in PRs is: 1) I find an interesting project, 2) I find something it doesn't do the way I want (a bug, or a config tweak), 3) I patch my fork to fix that, 4) I open up a PR incase the maintainer does think it's worth merging into upstream.

What's the upside of me opening an issue first to chat about it? The maintainer still has to burn the time to think about it, but without seeing the code that I'm proposing, which is already written because I already needed it to scratch my itch.

If they think it's worth of merging, woo, we merge it. If they want the problem fixed a different way, cool, one of us writes the PR that makes that happen. If they don't want the change, I keep using my fork.

[bcuzitsppl8383]

The post in the comments was the one I was referring to. Says verbatim don't make pr's without a ping first. Says nothing of major changes.

You forget maintainers aren't computers. While your logic is correct, social norms for humans are different.

You have voices describing a human view and interest in a certain way. Whether you agree is irrelevant; the project maintainer has no obligation to listen.

It's not all about you and the workflow that makes most sense from your office chair.