Maybe we can issue a warning before closing it to see if the contributor responds, if not, we can close the PR.
Best wishes, Cancai Cai > 2024年9月10日 21:50，Michael Mior <mm...@apache.org> 写道： > > I wanted to revisit this. So far we have a +0 from Julian and Francis and > a +1 from Ruben. Given there seems to be no strong opposition, I propose > that we move forward. I'll acknowledge that this doesn't really fix the > problem we have of PRs not getting reviewed, but I'm hoping that cleaning > up the list will make it easier to prioritize the remaining PRs. > > I initially proposed marking PRs as stale after 30 days (X) and closing > after 90 days (Y). That was before I compiled the list at the bottom of my > message. Based on what other projects have implemented, X=60 and Y=7 seems > to be the most common configuration. If there are no strong objections by > the end of the week, I'll try to get this in next week. > > Note that other than notifications to PR authors, this is completely > reversible since we could disable this in the future and reopen all PRs > that were closed or marked as stale. > > -- > Michael Mior > mm...@apache.org > > > On Thu, Aug 22, 2024 at 1:42 PM Michael Mior <mm...@apache.org> wrote: > >> Hi all, >> >> I know the better solution here is to have more people reviewing and >> merging PRs to keep momentum going. However, even when someone is engaged >> in trying to help merge a PR, sometimes the original author will disappear >> or changes become irrelevant over time. I think having a smaller number of >> open PRs can help keep things more manageable. The goal is that regardless >> of when the PR was opened, it should be kept open if there is still >> interest. But PRs which have been abandoned should be closed. >> >> I'm suggesting implementing (via GitHub Actions, e.g. >> https://github.com/actions/stale) a process that will automatically close >> PRs after some period of inactivity. This doesn't mean we lose any of the >> work. We can also have PRs automatically be reopened if there are any >> future comments. The idea would be that after X number of days, a comment >> is automatically posted and a label of "stale" is applied. Then after Y >> more days, the PR would be automatically closed. Any activity (more commits >> on the branch or comments) will remove the stale label and reset the clock. >> >> I'd propose implementing this with X=30 and Y=90. This gives four months >> for any activity to keep a PR alive. Again, if it is closed, no work is >> lost. But I think four months of no activity is a strong indicator that >> nothing is likely to move forward in the near future. I will note that if >> this policy were already in place, it would mean ~85% of our current open >> PRs would have been closed (if there was no intervention after the initial >> ping). >> >> Here's some configuration data from a few projects which have implemented >> this >> >> Apache Age, X=60, Y=14 >> Apache Airflow, X=45, Y=5 >> Apache Beam, X=60, Y=7 >> Apache ECharts, X=730,Y=7 >> Apache Iceberg, X=30, Y=7 >> Apache Kafka, X=90, Y=-1 (never automatically close) >> Apache Solr, X=60, Y=-1 >> Apache Spark, X=100,Y=0 >> Apache Superset, X=60, Y=7 >> >> -- >> Michael Mior >> mm...@apache.org >> >>
