I second Francis Chuang sentiment. I have several PR that I have not abandoned but no will review. I also have had several bugs closed that are still bugs. But having a long list of PR that never gets reviewed and bugs that no one is fixing, or reviewing the fixes is not productive.
On Thu, Aug 22, 2024 at 5:34 PM Michael Mior <michael.m...@gmail.com> wrote: > FWIW, I think we can resolve the languishing PR issue by adjusting the > values of X and Y if they feel too small. I think there exists some > timeframe after which we could all reasonably agree the creator of the pull > request has abandoned it. Obviously we don't want this to happen, but if a > PR isn't touched for a long enough period of time, the odds of it being > merged approach zero. > > On Thu, Aug 22, 2024, 17:59 Francis Chuang <francischu...@apache.org> > wrote: > > > I am also +0 on this one. Having a PR closed without any reviews can be > > discouraging for contributors, but at the same time, a PR requires more > > changes to merge as it languishes. > > > > On 23/08/2024 5:11 am, Julian Hyde wrote: > > > +0 > > > > > > I haven’t thought about the details, but it might improve our situation > > regarding pull requests. It’s a small reversible step, so I would support > > trying it. If it doesn’t help, we can change policy back again. > > > > > > Julian > > > > > > > > >> On Aug 22, 2024, at 10:59 AM, Ruben Q L <rube...@gmail.com> wrote: > > >> > > >> Thanks for opening the discussion, Michael. > > >> +1 on the idea. > > >> > > >> > > >> > > >> On Thu, Aug 22, 2024 at 6:43 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 > > >>> > > > > > > > >
