| Re: [paho-dev] AI contributions - policy needed? |
|
Hi Frank,
It's the same that's happening with the Linux Kernel, lots of bug reports, but most are garbage.
I can help a bit with the PR's/Issues on C/C++ if needed.
Pau Figueras | Software Engineer De: paho-dev <paho-dev-bounces@xxxxxxxxxxx> de part de Frank Pagliughi via paho-dev <paho-dev@xxxxxxxxxxx>
Enviat el: dilluns, 21 de setembre de 2026 15:53 Per a: paho-dev@xxxxxxxxxxx <paho-dev@xxxxxxxxxxx> A/c: Frank Pagliughi <fpagliughi@xxxxxxxxxxxxxx> Tema: Re: [paho-dev] AI contributions - policy needed? CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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 _______________________________________________ paho-dev mailing list paho-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev |