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,
