I thought the same at first, but if you look at the discussion page linked at the end, there's an example of some package descriptions that were auto-generated but the result was very inaccurate -- claiming features that aren't even close to what the package offers. Not knowing the contents of the package, you might not notice. And it would definitely trip up any attempt at indexing these descriptions for search.

Then a bot responded to the discussion poster's concerns and it was humorous but also it offered no way to resolve the issue.

So there are one or two cases where a maintainer might notice something off and this policy would offer a clear-cut way to reject whatever submitted the inaccurate decisions or to take the AI out of the discussion forum.

But for the cases of copilot-authored code I don't think there's any reliable way to detect or reject it. This probably falls under their "but not upstream changes" caveat.

So in reality it would probably end up as a faster way to reject unhelpful or harmful uses of AI. If you manage to auto-generate correct package descriptions (maybe through human review) nobody has a reason to complain, even if you overuse the word "delve" a bit.

At the same time, if you produce text and code that reads overly like a bot, they may have just cause to dismiss your submission and maybe even ban you, if we're being so teleological about it.

I don't personally agree this particular line in the sand will help in all cases -- it is a difficult standard determining whether something is AI-created, this will likely increase the burden on the humans in the loop. But as policies go, it makes sense to have a line drawn in the sand for outright rejecting it on source not content, especially in the context of a package manager and Linux distribution. The burden on said humans in the loop will be even greater if they don't have a rule in place granting blanket dismissal on this characteristic, especially if they're correct in seeing an increase in AI-produced packaging of unknown binaries.

Isn't that the point of code reviews, though? A human can write incorrect descriptions as well. This one is incredibly easy to catch for any maintainer of the project.

Of course, it'll get harder and harder to spot the problems, but that just brings the "bug" closer to the human-generated level.

Banning AI doesn't fix the problem, especially since the type of person that would have AI generate a description and then not even read it also isn't going to follow the rules.

The problem is that current LLMs are capable of creating junk that's prima-facie plausible in industrial quantities, and finding the sound material within it is a big and growing burden for any organization, especially those that accept contributions from the public.

> The type of person that would have AI generate a description and then not even read it also isn't going to follow the rules.

This is not a sound argument against this rule; it is an argument for the proposition that current LLMs present a threat to the open-source model, despite this rule.

> A human can write incorrect descriptions as well.

Sure they can, but the descriptions are completely irrelevant to what the package or project at hand does.

The author clarifies that there is no way to detect it. He only wants it explicitly stated in the policy: "don't bring that".

Yes, this would be like the Wikipedia policy that uncited material can be deleted at any time.

Human-generated and AI-generated aren’t mutually exclusive categories anyway. For example, a person writing a document (or software package) can start out with some rough human-generated notes, pass them to an AI to flesh out, and then edit the AI’s output to improve it, fix anything the AI got wrong (or even that they just don’t agree with, e.g. “this code is correct but it’s not how I’d write it”)

What’s the fundamental difference between that and a human doing it without an AI’s help at all? It could be essentially the same outcome, just more time and human effort

It's very easy to tell. AI fanboys will show you the most generic and bland pictures with crippled limbs and go "See? You probably can't tell if it was AI generated or not"

The code is usually equally braindead. Not that it matters of course, most code that humans write today isn't much better, but if you value quality like many foundational open source projects do, the difference becomes obvious.