pull down to refresh
260 sats \ 2 replies \ @optimism 21 Nov \ on: The problem with AI generated contributions to open source projects AI
You don't want to be wrong or negligent though. The issue is that something flagged up by an LLM can be valid, and you don't want to dismiss the underlying issue. What I currently do on my own repos is:
- Always judge for urgency: if something is urgent, process it regardless.
- Smell for slop. if something has a slop smell, deprioritize and don't look at it unless there is nothing else to do. If it's a sloppy feature, just ignore it forever.
- Ask questions. If someone cannot answer why propose something, deprioritize, or build an alternative non-sloppy solution and propose that.
Note that while this keeps most contributors that actually write code happy, it will piss off the vibe coders / talkers.
I've not yet made this a contribution guideline though. If someone wants to read and review slop, I let them. Though that rarely happens haha
It will piss off the vibe coders / talkers.
I thought about including a paragraph or two on this: basically, yes.
I was at a bitdevs last night, and there was a little discussion of the whole BIP 444 thing and someone was going strong on this idea that the people working on Core should have accommodated the people who wanted the option to change their datacarriersize limit.
It feels the same as accommodating the people who want to be able to submit BIPs without having put in enough time and effort to be able to write the BIP on their own.
I don't see how Open Source equals Communially Owned, nor do I understand why people who work on an open source project should be responsive to me, a user.
They can be responsive, if they want, but they can also ignore users and perhaps users will go elsewhere. Perhaps there will be a vibe-coders' implementation of Bitcoin to which the vibe coders can all submit their BIPs. I don't think I'll run it, though.
I'd much prefer the market to determine who handles vibe coder submissions the best.
reply
someone was going strong on this idea that the people working on Core should have accommodated the people who wanted the option to change their datacarriersize limit.
Isn't that the state of the thing right now? I still don't understand the issue people take now that everything is as it was.
without having put in enough time and effort to be able to write the BIP on their own.
That's why deprioritizing is a thing. It's not no, but instead it balances the effort. If you expect High Quality Service, then you gotta propose High Quality Work.
I don't think I'll run it, though.
Not unless vibe coding suddenly becomes high quality coding, indeed.
reply