Most of those things are talking about stale bots for closing issues rather than pull requests: https://drewdevault.com/2021/10/26/stalebot.html
On Sun, 1 Feb 2026 at 13:49, Jason Moore <[email protected]> wrote: > > In fact, these are the list of the first hits on my search of "stalebot": > > - Most stale bots are anti-user and anti-contributor, but they don't have ... > - No Stale Bots > - GitHub - actions/stale: Marks issues and pull requests that have > - GitHub stale bot considered harmful : r/programming - Reddit > - Don't use stale bots > - Understanding the Helpfulness of Stale Bot for Pull-based Development > - Github Stale Bots: A False Economy - blog.benwinding > > So, it seems that using such a practice may or may not be a positive thing. > > Jason > moorepants.info > +01 530-601-9791 > > > On Sun, Feb 1, 2026 at 2:43 PM Jason Moore <[email protected]> wrote: >> >> This reminds me that there is more nuance than I originally wrote. >> >> Github has 4 PR states and as far as I can gather from the last 15 years of >> community practice this is how we've treated them: >> >> - Open (green): request for review and author desires to have it merged >> - Closed (red): ether a core dev closed it to signal it will not be merged >> or the submitter self-closes it to signal they will not pursue it further >> - Merged (purple): a core dev merged the PR into master >> - Draft (grey): pull request shared so others can view the work or >> collaborate but not ready for review and/or merging (we used to use "WIP" in >> the title, as this a relatively new GH feature) >> >> I do think these have been distinct meanings and arose through many past >> conversations and practices. At one point in the past, we even used labels >> to designate "author's turn" or "reviewer's turn" to indicate who's >> responsibility it is to take the next steps in moving a PR forward. The >> green open PRs stall because we are waiting on one of these turns. This is >> not the first time we've discussed the fact that SymPy has a large number of >> open PRs and whether we should close them for other reasons than above. We >> can introduce closing a PR due to inactivity, but I do not see why doing >> this anything other than causing you to have to click an extra tab to see >> these PRs. I have always thought the stalebot tool in some repositories to >> be obnoxious and annoying. Some times it takes a long time to get a PR >> merged. I just searched "stalebot" and this was the first article that >> popped up: >> https://jacobtomlinson.dev/posts/2024/most-stale-bots-are-anti-user-and-anti-contributor-but-they-dont-have-to-be/. >> I agree with it being a turn-off to new contributors (and also just >> annoying to standing contributors). The second part of the article gives >> some tips not unlike our turns method we used in the past. >> >> I think it is also ok that we don't get to every PR or issue and that >> accepting that issues/PRs are an unwinnable Whac-A-Mole game. We've been >> staring at a huge list of issues and PRs for decades now. I'm not sure what >> closing a bunch for inactivity will change. >> >> Jason >> moorepants.info >> +01 530-601-9791 >> >> >> On Sun, Feb 1, 2026 at 1:53 PM Oscar Benjamin <[email protected]> >> wrote: >>> >>> On Sun, 1 Feb 2026 at 06:53, Jason Moore <[email protected]> wrote: >>> > >>> > In the past we've used the "closed" designation on a PR to mean: 1) this >>> > is merged into master and 2) this will definitely not be merged into >>> > master. If we close PRs based on inactivity time, then we have PRs >>> > labeled "closed" which are neither 1 or 2, they still have the state >>> > "could be or might be merged to master or might be rejected" but now >>> > we've labeled them with "closed" which would seemingly imply 1 or 2. So >>> > it seems to me if you close based on inactivity time, then the meaning of >>> > "open" or "closed" PR no longer has distinct meanings. >>> >>> I think that currently open vs closed does not have distinct meanings. >>> Most PRs in the open state should really be in the closed state. It is >>> just that no one has closed them. Even if the PR is closed that is >>> usually because the author decided to close the PR which does not >>> necessarily reflect a decision from the project that the PR was the >>> wrong approach. >>> >>> If we close based on inactivity then an open PR has an objective >>> meaning that there is some recent activity. A PR that is closed would >>> have a message saying that it was closed because of inactivity and >>> then it is clear that that is not necessarily a rejection of what is >>> in the PR. >>> >>> Most of the time the reason a PR has not been merged is not really to >>> do with making a decision about what the PR is trying to do but just >>> because the author hasn't done it properly and at the time when anyone >>> looked at it it was not clear if the author was going to fix the >>> problems or not. There may or may not be a comment from a reviewer >>> explaining what the problem with the PR is. >>> >>> -- >>> 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/CAHVvXxSphOcZ%2BDYen_Z27FtUwcSVmO9iR2S55B%3D%2BYL%2BjNmX_Lg%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/CAP7f1AiX-Am_uWixUtCHDm6ZFq-7zcuwO0E9JwLSyXBSpq1XMg%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/CAHVvXxSkRL-i%2Bf6k8tTaWmG1ohx8kpeDjMngdgpFupMe5M7ivg%40mail.gmail.com.
