[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [paho-dev] AI contributions - policy needed?
|
Hey All,
Since all my work customers have gone to 100% AI-generated code, writing
open-source code is the last place I can use my own brain for software.
We're getting a lot of CVE's on the C & C++ libraries that are
undoubtedly AI-generated. There's merit to some of them, but many are
simply bugs that should have been regular Issues without setting off
alarm bells. It gets annoying.
For PR's, my attitude is the same. Review it. Then, if it's slop (AI or
human) reject it. If the underlying idea is sound, ask for it to be
fixed, but if not, leave it for a while, and if there's clearly no human
interest behind it, eventually just close it.
I am using AI on the project, but mostly just for doing bug and
performance reviews, writing doc comments, tracking a CHANGELOG, and
writing unit tests. All the stuff I didn't like or never got around to
doing. It's nice having some help there.
Frank Pagliughi
On 9/21/26 08:30, james.parrott via paho-dev wrote:
Thanks Greg.
Some of these PR authors are apparently clicking through the buttons for the CLA signing process now. Those are great suggestions though.
James.
Sent with Proton Mail secure email.
On Monday, 21 September 2026 at 13:09, Greg Troxel via paho-dev <paho-dev@xxxxxxxxxxx> wrote:
"james.parrott via paho-dev" <paho-dev@xxxxxxxxxxx> writes:
I'm not sure the problem is AI per se - I do use it myself. The
problem's going to become more akin to spam, and 'contributers' that
feel suspiciously like chatbots when you interact with them. I guess
I'm not pushing for a ban, I'm just pushing for an understanding, that
there's no longer an expectation, that any PR submitted without the
tests being run on the fork, must be read.
I don't think any project has ever had a rule that all PRs must be
reviewed to any particular standard. I think it's always been the case
that a reviewer can say quickly that the contribution doesn't meet
standards or isn't in condition such that expenditure of review
resources is reasonable.
It seems easy to have some text to paste in to anything that looks
suspicious
Please explain if this PR contains any LLM-generated text.
Please review the contributor guidelines and explain what testing you
have done.
Please close this PR and rebsubmit when ready, with text and code
changes that are minimal and concise, in the way a human who
understands the codebase would craft them.
or something like that. The example of many PRs in a few hours that on
10 minute reading would seem to be properly many fewer and organized
better is the kind of thing that should just be rejected with a note
that the human should re-organize and trim.
There is a longstanding concept of "entry criteria" to inpsection
(inspection ~== formal/careful peer review) as a software engineering
process.
https://archive.org/details/softwareinspecti0000gilb
The details are paged out, but the basic concept is that cursory,
high-speed quality checks (by a human, back then) must show that the
code/whatever is good enough that it's a sensible use of resources to
conduct an inpsection.
We haven't really dug into this in the open source world because
pre-LLMs, incoming PRs were often reasonable enough, or were few in
number.
It would also be reasonable to require that any PR that seems to use LLM
must have a CLA on file before any review at all. Or perhaps that PRs
may only be submitted if CLA is on file, except for one PR that does not
involved LLM use. Humans starting out often submit a PR before CLA, and
wheen it's thoughtful and just one, that's fine.
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev
