Most OSS projects have a scale of expectation for external contributors depending on what they propose, either implied or written (like in [^0]).
A hypothetical but likely scale would be from typo/docs fixes (lowest), bugfixes, new features, to CI/CD and release workflow (highest). Generally, the wider audience your patch might influence, the more you are expected to know about the project itself, its workflow, collaboration, best practices, code quality and maturity, etc. in the first place.
I agree that banning people without prior communication is rude, but looking at OP's PR[^1], I tend to concur with lodash maintainers this time. The PR gets no description, no explanation, and no prior discussion or RFCs. It adds a totally new GitHub Actions pipeline, while lodash isn't even using GitHub Actions now. It contains various fixup commits that should be squashed. One commit has a super long subject that should be split up. OP here went straight to the top level to propose a brand new release workflow, but the lodash maintainers obviously didn't consider them to be ready for such contributions.
These are common mistakes every contributor would make in the beginning, and I don't think the maintainers meant it personal. As many other comments have pointed out, by choosing an easier task, getting familiar with the workflow, and building trust, OP can get their patch landed.
There wasn't even a "what is this" or "please explain". I feel like blocking should be reserved for disruptive behavior or spam. At best this seems like an accident, at worst it seems wildly immature.
But to my eyes, this PR does look like spam. It has no description, its title and commit messages are meaningless. Changing random auxiliary files is also a common sign of PR spam. This PR really looks no different from other spam PRs that popular GH repos have to deal with all the time.
This is not the right way to contribute to a project. If I were the maintainer, I wouldn't engage with it either, just like I don't reply to spam emails.
Your spam detector is broken. It was opened by an account that's clearly human with more than 10 years of history. It was closed by the author themselves 2 hours after they opened it. It's got WIP commits that were clearly written by a human thinking through the process.
What about this reads as spam to you? They just forgot to fill the description portion of the PR
If someone opens a PR to one of my repos with no context, I ban them.
There’s too much AI spam out there right now.
Publishing ‘@provenance-labs/lodash’ as a test, I suppose. Ok. Leaving it up? Looks like spam.
Badgering the author an a private email? Mmm. Definitely not.
This isn’t a bug, it’s a feature. There’s a contributing guide which clearly says; unless a feature gets community interest, it’s not happening. If you want a feature, talk about it rouse community interest.
Overall: maybe this wasn’t the right way to engage.
Sometimes you just have to walk away from these situations, because the harder you chase, the more it looks like you’re in the wrong.
…it certainly looks, right now, like the lodash author wasn’t out of line with this, to me.
> Overall: maybe this wasn’t the right way to engage
Lex Livingroom. If you are among friends you can surly criticize a sweater, but if you come barging in uninvited and criticize the same sweater, you're in for a bad time.
Foreign PRs with malicious GitHub Actions attached are a common vector for the very supply chain attacks OP was trying to mitigate, from what i understand. At first glance a PR like that is incredibly suspicious.
I sympathize with the OP, GitHub makes it outrageously easy to accidentally open an upstream PR when you meant to open one on your own fork, it's happened to me twice. But i don't blame lodash for blocking them.
Regardless, opening an issue about their release process obviously should have been done first.
Agreed. It seems there was no initial communication, consideration of the existing maintainers opinions or evaluation of current deployment processes.
OP simply pushed his personal opinion on how lodash (extremely popular library) should be deployed. Proceeds to get confused and upset when this is rejected.
I agree that banning people without prior communication is rude, but looking at OP's PR[^1], I tend to concur with lodash maintainers this time. The PR gets no description, no explanation, and no prior discussion or RFCs. It adds a totally new GitHub Actions pipeline, while lodash isn't even using GitHub Actions now. It contains various fixup commits that should be squashed. One commit has a super long subject that should be split up. OP here went straight to the top level to propose a brand new release workflow, but the lodash maintainers obviously didn't consider them to be ready for such contributions.
These are common mistakes every contributor would make in the beginning, and I don't think the maintainers meant it personal. As many other comments have pointed out, by choosing an easier task, getting familiar with the workflow, and building trust, OP can get their patch landed.
[^0]: https://www.mozilla.org/en-US/about/governance/policies/comm...
[^1]: https://github.com/lodash/lodash/pull/6014