How about creating issues and tagging the ones where PRs are welcome and inform everyone about this way of work? I understand the frustration, when someone comes one day to the project with tens PRs and most of them are missing the point of application or going way out of scope, that will surely make maintenance in the future problematic. Everyone's time will be saved by informing about contribution limits upfront.
I don't want your PRs anymore
141–148 of 148 posts
Re: I don't want your PRs anymore
#142This is sad. Human endeavors always benefit from the distributed contribution of the many, which keps everyone's egos and preferences in check while approaching the most optimal global solution in the limit. Every social institution works like this, and FOSS is no different. Centralization almost never works in social endeavours. Not to mention the dubious ethical implications of using (potenially stolen) LLM code in…
Sadly, it's not a great time to be a autistic revolutionary type. Too easy to get cancelled when you make women uncomfortable, or something. Look up what happened to Richard Stallman if you're not sure what I mean. No-doubt he'll be replaced by someone who says Safe Things that don't offend HR departments.
Re: I don't want your PRs anymore
#143This seems...fine? I know when I run into bugs in a project I depend on, I'll usually run it down and fix it myself, because I need it fixed. Writing it up the bug along with the PR and sending it back to the maintainer feels like common courtesy. And if it gets merged in, I don't need to fork/apply patches when I update. Win-win, I'd say. But if maintainers don't want to take PR's, that's cool, too. I can appreciate…
The ghost-PR problem is real though. Someone opens a PR that changes behavior they needed, you as the maintainer have to decide between three bad options: merge and own the new surface, reject and feel like a jerk, or let it sit and drain everyone's time. Forking is the clean answer when your needs diverge enough. The cost is duplicate work when the upstream fixes something you fixed six months ago in your branch.
Re: I don't want your PRs anymore
#144I have come to a similar realization recently - its what I call "Take it home OSS" - i.e. fork freely, modify it to your liking using AI coding agents, and stop waiting for upstream permissions. We seem to be gravitating towards a future where there is not much need to submit PRs or issues, except for critical bugs or security fixes. It's as if OSS is raw material, and your fork is your product.
This is very shortsighted and it’s like polishing gun to shoot your foot with it. If it’s "take it home OSS" and "there is not much need to submit PRs or issues" then why would anybody submit PRs and issues for "for critical bugs or security fixes"? If they have fix and it works for them, they’re fine, afterall. And while we’re at it, why would anybody share anything? It’s just too much hassle. People will either com…
> why would anybody share anything
Before LLMs, it was cheaper in the long run; by upstreaming your patches you don't have to rebase them continually and sometimes the community will maintain the code for you. OTOH sometimes you might need to work on the code again though as other parts of the project evolve if the project is likely to throw out unmaintained code; this is especially true in the Linux kernel where internal APIs change constantly, but upstream maintenance is probably cheaper than continually backporting security fixes to your stable/LTS/SLTS or completely dead versions.
With LLMs the costs might be different but will still exist.
Re: I don't want your PRs anymore
#145Review was always the expensive part. Contributions are now just well written GitHub issues...
Re: I don't want your PRs anymore
#146This guy fails to communicate properly how others can and should contribute to his project. I see this all the time where the standards of a project aren't properly documented so the reviewer/maintainer just wastes time reviewing the same thing thousands of times until they give up.
Re: I don't want your PRs anymore
#147I think every maintainer should be able to say how they want or don't want others to contribute. But i feel like it was always true that patches from the internet at large were largely more trouble then they were worth most of the time. The reason people accept them is not for the sake of the patch itself but because that is how you get new contributors who eventually become useful.
Exactly! Documenting how others can contribute to your project, if you accept contributions, is the only way to go.
Re: I don't want your PRs anymore
#148This seems...fine? I know when I run into bugs in a project I depend on, I'll usually run it down and fix it myself, because I need it fixed. Writing it up the bug along with the PR and sending it back to the maintainer feels like common courtesy. And if it gets merged in, I don't need to fork/apply patches when I update. Win-win, I'd say. But if maintainers don't want to take PR's, that's cool, too. I can appreciate…
The ghost-PR problem is real though. Someone opens a PR that changes behavior they needed, you as the maintainer have to decide between three bad options: merge and own the new surface, reject and feel like a jerk, or let it sit and drain everyone's time. Forking is the clean answer when your needs diverge enough. The cost is duplicate work when the upstream fixes something you fixed six months ago in your branch.
It's ok to reject for any number of (or no) reasons. Nobody needs to feel like a jerk for taking a project in the direction they want.