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

[mttaggart@infosec.exchange]

@glyph Couple of quick thoughts.

1. "Slop-haunted world" is very good.
2. The original post is a masterclass in FOSS myopia, focusing only on code and ignoring the social implications of the code or its provenance.

Assuming agents can produce reasonable code output (hardly guaranteed), is more of it "good" for FOSS? I am unclear if that's even true, since I agree with your point that what most projects need are maintainers, not more PRs. But I also think of FOSS as part of a larger social justice project, and in that context, I am really not so sure that happy acceptance of model-generated code as a norm is ultimately "good" for the movement. At least, not as currently constructed.

[astraluma@tacobelllabs.net]

@mcc @glyph based on how the Olivia Hill rule goes, this would be shockingly effective

eg, this thread: https://ngmx.com/@pathunstrom/115545419415666949

[glyph@mastodon.social]

@mcc I have to guess "no" if not even zkat has done so, even after *multiple* comments from the offender in the above post.

This strikes me as a situation where different approaches make sense in different contexts. Some projects should probably take that approach, and maybe even collaborate on blocklists to kick out transgressors. Other projects with higher emotional bandwidth might want to have an explicit goal of rehabilitation.

[mcc@mastodon.social]

@glyph the blocklist idea is interesting to me

[cypnk@masto.hackers.town]

@glyph How dare you have boundaries! /s

I don't know how common this is, but there are quite a few places which have adopted (with various wording) "sealioning, intentional or not, will be destroyed with extreme prejudice". This seems to have preemptively reduced or outright stopped this sort of thing before it takes hold

I'm reminded of a very practical treatise written years ago by Joel Spolsky
https://www.joelonsoftware.com/2003/03/03/building-communities-with-software/

After all these years, it's amazing how much of it holds up

[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.