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.
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.
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".
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 tried to contribute in the past and the owner was an unprofessional jerk. Instead of replying the PR rejection with arguments, he posted memes and shit
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.
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.
> 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.
Ehh what. I would give some merit to arguments like "no one should use lodash in 2025 because you can do most of it with built-ins nowadays" or maybe because it doesn't tree-shake well or maybe even because it doesn't seem to have much active development now.
But stating matter-of-factly that no one should use it because some of its well-documented functions are mutating ones and not functional-style, and should instead use one particular FP library out of the many out there, is not very cool.
Without naming, there seems to be >1 VC-funded companies building "open-source" products, with paid-enterprise or other more sinister business models, where they claim to be open to contributions and have a full CONTRIBUTING.md, and where there's an active community of devs trying to contribute good PRs to solve open issues in the issue tracker.
But the issue tracker is so overwhelmed by slop, non-Latin scripts, and people who think their personal problems (or AI model problems) are the product's problems, that the employees have all but ghosted the issue tracker and PRs; it takes days or weeks for the maintainers (employees) to triage/respond/despam the Github issues list. And if the employees _do_ leave an initial comment on a community PR that multiple users on the issue tracker are begging to be merged, and the PR author makes the requested changes or solves the roadblock, then the team never responds, or takes months to respond. Meanwhile main branch marches on - PRs from the internal paid dev team do get merged often.
I have to imagine that there's a layer of internal politics (maybe VC funding related? dunno) at these companies that shifts more and more communication onto internal nonpublic platforms, to the point where the open-source community rarely gets updates beyond patch notes. It certainly can feel strange when you're on the receiving end of a ghosting. One has to remember that "open-source" does not necessarily mean "community".
This is probably because "add publishing with provenance" is precisely the kind of thing that would ping on my AI slop radar. There are people mass-opening crap issues like this. It's not per se nice to block them and you obviously don't deserve that but you can get type I error only so low before raising your type II.
You could at least evaluate the contribution to see if it is or is not actually slop. From my perspective in security, it's the exact kind of thing that I would expect a thoughtful, helpful community member to do - big project, not a lot of activity but still widely used, moderately sized security win, not super hard to do solo - hey, let's improve security for everyone! - not AI slop.
And, FWIW, cURL - who has been dealing with tons of faux-security AI slop - just recently posted about someone using AI to find 22 actual security issues in cURL, which was helpful. So even if it's AI, it's not necessarily even slop - you should evaluate the contribution on its own merits. Before AI, people opened garbage PRs to popular repos all the time that were unhelpful/noise, they continue to do so now, nothing has changed.
I tend to agree, sure. This doesn't make the PR worse or something.
On the matter of curl yeah I've seen they got actual help that way. Here is the problem. If you are an open-source maintainer there is some proportion of good contributors (most) and some proportion of low-effort spammers (few). AI is a force multiplier for sheer volume. So the spammers all pick it up because they do not care about quality. It can be used carefully to good effect, true, but now your mix of incoming volume goes from "lots of good contributions and a little to spam" to "lots of good contributions and lots of AI stuff" with the latter being mostly slop.
So open-source maintainers with limited time do what all humans do: they fall back on heuristics and adopt a bias against AI output, because now dealing with the spammers on a case-by-case basis takes way more time and just tossing AI stuff becomes easier. Like all heuristics it is imperfect, and I don't know if it's the best way, but I get why they do it.
> In an attempt to reach out to clear up any misunderstandings, I opened a Github issue on my forked repo, tagged the lodash org and primary maintainer, and explained the situation. I gave context as to why I had opened the PR, and what I wanted to achieve. Two weeks later, no response. As a last-ditch effort, I sent an email directly to the same primary maintainer, using an email I found in git commit history
Dude cannot take a no. The lesson here is don't be annoying if you want people to work with you.
Blocking is a "no" and also a "I don't even respect you enough to deliver my answer to you or acknowledge your question". About as tactful as ghosting.
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.
[^0]: https://www.mozilla.org/en-US/about/governance/policies/comm...
[^1]: https://github.com/lodash/lodash/pull/6014
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.
Closing a PR immediately after realizing human error should NOT get a ban.
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.
The insta-banned is I think most likely a bot detection algorithm, which is unfortunate, but not necessarily the fault of the maintainer.
Maybe the project is feature complete? Could it be a sign they don't want contributions which change the build process?
I guess it also didn't help that these kind of PRs are most commonly generated with AI.
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".
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 tried to contribute in the past and the owner was an unprofessional jerk. Instead of replying the PR rejection with arguments, he posted memes and shit
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.
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.
> 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.
It can take a lot of effort to integrate random contributions.
If OSS project maintainers don't want to work with you then just fork it and move on. No need for drama.
A fork does not accomplish the goal here. And tossing out bans for nothing is significantly more of a drama generator than a postmortem.
My only theory is maybe they thought the author was a bot? It seems very odd to block someone over one PR.
You'd be amazed at what people do. I believe that they liked googled the name found something offensive and blocked.
As an aside, since it seems the other comments already address the core issue...
No one should be using Lodash in 2025, it mutates your collections, use `ramda` (https://ramdajs.com/) instead.
Unfortunately, a lot of the early core existing packages have dependencies in lodash, or another packages that does so too.
Ehh what. I would give some merit to arguments like "no one should use lodash in 2025 because you can do most of it with built-ins nowadays" or maybe because it doesn't tree-shake well or maybe even because it doesn't seem to have much active development now.
But stating matter-of-factly that no one should use it because some of its well-documented functions are mutating ones and not functional-style, and should instead use one particular FP library out of the many out there, is not very cool.
Without naming, there seems to be >1 VC-funded companies building "open-source" products, with paid-enterprise or other more sinister business models, where they claim to be open to contributions and have a full CONTRIBUTING.md, and where there's an active community of devs trying to contribute good PRs to solve open issues in the issue tracker.
But the issue tracker is so overwhelmed by slop, non-Latin scripts, and people who think their personal problems (or AI model problems) are the product's problems, that the employees have all but ghosted the issue tracker and PRs; it takes days or weeks for the maintainers (employees) to triage/respond/despam the Github issues list. And if the employees _do_ leave an initial comment on a community PR that multiple users on the issue tracker are begging to be merged, and the PR author makes the requested changes or solves the roadblock, then the team never responds, or takes months to respond. Meanwhile main branch marches on - PRs from the internal paid dev team do get merged often.
I have to imagine that there's a layer of internal politics (maybe VC funding related? dunno) at these companies that shifts more and more communication onto internal nonpublic platforms, to the point where the open-source community rarely gets updates beyond patch notes. It certainly can feel strange when you're on the receiving end of a ghosting. One has to remember that "open-source" does not necessarily mean "community".
This is probably because "add publishing with provenance" is precisely the kind of thing that would ping on my AI slop radar. There are people mass-opening crap issues like this. It's not per se nice to block them and you obviously don't deserve that but you can get type I error only so low before raising your type II.
You could at least evaluate the contribution to see if it is or is not actually slop. From my perspective in security, it's the exact kind of thing that I would expect a thoughtful, helpful community member to do - big project, not a lot of activity but still widely used, moderately sized security win, not super hard to do solo - hey, let's improve security for everyone! - not AI slop.
And, FWIW, cURL - who has been dealing with tons of faux-security AI slop - just recently posted about someone using AI to find 22 actual security issues in cURL, which was helpful. So even if it's AI, it's not necessarily even slop - you should evaluate the contribution on its own merits. Before AI, people opened garbage PRs to popular repos all the time that were unhelpful/noise, they continue to do so now, nothing has changed.
I tend to agree, sure. This doesn't make the PR worse or something.
On the matter of curl yeah I've seen they got actual help that way. Here is the problem. If you are an open-source maintainer there is some proportion of good contributors (most) and some proportion of low-effort spammers (few). AI is a force multiplier for sheer volume. So the spammers all pick it up because they do not care about quality. It can be used carefully to good effect, true, but now your mix of incoming volume goes from "lots of good contributions and a little to spam" to "lots of good contributions and lots of AI stuff" with the latter being mostly slop.
So open-source maintainers with limited time do what all humans do: they fall back on heuristics and adopt a bias against AI output, because now dealing with the spammers on a case-by-case basis takes way more time and just tossing AI stuff becomes easier. Like all heuristics it is imperfect, and I don't know if it's the best way, but I get why they do it.
Seems really wacky that dude got blocked. That’s pretty extreme.
Blocking someone for being annoying? Sure, whatever.
Blocking someone for trying to make a contribution even if it was unwanted? Seems excessive and unhealthy to me.
Github deals with a lot of bots/AI that open pointless/spam/bad PRs/issues/etc.
https://github.com/orgs/community/discussions/158850 https://www.reddit.com/r/developersIndia/comments/1akh9ll/a_...
etc etc etc
Github needs moderation, just like anything else with user-created content.
I am not in the tiniest bit surprised that sometimes moderation makes a mistake, whether human error or automated error.
a nice 4 part series on the SBOM, CycloneDX additions to Raku may be found here … https://dev.to/lizmat/series/32933
A reminder to all, that it is hacktober.
> In an attempt to reach out to clear up any misunderstandings, I opened a Github issue on my forked repo, tagged the lodash org and primary maintainer, and explained the situation. I gave context as to why I had opened the PR, and what I wanted to achieve. Two weeks later, no response. As a last-ditch effort, I sent an email directly to the same primary maintainer, using an email I found in git commit history
Dude cannot take a no. The lesson here is don't be annoying if you want people to work with you.
Dude didn't get a no. And was blocked before doing anything you're calling annoying here.
Block is a no
Blocking is a "no" and also a "I don't even respect you enough to deliver my answer to you or acknowledge your question". About as tactful as ghosting.
A lot of people think it was an anti-bot measure, and if that's true it was not a no to the human contributor.