As a minor contributor, I strongly agree with the idea that PRs without activity for some period of time should be automatically closed. I am not sure the core maintainers and reviewers need to be notified. The originator of the PR should be notified with a message explaining that it was closed because of inactivity over the last XX period of time. They should be encouraged to review the PR carefully and decide if they have the time and interest in adjusting the code so that it meets all requirements for merging and address any concerns raised in the PR before it was closed. If so, they should open a new pull request with code updated to pass all tests when built with the current development branch and refer to the old PR in case reviewers want to look at the history.
I would be in favor of the period of inactivity being in the range of 6 months to a year. This would potentially close both pull requests I currently have open (https://github.com/sympy/sympy/pull/28258 and https://github.com/sympy/sympy/pull/24574). This seems reasonable, because although I would be interested in pursuing both of them, the reality is that my primary job is as a Chemistry Professor/Computational Quantum Chemist and I am unlikely to have much time for work on either of these until at least the end of the current semester. I do not object to opening a new PR or reopening the old one when I get back to being able to consider the code. AI generated slop should definitely be closed when noticed. My experience as an instructor is that people will only do what you want if you enforce the expectations. Jonathan On Saturday, January 31, 2026 at 12:00:42 PM UTC-6 Oscar wrote: > 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/daa114c9-89f3-45ef-9a39-202601e1d3c7n%40googlegroups.com.
