On Sun, 1 Feb 2026 at 14:17, Oscar Benjamin <[email protected]> wrote: > > On Sun, 1 Feb 2026 at 13:44, Jason Moore <[email protected]> wrote: > > > > > 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.
Thinking about this a bit I think that most of the time it is not really a clear binary state here. A lot of them are in an in-between sort of state where the PR is not good enough but the author does not know how to improve it and no reviewer is willing to coach it to success. A lot of the PRs being opened as we speak will enter this state. >From a process perspective it might seem like "reviewer's turn" because no one has reviewed it and told the author what they should do. Actually though, I (and probably others) have looked at the PR and just decided not to reply telling them what to do because it is just below some level where I effectively consider it still the "author's turn" to produce something better without needing a reviewer to tell them exactly what to do. (My decision now about reviewing PRs is just to increase this threshold to a level that few new contributors will reach.) I know that I could say something like "oh, by the way Python code needs to be properly indented and have valid syntax" and then with enough back and forth it could likely turn into a merged PR but I have judged that it would require unreasonable effort to do that. In this situation it usually does not make sense to just close the PR because: - Another reviewer might be willing to coach it. - The author could come back to it and improve the PR. The last point is important. In general the reason that we don't immediately close PRs that are not perfect is because at the time of activity a PR is generally a work in progress. This is why I think closing after two months is reasonable. In the current workflow there is no clear notification at a time when you can conclude that probably no one is going to do what would be needed for the PR to succeed. You can be notified when the PR is opened or after a push but it is always possible (quite likely in fact) that there will be a subsequent push soon after so even if it is not good enough now it might be later. Two months is enough time to wait for that though before concluding that the PR is just not being actively worked on by the author or reviewers. I also think it is better if a bot does the closing rather than a human. If you think that it is not nice that a bot does this, how do you think it would feel if a human explained the situation honestly: "Look this code is not good enough but based on various factors (very much including our perception of your personal capabilities) we don't think it is worth our time to help you improve it so we think it is better to give up on this one." Alternatively is it nicer just to leave the PR permanently open but ignored? I'm not sure it is. Also I think that having one month and two month notifications would actually result in more things being merged. A lot of maintainer PRs get lost in the noise of all the others and end up waiting for review before eventually being self-merged. The one month notification would remind people when those have been overlooked for review. The two month mark is probably a reasonable basis for saying "look I tried to wait for a review on this but no review is coming so I'm just going to merge it". -- 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/CAHVvXxQ8pD0G1w1GGYkPR88%2BeBm2aM9z6D5w7EBPW8cAufLoyQ%40mail.gmail.com.
