On Sat, 31 Jan 2026 at 16:38, Peter Stahlecker <[email protected]> wrote: > > 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?
Some are good and some are not. All you can really say is that they have been forgotten about and there are just too many for anyone to go back through. > Would it make sense to just close untouched PRs that are beyond a certain age? Yes it would and I think that this is what sympy should do now. We should have some automation that closes a PR after 2 months of no activity. The notification of it being closed can be a trigger that a reviewer can quickly check if it is worth not closing or it can remind the contributor that they should actually finish it or something. There are a few reasons that a PR can end up in that state. Basically when a new PR is opened or someone pushes new commits or comments etc I get a notification by email. I regularly swipe through the messages in that mailbox which shows me most activity happening in the repo as it happens. At the time of someone opening/updating a PR I may choose to look at it and if I do then I can decide between these options: 1. Merge the PR. 2. Make a comment suggesting changes. 3. Make a comment suggesting to close the PR. 4. Close it immediately (unusual but much more common recently). 5. Ignore the PR (perhaps just until further changes). A lot of PRs end up in a space where you can choose between options 2, 3 and 5 depending on how much effort you as a reviewer want to put in. How much work it would be to suggest changes that improve the PR varies a lot depending on who is submitting the PR and what they are trying to change. Often then I will just ignore the PR based on its contents and who the author is. Of course I am not the only person reviewing PRs and anyone is free to ignore a PR. What that means is that if I do choose to ignore a PR I don't actually know that that means that no one else is going to review the PR although often that is the case. To some extent there is a notion that there are certain people who would review PRs for some particular parts of the codebase but there are also quite large parts of the codebase that no one really actively maintains so a PR for those can easily be ignored. Another point that is probably worth mentioning here is that if you are the first person to comment on a PR then that is often interpreted like you are taking responsibility for that PR. Then the author will assume that you are going to interact with them repeatedly rather than just commenting once and ignoring it afterwards. Likewise other potential reviewers may be discouraged from reviewing the PR by the fact that someone else seems to be already doing that. I think that automatically closing PRs after a certain time is realistically the only good way of handling this and is just a necessary admission of our resource limitations. There are a lot of PRs where I know that it is not good enough to be merged but I don't think that the effort (on our part) of helping the author improve the PR is worth it. If I was saying my thoughts out loud then it would be things like: - This person is not capable of making this PR correct. - It would be too much effort to explain to them what is needed. The difference with the AI PRs now is that probably anyone can do anything with enough prompting but PR review is now like prompting a really broken AI (worse than using an actual AI directly). The fact that people are using AI (for anything, not just writing the code) increases the work involved from my perspective to do anything other than just ignore the PR. Another thing that happens particularly now with lots of new contributors making mostly trivial PRs is that I would generally be quite strict about making sure that someone's first or second PR must be exactly correct and follow all standards. In the past what that would mean is that if you give clear and detailed feedback to someone's first PR then their second PR will not have any of the issues that were discussed in the previous one. Now though with AI PRs each PR comes from a different AI context window. Everything you said in the previous PR like "use X not Y" will have to be said again because the AI forgot all of your previous feedback. A human actually thinking about and typing the code would have remembered that feedback when typing it but a human using an AI and not closely reviewing its output will just produce the same wrong AI code again and again. Unfortunately a lot of new sympy contributors seem to think that it is okay to expect that all the reviewing is done by someone else and that means that they are just not experienced enough to be able to use AI in any reasonable way. I watched a talk from someone at Google who was something like "director of AI infrastructure" and was basically overseeing how Google developers use AI tools for programming. He literally said that it meant that junior people were opening PRs in half the time but PR reviews were taking twice as long and then ruminated about how to manage the increased burden for senior people doing the reviewing. His suggestions for managing that burden were reasonable things to do in a company with employees, teams, line managers, and so on. None of his ideas were remotely useful for an open source project where the critical resource is always maintainer time. I think that we need to question whether the open-to-anyone model of open source collaboration is actually viable any more. In particular for SymPy I think that GSOC is not worth it any more because it means all of these low quality PRs now (not just the AI ones). -- 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/CAHVvXxSEY38qdRSHO4ocQPLWDZstngU2%3DwEk1SQPPRMtOemaqg%40mail.gmail.com.
