The way that this is written strikes me as wildly over-optimistic and dangerously credulous towards slopmongers' claims about capabilities.

[mcc@mastodon.social]

@glyph i wonder if codeberg could be convinced to, instead of allowing participation by default, allowing something like an onboarding pass like Discords have. where you have to do something to get added to an allowlist before you can submit (issues/PRs/comments/whatever).

[tante@tldr.nettime.org]

@mttaggart @glyph "FOSS as part of a larger social justice project".

THANK YOU. THAT

[glyph@mastodon.social]

@mttaggart I think that most projects should maintain hard boundaries around rejecting any LLM output, for the reasons that you suggest, although obviously we have a long way to go on convincing people of that. However, "AI PRs not accepted" is not the same policy as "hurl expletives and insults at everyone who tries". *Some* of the people who are trying just don't know any better, and might be amenable to a friendly invitation to try again with code they wrote themselves.

[sabrina@fedi01.unicornsparkle.club]

@glyph I've suggested this as a sort of "good faith" filter. Do they care about consent? Can you redirect them to thinking about consent? I'd be curious to know if it works.

Phie Lux (@sabrina@fedi01.unicornsparkle.club)

@zkat @xgranade I have an idea. If somebody tries to use the "unenforceable" argument, ask them if they would break the rules. If they say yes, they've outed themselves and that's an easy ban. If they say no, push them to see if they can identify the type of person they think would break the rules. Push back the ideological front lines and direct their attention to the bad actors they should be working against.

fedi01.unicornsparkle.club (fedi01.unicornsparkle.club)

[glyph@mastodon.social]

@mcc I am stuck on github for a bunch of reasons but if codeberg actually added clear, automation-assisted workflows for marking people as [potential contributor ️ contributor ️ auditioning maintainer ️ maintainer ️ core team ️ emeritus that might be a feature I need badly enough to switch

[glyph@mastodon.social]

@mcc re: the blocklist, I think that it's something that would need to be handled very carefully, as we have previously seen that Making Lists can get us all into trouble very fast. but there's probably a way to do it without turning it into a professional blackball machine when the hype rebounds

[mcc@mastodon.social]

@glyph codeberg could probably be persuaded to add this if they got a PR for it. especially if you want a complex Jira-like flow like that, even if they had the time to architect it out they probably would not come up with the exact design you're looking for.

[pathunstrom@ngmx.com]

@mcc @glyph I feel like I might need to make a corollary to the Olivia Hill rule.

[benjamineskola@hachyderm.io]

@glyph It often feels to me like this relates to a broader problem around boundaries.

Like the smaller scope is what feels to me (subjectively, maybe confirmation bias) like people keep pushing non-users to reconsider trying LLMs. The new model is better, your objections are out of date.

(And obviously the scale of that for a maintainer is likely to be much worse anyway.)

But that in turn also makes me think of the deceptive/coercive patterns of ‘not now’ or ‘maybe later’ where no is never an option; your refusal is always open to reconsideration.

[mttaggart@infosec.exchange]

@glyph I don't disagree on principle, but how do you imagine a hard ban (such as the one I just implemented for IFIN) be enforced? I don't know how you do it other than only accepting PRs from known, trusted members of a community and not the internet at large. Like you need some sort of filtering process if you actually want to ban generative code, and the filter probably won't be anything like a code smell for long.