My comment may only be tangent to the topic. Oscar mentioned that there are over 900 PRs. I checked and the oldest one is from 2012! My question: If a PR sits around for over a year and has not been merged, does this not indicate that it might not be a great one? Would it make sense to just close untouched PRs that are beyond a certain age?
I am just a user, not a contributor, just following the discussions. Peter Jason Moore schrieb am Samstag, 31. Januar 2026 um 17:03:30 UTC+1: > I agree that this PR can be closed based on the new policy. It sounds like > you missing Chris's review was then just an oversight. > > Jason > moorepants.info > +01 530-601-9791 <(530)%20601-9791> > > > On Sat, Jan 31, 2026 at 1:15 PM Oscar Benjamin <[email protected]> > wrote: > >> Let's just clarify the individual points here: >> >> - Do we agree that the code is AI generated? >> - Do we agree that this was not honestly disclosed? >> - Do we agree that the AI policy prohibits that and says we will close >> a PR in that case? >> >> I agree that it should be done more politely but if we don't have a >> clear "undisclosed AI means close PR" rule then I think that the >> policy is a failure. >> >> Any suggestion that more effort, thought, discussions etc goes into >> the decision to close an AI PR is missing the point that the problem >> they cause is the time that it takes to sift and review them. The >> effort ratio where someone can type a prompt and have an AI make a PR >> and then a reviewer has to spend actual time considering its technical >> merit is precisely the problem and we need a solution that is minimal >> effort on the maintainer side. >> >> I'm not sure if I even noticed that Chris was reviewing the PR. I just >> saw people mentioning LLMs, looked and saw that the code was AI >> generated and then looked and saw that the AI disclosure was >> dishonest. >> >> It is perhaps worth pointing out that the sympy repo has been drowning >> in PRs for a long time. There are 921 open PRs and that number only >> goes up. This was already unsustainable before the AI PRs came along. >> >> Oscar >> >> On Sat, 31 Jan 2026 at 06:56, Jason Moore <[email protected]> wrote: >> > >> > A core dev was engaging with the PR, so closing it over top of them is >> not polite. Ideally we would not do such a thing at all (AI involved or >> not). We should also be more polite in the comments to the contributor, >> even if we are talking to an AI bot. >> > >> > My suggestion would be that any core dev who wants to apply the policy >> should ask the other core devs involved in the PR discussion before making >> the universal call. >> > >> > Jason >> > moorepants.info >> > +01 530-601-9791 <(530)%20601-9791> >> > >> > >> > On Fri, Jan 30, 2026 at 11:12 PM Oscar Benjamin <[email protected]> >> wrote: >> >> >> >> On Fri, 30 Jan 2026 at 20:28, Chris Smith <[email protected]> wrote: >> >> > >> >> > I’d like to raise a process question regarding the application of >> the AI policy to reviewed pull requests. >> >> > >> >> > A recent PR addressing a long-standing performance issue in >> degree() was closed with the label “AI slop,” >> >> >> >> I definitely should have been more polite so I will acknowledge that. >> >> I guess I must have been getting annoyed with there being so many low >> >> quality and AI PRs. >> >> >> >> If you want to review and merge that PR then go ahead. >> >> >> >> > The author disclosed AI usage and stated that finding the source of >> the problem and design were manual >> >> > >> >> > The PR appears to comply with current AI policy as written (or at >> least I don't see the violation) >> >> >> >> I think that this is a bit disingenuous and that you know that the >> >> code was all written by AI and that this was not honestly disclosed. >> >> The AI policy says that you should explain how you have used AI and >> >> that is in the PR template but what was written there was just "review >> >> suggestions were provided by an AI tool". Maybe you read that >> >> differently from me but what it should honestly say is "the code was >> >> all written by Claude". >> >> >> >> Much like I can see a few lines of code and know immediately that it >> >> was written by Christopher Smith I can also see a few lines of code >> >> and know that it was written by Claude or its ilk. I'm pretty sure >> >> that you can also read a few lines of code and say the same things. >> >> >> >> > As the AI policy currently stands, it permits AI-assisted >> contributions provided the author understands and takes responsibility for >> the code. And having reviewed the code, I can't see why labelling it as “AI >> slop” is a sufficient basis for closure in the absence of technical >> objections. >> >> >> >> I think that you are misunderstanding what I would consider to be the >> >> problem of AI PRs. It is not about the actual code and its quality. >> >> Many AI tools can produce better code than many of the people >> >> currently opening SymPy PRs. The problem with the AI PRs is that they >> >> are harder to review and are overloading us with spam. The problem >> >> also is that if people don't explain honestly how they have used AI >> >> then that in itself makes it harder to review the code because you >> >> have to pick apart the AI hallucinations from the human >> >> misunderstandings. >> >> >> >> The other problem is that if we really want AI PRs then we don't >> >> actually need new contributors to bring them. It would be far more >> >> efficient for those of us who would have reviewed the PR to make AI >> >> PRs directly without the other person getting in the way. >> >> >> >> Technically the main problem with the PR is just the fact that it is >> >> classic more code on top of code creating more space for bugs without >> >> actually delivering much value. Unfortunately this is exactly what AI >> >> makes easy: you ask it to do something and it just spits out more and >> >> more code. The code might seem to work but if we merge it into the >> >> codebase then it needs to be maintained and soon there will be bug >> >> reports saying that degree doesn't work in this or that corner case >> >> and then someone will have to review the bug reports and then someone >> >> else will have an AI spit out more code on top of code and so on. >> >> >> >> The PR may "fix" some issue but how much actual value are you getting? >> >> It doesn't actually make it safe to call degree on an expression >> >> because it still has a fallback case where it would effectively go >> >> into an infinite loop like degree((x - 1)**1000000 - (x + >> >> 1)**1000000). The proper fix would be to have a version of Poly that >> >> does not expand everything and that would be something very useful >> >> that could be used in lots of places for much more than just degree >> >> like it could also get the leading coefficient, support different >> >> domains, evaluate and so on. >> >> >> >> In any case all of the low quality PRs around now are seriously >> >> getting me down. I think for now I will stop reviewing PRs from anyone >> >> but a select list of people whose PRs don't annoy me (people who can >> >> consistently produce something that does not require many iterations >> >> unless it delivers significant actual value). This will mean that >> >> unless other people do a lot more PR reviewing most GSOC-related PRs >> >> are not going to get reviewed. >> >> >> >> -- >> >> Oscar >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups "sympy" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> >> To view this discussion visit >> https://groups.google.com/d/msgid/sympy/CAHVvXxTi4x5ZBAeUmWhLZsU%2B_ffYFCL7Y87HnKhRAjMd0XL3sQ%40mail.gmail.com >> . >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "sympy" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > To view this discussion visit >> https://groups.google.com/d/msgid/sympy/CAP7f1AjKhWt1yq4aP1rOHxBr-6ctdA7NCJ7eqCeqNSgNVPMGNA%40mail.gmail.com >> . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion visit >> https://groups.google.com/d/msgid/sympy/CAHVvXxRx49c8U07sH6-2foEWA04LdrSjT82nCmX0M8pkXLuCKg%40mail.gmail.com >> . >> > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sympy/742c0a05-b733-4ad3-9f85-ca36beb3917en%40googlegroups.com.
