I ain’t shook up about it. There’s not really a surefire way to detect tool-assisted code gen anyway, so IMO the acceptance criteria should be the same as it’s always been, tool-assisted or otherwise. Which is ultimately the path they chose to take.
Obvious slop should be immediate permanently banworthy, sloppers can just keep burning new accounts (as long as they have access to new IP addresses) while real developers deserving of praise and reputation thrive.
sloppers can just keep burning new accounts (as long as they have access to new IP addresses) while real developers deserving of praise and reputation thrive.
Becoming a Debian developer requires you to meet an existing Debian developer in person and have your public key signed by them. It’s not possible to keep burning new accounts unless you go and meet a different Debian developer each time and there’s a limited number of them in each region and they usually meet together, so more than one person will see your face.
Yep. I’m not familiar with Debian’s strategy specifically, but generally, I think any new contributor to a project should be subject to heightened scrutiny. My policy is that new contributors should start small and develop a rapport with the maintainers before submitting more ambitious (and for the maintainers, more costly to review) large and/or critical path PRs. It was a good policy before LLMs and I think it remains a pretty robust method of weeding out irresponsible devs without wasting a ton of maintainer time. There are simply more slop PRs to reject sight unseen these days, which is admittedly very annoying, but the process is much the same as it’s always been.
I’ll admit I don’t maintain any projects anywhere near the popularity or volume of the Debian project, so I’m not really sure what the view is from their vantage point.
I still think that’s not good enough, that treating them fairly is a stupid waste of time and resources and unfair to everyone else.
Just make the rule “any slop” and give the idiots a checkbox so they can ban themselves for reasons which will never be revealed to them (sloppers don’t read documents, it’ll take them a while to figure out). Also start banning people when evidence surfaces of them admitting to slopping.
I don’t like this concept that a slopper can potentially produce decent code, the data shows this simply isn’t true: sloppers produce vast amounts more and worse bugs and vulnerabilities. It’s better for the health of the project to ban it in every scenario.
How is treating one contributor fairly unfair to another contributor? If you want to add a “check this box to get your PR dumpster’d” checkbox I guess go nuts, but I’m unconvinced that’s a good long-term solution. I find it easier to ask “Do I know this contributor, or did they follow the new contributor guidelines and submit a small, single-issue PR?”, and if the answer is “no” then the PR gets ignored or, if I’m feeling gregarious and have the time, rejected with change requests. It’s a pretty easy rubric.
Humans have been perfectly capable of generating huge volumes of trash code, and code that looks good at first glance but has tricky bugs or vulnerabilities, since long before LLMs were a thing. The only real change now is the pace at which shitty code can be ripped out. IMO the solution is just: don’t accept more code than you can review and test. If that means rejecting 10x or 100x more LoC than you did five years ago, then… ok. It is more busy work, and it is annoying. But I don’t think trusting contributors to self-declare LLM use is an answer to the problem. There are better ways of rate-limiting eager beavers, regardless of what tools they use.
How is treating one contributor fairly unfair to another contributor?
Because sloppers do not actually do the work and in the vast majority of cases are not even capable of doing so. A slopper can produce 10 worthless products in the time a person can produce 1 good product.
I ain’t shook up about it. There’s not really a surefire way to detect tool-assisted code gen anyway, so IMO the acceptance criteria should be the same as it’s always been, tool-assisted or otherwise. Which is ultimately the path they chose to take.
Obvious slop should be immediate permanently banworthy, sloppers can just keep burning new accounts (as long as they have access to new IP addresses) while real developers deserving of praise and reputation thrive.
Becoming a Debian developer requires you to meet an existing Debian developer in person and have your public key signed by them. It’s not possible to keep burning new accounts unless you go and meet a different Debian developer each time and there’s a limited number of them in each region and they usually meet together, so more than one person will see your face.
Yep. I’m not familiar with Debian’s strategy specifically, but generally, I think any new contributor to a project should be subject to heightened scrutiny. My policy is that new contributors should start small and develop a rapport with the maintainers before submitting more ambitious (and for the maintainers, more costly to review) large and/or critical path PRs. It was a good policy before LLMs and I think it remains a pretty robust method of weeding out irresponsible devs without wasting a ton of maintainer time. There are simply more slop PRs to reject sight unseen these days, which is admittedly very annoying, but the process is much the same as it’s always been.
I’ll admit I don’t maintain any projects anywhere near the popularity or volume of the Debian project, so I’m not really sure what the view is from their vantage point.
I still think that’s not good enough, that treating them fairly is a stupid waste of time and resources and unfair to everyone else.
Just make the rule “any slop” and give the idiots a checkbox so they can ban themselves for reasons which will never be revealed to them (sloppers don’t read documents, it’ll take them a while to figure out). Also start banning people when evidence surfaces of them admitting to slopping.
I don’t like this concept that a slopper can potentially produce decent code, the data shows this simply isn’t true: sloppers produce vast amounts more and worse bugs and vulnerabilities. It’s better for the health of the project to ban it in every scenario.
How is treating one contributor fairly unfair to another contributor? If you want to add a “check this box to get your PR dumpster’d” checkbox I guess go nuts, but I’m unconvinced that’s a good long-term solution. I find it easier to ask “Do I know this contributor, or did they follow the new contributor guidelines and submit a small, single-issue PR?”, and if the answer is “no” then the PR gets ignored or, if I’m feeling gregarious and have the time, rejected with change requests. It’s a pretty easy rubric.
Humans have been perfectly capable of generating huge volumes of trash code, and code that looks good at first glance but has tricky bugs or vulnerabilities, since long before LLMs were a thing. The only real change now is the pace at which shitty code can be ripped out. IMO the solution is just: don’t accept more code than you can review and test. If that means rejecting 10x or 100x more LoC than you did five years ago, then… ok. It is more busy work, and it is annoying. But I don’t think trusting contributors to self-declare LLM use is an answer to the problem. There are better ways of rate-limiting eager beavers, regardless of what tools they use.
Because sloppers do not actually do the work and in the vast majority of cases are not even capable of doing so. A slopper can produce 10 worthless products in the time a person can produce 1 good product.