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,
