Post

open source projects may need to lock PRs to trusted folks. careless slop is sucking the life out of maintainers. we need better tools to talk to and onboard new contributors while interacting on issues. more friction could actually help new folks who care stand out, and let the community breathe

we were talking about this with @vladimir.berlin and @bluwy.me. i've always pushed back against locking PRs. i feared it would make the barrier higher for new folks to join open source communities. but if their work is covered by noise, other avenues than PRs to gain trust may end up helping them

0 reposts24 likes

My current hatred is slop accounts just targeting any "good first issue" or "help wanted" labelled issue. They usually have zero interest in actually working with the project. I'm not sure what the grift is yet though

I think the main grift is still generating activity to use GitHub when looking for a job. Some of it may be people that think they are actually helping, but I don't think they would continue after so many maintainers tell them to stop, though.

I'm wondering whether it's actually to gain CI access on a broad range of repositories? I don't think anyone cares about GitHub activity in the age of AI?

For what I've seen around, it's stats farming for fame, stats farming for CVs, and sometimes is genuine willing to contribute but with zero knowhow on how to control an ai agent. Also, last but not least, the classic case where they are just trying to sneak in some malware.

I saw some accounts that were clearly doing it for the activity, even if it doesn't make sense (it never did to be honest). @matteogabriele.npmx.social, maybe you have a more general picture of why people are sending slop PRs?

maintainers are starting to ignore PRs altogether as the chance to find a real caring human on the other side is diminishing. being ignored is worse for new folks than having to go through a longer process to be able to contribute. communities will adapt, here hoping towards more human connection

By now I'd prefer a well written issue-description without PR. Let my own coding-agent write the implementation. Mixing pre- and post- agentic-AI workflows can cause a lot of friction.

I've rarely found an agent that can't assimilate good ideas where it finds them. Start yours without looking at the other solution! But double back, have some tokens to compare, see what to take forward.

In truth I think there's a lot of value doing the exact opposite: instead of writing up the problem & design constrians, the maintainer could often have their agent generate that intent from a pr. Writing out intent as words can be much lossier, hard to balance. Just send the code has value too.

yes, the value of a PR isn't in the generated code

patak@patak.cat

The changed code is a small fraction of an open source contribution. Your commitment to understand the issue, how your proposed solution fits with the project, and be ready to own and push the review process forward is the biggest chunk of the work. Your effort is the contribution, not the code.