3 ms·

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

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.

wongarsu 3y ago
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.
- kevindamm 3y ago
  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.
wccrawford 3y ago
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.
- johnisgood 3y ago
  > 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.
- mannykannot 3y ago
  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.

wongarsu 3y ago

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.

kevindamm 3y ago
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.

wccrawford 3y ago

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.

johnisgood 3y ago
> 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.
mannykannot 3y ago
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.