I think this is a great idea. If we don’t want the auto-close functionality, we can set it to -1
I realize this isn’t a vote, but I’m +1 on this -David On Fri, Jun 2, 2023 at 15:34 Colin McCabe <cmcc...@apache.org> wrote: > That should read "30 days without activity" > > (I am assuming we have the ability to determine when a PR was last updated > on GH) > > best, > Colin > > On Fri, Jun 2, 2023, at 12:32, Colin McCabe wrote: > > Hi all, > > > > Looking at GitHub, I have a bunch of Kafka PRs of my own that I've > > allowed to become stale, and I guess are pushing up these numbers! > > Overall I support the goal of putting a time limit on PRs, just so that > > we can focus our review bandwidth. > > > > It may be best to start with a simple approach where we mark PRs as > > stale after 30 days and email the submitter at that time. And then > > delete after 60 days. (Of course the exact time periods might be > > something gother than 30/60 but this is just an initial suggestion) > > > > best, > > Colin > > > > > > On Fri, Jun 2, 2023, at 00:37, Josep Prat wrote: > >> Hi all, > >> > >> I want to say that in my experience, I always felt better as a > contributor > >> when a person told me something than when a bot did. That being said, > I'm > >> not against bots, and I think they might be a great solution once we > have a > >> manageable number of open PRs. > >> > >> Another great question that adding a bot poses is types of staleness > >> detection. How do we distinguish between staleness from the author's > side > >> or from the lack of reviewers/maintainers' side? That's why I started > with > >> a human approach to be able to distinguish between these 2 cases. Both > >> situations should have different messages and actually different > intended > >> receivers. In case of staleness because of author inactivity, the > message > >> should encourage the author to update the PR with the requested changes > or > >> resolve the conflicts. But In many cases, PRs are stale because of lack > of > >> reviewers. This would need a different message, targeting maintainers. > >> > >> Ideally (with bot or not) I believe the process should be as follows: > >> - Check PRs that are stale. > >> - See if they have labels, if not add proper labels (connect, core, > >> clients...) > >> - PR has merge conflicts > >> -- Merge conflicts exist and target files that still exist, ping the > author > >> asking for conflict resolution and add some additional label like > `stale`. > >> -- Merge conflicts exist and target files that do not exist anymore, let > >> the author know that this PR is obsolete, label the PR as 'obsolete' and > >> close the PR. > >> - PR is mergeable, check whose action is needed (author or reviewers) > >> -- Author: let the author know that there are pending comments to > address. > >> Add some additional label, maybe `stale` again > >> -- Reviewer: ping some reviewers that have experience or lately touched > >> this piece of the codebase, add a label `reviewer needed` or something > >> similar > >> - PRs that have `stale` label after X days, will be closed. > >> > >> Regarding the comments about only committers and collaborators being > able > >> to label PRs, this is true, not everyone can do this. However, this > could > >> be a great opportunity for the newly appointed contributors to exercise > >> their new permissions :) > >> > >> Let me know if it makes sense to you all. > >> > >> Best, > -- David Arthur
