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

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

0 reposts24 likes

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.