hi again:)
On Mon, Aug 24, 2026, 1:49 AM Christian Schneider <[email protected]> wrote: > Am 23.08.2026 um 20:41 schrieb Osama Aldemeery <[email protected]>: > > Since this isn't the first time this has come up, I'd like to ask > whether it's time internals discussed an AI-usage policy? > > > > A written document would tell contributors what is and isn't acceptable > here. Whether that is a disccussion, an RFC, or a PR. > > And it would save everyeone from settling it case by case each time. > > > > It is not new ground either...Python, CURL, Linux Kernel, and Fedora > (among others) have all faced the same issue, and each landed on a policy. > > > > For reference: > > Python: https://devguide.python.org/getting-started/generative-ai > > curl: https://curl.se/dev/contribute.html#on-ai-use-in-curl > > Linux kernel: https://docs.kernel.org/process/coding-assistants.html > > Fedora: > https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy > > > One little note here: The above seems to concern code contributions like > PRs. > I was more talking about the discussions here on the internals mailing > list. > > But in the end it applies to both: How do we handle the higher amount of > generated code and mails. > And how can guidelines hopefully somewhat protect the limit resources of > the PHP maintainers? > Most if not all security i could see are discovered by AI. I can imagine many PRs are, at least, partially AI generated too. One issue I mentioned was the process (I need another word as this not a process anymore at this stage), and will, or ability, to delegate reviews of PRs. We cannot expect RMs, or RFC policies checkers to have the knowledge for everything in php-src. The latter, and delegation, is harder to solve than the policies. I only we don't even think about an anti AI policy or similar bad ideas :) cheers, -- Pierre @pierrejoye >
