> Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years
Github is in my profile; I am nixpkgs committer for ~10 years (which is one of the most active projects on Github with 450000 merged PRs).
There is no way I could have possibly written and (pre-tested, to arrive at the eventual code submitted) all the code that I have reviewed.
From the other side, I have spent thousands of hours debugging and writing PRs to over 100 FOSS projects (e.g. glibc, busybox, util-linux, lz4, GHC and tens of Haskell packages, Jenkins, Chromium, GTK, Consul, OpenCV, Signal, many more).
Many of them are small or medium fixes ("drive-by fixes"), where you propose a PR, the owner reviews, says "great, thanks", and the bug gets fixed.
This is a fundamental workflow for open source work. The project gets free contributions and time investment outsourced to "the community" who fix its bugs, the developer-users/community get their problems fixed upstream, permanently.
This not possible for projects that don't have an easy way to submit code with low effort for both sides.
Accepting drive-by fixes is what clears up developer time and helps clear out the countless small issues in software.
If AI slop PRs are a problem, it seems better to establish clear rules and reject contributions that don't follow them with a single click, rather than banning developer contributions altogether. It seems to work acceptably for nixpkgs so far.
Thanks for your work on nixpkgs but I think that shapes your perspective quite a lot - its a very different project from Ladybird. Not to belittle your contributions there but the majority of commits there are a few lines of code and much of it is declarative. I'm sure a lot goes into review of entirely new packages and there are some complex interactions between dependencies to consider on some changes but not in a program structure or logic sense. Vibe slop may not be so much an issue there.
It is simply a fact that most commits are small - that is the nature of that kind of project. I looked at the commit history. It still takes a lot of work and it is valuable, but it has very different review requirements.
Ok, how come your little comprehension examination didn’t grapple with the main point: that they said they could not have made the changes they merged in themselves? Surely pointing out that the commits were small cuts AGAINST your whole argument. For a more complex project where vibe slop might not be appropriate (again, wild thing to say), the potential input from outside is more valuable, not less.
Github is in my profile; I am nixpkgs committer for ~10 years (which is one of the most active projects on Github with 450000 merged PRs).
There is no way I could have possibly written and (pre-tested, to arrive at the eventual code submitted) all the code that I have reviewed.
From the other side, I have spent thousands of hours debugging and writing PRs to over 100 FOSS projects (e.g. glibc, busybox, util-linux, lz4, GHC and tens of Haskell packages, Jenkins, Chromium, GTK, Consul, OpenCV, Signal, many more).
Many of them are small or medium fixes ("drive-by fixes"), where you propose a PR, the owner reviews, says "great, thanks", and the bug gets fixed.
This is a fundamental workflow for open source work. The project gets free contributions and time investment outsourced to "the community" who fix its bugs, the developer-users/community get their problems fixed upstream, permanently.
This not possible for projects that don't have an easy way to submit code with low effort for both sides.
Accepting drive-by fixes is what clears up developer time and helps clear out the countless small issues in software.
If AI slop PRs are a problem, it seems better to establish clear rules and reject contributions that don't follow them with a single click, rather than banning developer contributions altogether. It seems to work acceptably for nixpkgs so far.