I am +1 on the general idea. Looking at other projects a two step process with the PRs being marked stale first (with a comment to ping participants) and only being closed after a second period of time.
I also agree with Rok that it would be nice to do /something/ with the issue backlog. There are a lot of valid issues but also a bunch of outdated/superseded ones that could be closed. On Fri, Mar 31, 2023 at 9:59 PM Rok Mihevc <rok.mih...@gmail.com> wrote: > I agree with Joris' and David's points here and would prefer some form of > pinging. > > Also at 120 open PRs we could realistically close out stale ones manually. > Meanwhile we have 3.2k open issues where we might want to get creative. > > Rok > > On Fri, Mar 31, 2023 at 9:17 PM Antoine Pitrou <anto...@python.org> wrote: > > > > > I have the same opinion as Joris. We shouldn't auto-close PRs simply > > because they have not been recently updated. For a casual contributor it > > can be extremely frustrating and demotivating to be dealt such a > > treatment, especially if you've already found it difficult to attract > > the attention of reviewers. > > > > I also agree with Weston that some automated ping based on the PR status > > could be more useful (and less hostile to contributors). > > > > Regards > > > > Antoine. > > > > > > Le 31/03/2023 à 18:54, Weston Pace a écrit : > > > I just now caught up to the recent wave of closed PRs in my > notifications > > > so maybe I see where some of this discussion is coming from :) > > > > > > I agree with everything David said and will change my stance from > neutral > > > to -0.5. My main problem is that I see no advantage to closing these > > PRs. > > > > > > On Fri, Mar 31, 2023 at 9:51 AM David Li <lidav...@apache.org> wrote: > > > > > >> I think I'm -0.5 overall. I do think it is worthwhile giving a "final > > >> chance" ping to very stale PRs as has been suggested, and pinging > > reviewers > > >> for PRs that have been sitting around. > > >> > > >> Automatically closing PRs purely based on time (since last update) is > > >> quite unfriendly. If the problem is reviewer/committer availability, > > this > > >> is mostly just sweeping it under the rug. (Especially for subprojects > or > > >> areas of the project where there are just not many active reviewers; > > both > > >> Parquet-C++ and Java are facing this IMO.) Plus, it is not necessarily > > >> clear what the etiquette is around pinging reviewers. I can understand > > if a > > >> contributor does not necessarily want to bother reviewers even if they > > >> aren't getting immediate attention, hence having a bot do it may help. > > And > > >> we have only just started to roll out relevant changes like the > > 'awaiting > > >> review' label and use of CODEOWNERS to assign reviewers. > > >> > > >> I'm also concerned that there was an out-of-the-blue mass closure of > PRs > > >> recently that didn't appear to even use the 30 day criteria, and which > > led > > >> to contributor questions/confusion. (Not to mention, arguably > > exacerbating > > >> the inbox problem for many reviewers.) > > >> > > >> On Fri, Mar 31, 2023, at 12:35, Gang Wu wrote: > > >>> From a contributor perspective, it would be great if a bot could > > detect a > > >>> PR is waiting > > >>> for review for a certain period of time and then automatically notify > > >>> reviewers if possible. > > >>> > > >>> > > >>> > > >>> On Sat, Apr 1, 2023 at 12:21 AM Joris Van den Bossche < > > >>> jorisvandenboss...@gmail.com> wrote: > > >>> > > >>>> On Fri, 31 Mar 2023 at 17:38, Alessandro Molina > > >>>> <alessan...@voltrondata.com.invalid> wrote: > > >>>>> > > >>>>> .. > > >>>>> My question probably would be... If a PR was sitting ignored for 30 > > >> days > > >>>>> without anyone from the community feeling the need to review and > > >> merge it > > >>>>> and without its primary author feeling the need to push for getting > > it > > >>>>> merged. Isn't that a signal that both parts consider that PR not > > >>>> important? > > >>>> > > >>>> I personally don't think that is necessarily the case, no. It might > > >>>> often be, but certainly not always. This is an open source > community, > > >>>> including volunteer contributors. I think it's very normal that PRs > > >>>> can sometimes take a longer time to get updated. Also, from my side > as > > >>>> a reviewer. There are more PRs (that interest me) than I personally > > >>>> have the capacity to review, so the fact that I didn't respond to a > PR > > >>>> is not necessarily a signal that I think it's not a relevant PR for > > >>>> the project. > > >>>> > > >>>> And to be clear, this is for sure not an ideal situation. A too > > >>>> limited maintainers' reviewing capacity and slow response time is a > > >>>> problem. Having such stale PRs just sit there is a problem, both for > > >>>> the project as giving a bad contributor experience (I think stale > PRs > > >>>> are often due to lack of review). But just closing them IMO isn't > > >>>> necessarily the best solution to that problem. > > >>>> > > >>>> Sometimes closing a PR might give a better contributor experience > than > > >>>> letting the author wait in vain on reviews for years (if the reason > is > > >>>> that there is no real interest in the PR), but I think such a > decision > > >>>> about a contribution not being worth it should ideally still be a > > >>>> human decision. > > >>>> > > >> > > > > > >
