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.
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.
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.
When you start contributing to an open source project, you should start with tackling an open issue, or opening an issue and contributing per their process. Jumping in, opening random pull requests, forks, tagging, and trying to alter the build process is not a good way to do so. Changing the build process, which affects every single person that touches the code, and can also interact with CICD platforms you don't have access to, is possibly the worst place to jump into, especially when they don't show any interest in this.
The lack of commits for months was also a good clue that this wasn't a good place to contribute. Getting insta-banned is still weird, though. If someone makes a PR and then immediately closes it, that strongly implies human error rather than spam or any other malice. The right move is the default one: ignore it until something actually happens.
There's a lot of attention around increasing malicious contributors. Someone I don't know with no history contributing to my project immediately jumping into packaging, distribution, provenance would really have me questioning their intentions.
Am I being paranoid? Probably, but given recent history I don't think so. Would I ban them for that? Dunno, but it would be a consideration.
Either way, I don't find the decision to ban someone from contributing for that to be all that surprising.
I would also block/reject a person like this. I had my fair share of these phishing attemts so I'm not asking questions if someone is trying to touch my infra.
This kind of attestation doesn’t realistically add any value. It just lets downstream users assert that the build happened on a host managed by Microsoft. That doesn’t reflect anything with regards to the package content itself — although it may allow ticking some compliance checkbox somewhere.
Reproducible builds are a lot more valuable. They let downstream consumers verify that the package was actually generated with the documented sources and inputs.
Assuming you trust GitHub CI, why doesn't attestation bring the same value?
I haven't really looked into what it entails in establishing an attestation for a CI-built package, though, but I thought the idea was that you will at least get a git commit id that will describe the work, and that the attestation says that that's the work that's been done?
Reproducible building would be useful for removing the need to trust GitHub. But then what do you need the builds for anyway, you would always need to build it yourself anyway?
Having both is really where things are at. That way you can verify that the tools being used for the build aren't doing something behind your back and that the code that you see is what you're getting.
I see a lot of folks complain about not getting help on OSS projects; I also see a lot of people turning a blind eye to people trying to help (however naively it may be). It's an intesting dichotomy.
> people trying to help (however naively it may be)
As soon as you are giving free attention and mentoring to people unable to make a somewhat useful contribution, you are giving up even more of your life for free.
There are people who know how to pick appropriate issues and send PRs with test cases. It might be better to look for them than try to mentor ineffective contributors.
Yup, it's interesting. I think a major cause is just a lack of perspective. Maintainers are likely working for free, have their own jobs and the like. They will appreciate it if you make their jobs easier, and will be extremely cautious if you are changing fundamental/core components as a new guy in town.
One needs to study on their own, use forums or get in touch in some other way that isn't a PR if they want help. Also, while studying the codebase, finding low hanging fruit is going to be easy. That's where everyone should start.
One of the questions you as a maintainer have to ask yourself when coming across some PR, Issue or similar is "Does this Person want to help, or are they interested in obtaining the identity of a 'helping person'".
This blog post existing points at the latter.
Depending on how you run your project, you might want to play along with that story regardless, to extract some value and make the whole thing a two-way transaction instead of a one-way one.
That however requires there to be some significant value to be extracted or else you end up with a net negative.
It is however also possible to reject transactionality entirely.
___
What is interesting in this case specifically, is that the author did manage to extract value eventually. If not by being the savior of lodash, then by becoming the victim of lodash.
This might be another detail hinting at why whoever maintains lodash might've decided to react with a block and nothing else.
Further receipts for this read of the situation include the immense clout-to-effort ratio of the PR just adding a new GitHub action that "adds more security" and the Blogpost itself opening with the actual mission statement of "improving the ecosystem".
Readit News
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
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.
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.
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.
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 suggest to OP to work on his social skills.
Am I being paranoid? Probably, but given recent history I don't think so. Would I ban them for that? Dunno, but it would be a consideration.
Either way, I don't find the decision to ban someone from contributing for that to be all that surprising.
This sort of contribution seems easy enough to review.
Reproducible builds are a lot more valuable. They let downstream consumers verify that the package was actually generated with the documented sources and inputs.
I haven't really looked into what it entails in establishing an attestation for a CI-built package, though, but I thought the idea was that you will at least get a git commit id that will describe the work, and that the attestation says that that's the work that's been done?
Reproducible building would be useful for removing the need to trust GitHub. But then what do you need the builds for anyway, you would always need to build it yourself anyway?
That seems like an obvious vector for doing something behind your back.
As soon as you are giving free attention and mentoring to people unable to make a somewhat useful contribution, you are giving up even more of your life for free.
There are people who know how to pick appropriate issues and send PRs with test cases. It might be better to look for them than try to mentor ineffective contributors.
One needs to study on their own, use forums or get in touch in some other way that isn't a PR if they want help. Also, while studying the codebase, finding low hanging fruit is going to be easy. That's where everyone should start.
This blog post existing points at the latter.
Depending on how you run your project, you might want to play along with that story regardless, to extract some value and make the whole thing a two-way transaction instead of a one-way one. That however requires there to be some significant value to be extracted or else you end up with a net negative.
It is however also possible to reject transactionality entirely.
___
What is interesting in this case specifically, is that the author did manage to extract value eventually. If not by being the savior of lodash, then by becoming the victim of lodash.
This might be another detail hinting at why whoever maintains lodash might've decided to react with a block and nothing else.
Further receipts for this read of the situation include the immense clout-to-effort ratio of the PR just adding a new GitHub action that "adds more security" and the Blogpost itself opening with the actual mission statement of "improving the ecosystem".