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.
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.
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.
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.
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.
> 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.
If OSS project maintainers don't want to work with you then just fork it and move on. No need for drama.
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.
I guess it also didn't help that these kind of PRs are most commonly generated with AI.
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.
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.
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.
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.
It can take a lot of effort to integrate random contributions.
> 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.