Hey option d, please create a website to sell stuff similar to ebay but with a vibe for old/vintage stuff, don't review and push to github... it's fine if it's the contractor of the contractor that just cares about closing tickets?
Not picking on you, I know biological processes/brains/humans are inherently "efficient"/lazy... but there is some irony in wanting things to be correct without wanting to spend any effort on the thing? is like reading a 100 char message and deciding it's true and take decisions around it.
So, when I see an AI wall of text without any editing, I assume that the author did not bother spending their time on it, but they want me to spend more of my time on reading it than they spent on creating it, and I refuse. Everyone has access to the same AI, and if I want to read AI generated text with little to no human author involvement, I'll go ask ChatGPT or Claude.
Same goes for GitHub slop PRs which are faster to create than to review.
On the other hand if there is no AI involved, but as another comment here mentions, before ai times, the ntfs driver that was not polished enough, then it's also slop.
But also, even the NTFS driver passes my test of "more effort to create it than to review it", by the way.
Github/Gitea issue with feature request; typically not slop
Github/Gitea PR with AI-implimented feature; typically slop
The issue is almost always drive-by contributions. A lot of programmers don't care about dependency creep, SLOC management, SDLC nicities, fragile CI/CD or multiplatform testing. Many FOSS maintainers and core contributors have a much higher standard for what they're willing to merge, and therefore reject slop judiciously. Same goes for one-man-band vibe coding outfits that want to ship a half-assed "native" app and charge money for it. Most of these people don't understand what the industry considers standard, even with AI helping them.
FWIW, there were slop PRs even before AI. Famously Paragon's NTFS driver was so bad that Linux refused to merge it because the costs outweighed any potential benefits. It ultimately came down to a difference in culture between FOSS and closed-source development.