[alaaibrahim]

Why Not?

I see a problem that I can fix, I do that, and then send it back to the original maintainer, making sure that I'm not breaking tests if they exist, and providing a good description of the change. Then it's up to the maintainer to either merge it, or throw it away.

Of course, I don't have any problem with getting my PRs closed, I'm not the one who would end up maintaining the code.

[asdkjfsad888]

> I see a problem that I can fix...

Remember, they said "out of the blue" which means "without prior contact to discuss doing so."

This exact reason was explained in the parent post: maybe the maintainers and project owners don't see it as a problem or are already working on something.

It's not just about being a machine that can crank out fixes to the individual issues in software wherever you see them. It's about participating in a social project intended to fix a larger scale problem.

> Of course, I don't have any problem with getting my PRs closed, I'm not the one who would end up maintaining the code.

A reason alone not to send PR's "out of the blue". If you're just looking to pump and dump, I'd rather not involve you in the process, only to have to do work to fix/rm code down the road.

But I mean, above all, it's your time to waste.

[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.

[alaaibrahim]

> Remember, they said "out of the blue" which means "without prior contact to discuss doing so."

If I do contact the maintainer before I do any change, that means I'm making a commitment to do that change, which is not something I want to do.

> If you're just looking to pump and dump, I'd rather not involve you in the process, only to have to do work to fix/rm code down the road.

I think you should always assume with any PR, that it's a pump and dump, unless you have a history with whoever raised the PR.

> It's your time to waste.

I don't think it's a waste, it's an issue that I'm facing (or a feature that I want), so writing the code is for my own need, I'm sharing it back in case other people want it.

[kingosticks]

> If I do contact the maintainer before I do any change, that means I'm making a commitment to do that change, which is not something I want to do.

There doesn't have to be a commitment to do anything. You are opening an issue and starting a dialogue. If you then disappear, someone else can come along later and implement/fix it with the benefit of the original discussion.