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.
ecshafer 5 hours ago [-]
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.
andrewflnr 3 hours ago [-]
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.
ecshafer 3 hours ago [-]
The insta-banned is I think most likely a bot detection algorithm, which is unfortunate, but not necessarily the fault of the maintainer.
petre 59 minutes ago [-]
Maybe the project is feature complete? Could it be a sign they don't want contributions which change the build process?
altbdoor 4 hours ago [-]
I guess it also didn't help that these kind of PRs are most commonly generated with AI.
neoCrimeLabs 4 hours ago [-]
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.
WhyNotHugo 4 hours ago [-]
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.
_flux 28 minutes ago [-]
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?
scheme271 2 hours ago [-]
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.
just_mc 4 hours ago [-]
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.
spookie 1 hours ago [-]
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.
fn-mote 3 hours ago [-]
> 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.
herpdyderp 4 hours ago [-]
It can take a lot of effort to integrate random contributions.
whycombinetor 41 minutes ago [-]
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".
beckthompson 2 hours ago [-]
My only theory is maybe they thought the author was a bot? It seems very odd to block someone over one PR.
worthless-trash 2 hours ago [-]
You'd be amazed at what people do. I believe that they liked googled the name found something offensive and blocked.
nradov 4 hours ago [-]
If OSS project maintainers don't want to work with you then just fork it and move on. No need for drama.
Dylan16807 3 hours ago [-]
A fork does not accomplish the goal here. And tossing out bans for nothing is significantly more of a drama generator than a postmortem.
xx__yy 2 hours ago [-]
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.
pizlonator 2 hours ago [-]
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.
freddie_mercury 1 hours ago [-]
Github deals with a lot of bots/AI that open pointless/spam/bad PRs/issues/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.
landl0rd 4 hours ago [-]
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.
arcfour 2 hours ago [-]
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.
landl0rd 2 hours ago [-]
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.
Dylan16807 3 hours ago [-]
Dude didn't get a no. And was blocked before doing anything you're calling annoying here.
thenanyu 3 hours ago [-]
Block is a no
schmookeeg 2 hours ago [-]
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.
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
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.
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?
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.
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.
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".
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.
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.
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.
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.
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.
Dude cannot take a no. The lesson here is don't be annoying if you want people to work with you.