Sum up the ideas above: * Keep it as is @penghui * Extend the interval @dave * Change the message @eolivelli * Remove the message @zixuan
I may try to remove the stale bot at the beginning, but when I consider it more constructively, the goal here is that we'd like to nudge the ping-pong circle between the author and the reviewer. So I'd like to prototype a feature based on pulsarbot, simulate ASF INFRA's waiting-for-user, waiting-for-infra cycle to react to: /pulsarbot waiting-for-author /pulsarbot waiting-for-reviewer ... which labels the issue. The original stale logic can be integrated into waiting-for-reviewer, which is better than "you are stale/inactive". Then a reviewer can label it as waiting-for-author so that we learn the state and the stale bot will skip it. What do you think? Best, tison. Zixuan Liu <node...@gmail.com> 于2022年8月1日周一 11:42写道： > Hi tison, > > Good catch! I also noticed some issues with a stable label and a no > activity commit message. This is going to add a lot of useless information > to the issue. > > I don't recommend leaving a commit message. > > > For example, even if we close (and lock?) the issue or pull request after > a > certain interval, the stale bot helps on transforming issues state with a > clear rule (although a human action could be more friendly). > > We can use the bot to mark the issue or PR but don't leave a commit > message, and then it's up to the committer/PMC to decide whether to close > it or continue handling it. > > Thanks, > Zixuan > > Enrico Olivelli <eolive...@gmail.com> 于2022年7月31日周日 01:39写道： > > > Il Sab 30 Lug 2022, 17:53 tison <wander4...@gmail.com> ha scritto: > > > > > For example, even if we close (and lock?) the issue or pull request > > after a > > > certain interval, the stale bot helps on transforming issues state > with a > > > clear rule (although a human action could be more friendly). > > > > > > Instead, we leave a comment and add a label which information can be > > > filtered as the search query mentioned above. I'm curious if our > members > > > treat an issue with/without the stale label differently. If not, I > don't > > > see the value we gain from running workflows and potentially spamming > > > comments. > > > > > > > Totally agreed. > > It is very hard to follow the overwhelming flow of github pull requests. > > On one hand this is great because the project is very active. > > On the other hand it is very hard to take time to pay attention to > > everyone. > > > > The stale bot is useful only because it bumps up the pr by sending a > > notification and possibly you find it. > > > > > > I think that we should encourage people to talk about their PRs on the > dev@ > > list. > > We should add some message on the PR template to advise folks to > advertise > > their patches here. > > > > In the stale bot the comment should suggest to the author of the PR to > ask > > for review here on dev@. > > It will be less frustrating. > > Like: > > We are sorry if your patch has not make it yet. Please advertise about > your > > patch on dev@pulsar.apache.org > > > > > > Enrico > > > > > > > > > Best, > > > tison. > > > > > > > > > tison <wander4...@gmail.com> 于2022年7月30日周六 23:00写道： > > > > > > > Hi Dave, > > > > > > > > > The other aspect is it would be helpful if many Pulsar committers > > would > > > > spend effort every few weeks reviewing issues and PRs to engage the > > > > community. > > > > > > > > Agree. I'll try to help with reviewing issues and PRs as I handled > > > > backlogs for the Apache Curator project. > > > > > > > > The topic here is whether "the stale bot" helps or it creates > > > frustration, > > > > spamming comments, and consumes resources unnecessarily. We should > > always > > > > handle backlogs in some way, but may not with a stale bot. > > > > > > > > Best, > > > > tison. > > > > > > > > > > > > Dave Fisher <wave4d...@comcast.net> 于2022年7月30日周六 22:50写道： > > > > > > > >> Perhaps 30 days is too quick? 90 days might be better. > > > >> > > > >> Also in cases like this one it’s likely that a PR would get more > > > >> discussion. > > > >> > > > >> The other aspect is it would be helpful if many Pulsar committers > > would > > > >> spend effort every few weeks reviewing issues and PRs to engage the > > > >> community. > > > >> > > > >> All the best, > > > >> Dave > > > >> > > > >> Sent from my iPhone > > > >> > > > >> > On Jul 30, 2022, at 9:59 AM, tison <wander4...@gmail.com> wrote: > > > >> > > > > >> > Here is a fresh bad case of stale impressions: > > > >> > > > https://github.com/apache/pulsar/issues/15981#issuecomment-1200152441 > > > >> > > > > >> > Best, > > > >> > tison. > > > >> > > > > >> > > > > >> > tison <wander4...@gmail.com> 于2022年7月30日周六 13:20写道： > > > >> > > > > >> >> Hi Penghui, > > > >> >> > > > >> >> Thanks for your feedback! Comments inline: > > > >> >> > > > >> >>> If we removed the stale label, how can we know which issues/PRs > > are > > > >> >> active? > > > >> >> > > > >> >> GitHub Search supports filter by updated time: > > > >> >> > > > >> >> * > > > >> >> > > > >> > > > > > > https://github.com/apache/pulsar/issues?q=is%3Aissue+is%3Aopen+updated%3A%3E2022-07-01 > > > >> >> updated in this month > > > >> >> * > > > >> >> > > > >> > > > > > > https://github.com/apache/pulsar/issues?q=is%3Aissue+is%3Aopen+created%3A%3E2022-07-01 > > > >> >> recently created > > > >> >> > > > >> >> You can see more information at: > > > >> >> > > > >> >> * Understanding the search syntax > > > >> >> > > > >> > > > > > > https://docs.github.com/en/search-github/getting-started-with-searching-on-github/understanding-the-search-syntax > > > >> >> * Searching issues and pull requests > > > >> >> > > > >> > > > > > > https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests > > > >> >> > > > >> >>> IMO, it is just a tool that can help us to get a list of all > > active > > > >> PRs > > > >> >> and issues. > > > >> >> > > > >> >> Yes. We can achieve this goal as mentioned above in this mail, > > while > > > a > > > >> box > > > >> >> is unfriendly for interaction and wastes CI resources. > > > >> >> > > > >> >> Besides, we have even two labels (Stale, lifecycle/stale). > Project > > > >> entropy > > > >> >> increases if we treat broken windows as not a big deal. > > > >> >> > > > >> >> Best, > > > >> >> tison. > > > >> >> > > > >> >> > > > >> >> PengHui Li <codelipeng...@gmail.com> 于2022年7月30日周六 09:38写道： > > > >> >> > > > >> >>> Hi tison, > > > >> >>> > > > >> >>> Thanks for bringing up this discussion. > > > >> >>> > > > >> >>> The stale label can help contributors to filter out inactive PRs > > and > > > >> >>> issues(no active comments for more than a month) > > > >> >>> So that the contributors can focus on the active issues and PRs. > > > >> >>> > > > >> >>> I think we should start to consider closing the issues and PRs > > with > > > >> the > > > >> >>> stale label manually. > > > >> >>> If we removed the stale label, how can we know which issues/PRs > > are > > > >> >>> active? > > > >> >>> > > > >> >>>> From my experience, any process won't work. The only way is to > > > >> inspire > > > >> >>> more reviewers act on PRs > > > >> >>> > > > >> >>> Totally agree, the purpose of the stale label is to help > > > contributors > > > >> >>> participate in the review work of active PRs. > > > >> >>> IMO, it is just a tool that can help us to get a list of all > > active > > > >> PRs > > > >> >>> and issues. > > > >> >>> > > > >> >>> Best, > > > >> >>> Penghui > > > >> >>>> On Jul 29, 2022, 23:09 +0800, tison <wander4...@gmail.com>, > > wrote: > > > >> >>>>> Hi, > > > >> >>>>> > > > >> >>>>> Previous discussion: > > > >> >>>>> > > > >> >>>>> * [DISCUSS] How to handle stale PRs [1] > > > >> >>>>> * [DISCUSS] Add icebox label for issues and PRs that have been > > > >> inactive > > > >> >>> for > > > >> >>>> more than 4 weeks [2] > > > >> >>>> > > > >> >>>> I notice that over 80% (1527/1891 ATM) issues are marked as > > stable > > > >> but > > > >> >>>> nothing happens later. In an offline discussion with > > > @codelipenghui I > > > >> >>>> learned that we ever wanted to focus on non-stable issues to > > handle > > > >> more > > > >> >>>> inputs but it seems now we don't achieve this goal. > > > >> >>>> > > > >> >>>> Refrain my comment in [1] that: > > > >> >>>> > > > >> >>>>> From my experience, any process won't work. The only way is to > > > >> inspire > > > >> >>>> more > > > >> >>>> reviewers act on PRs. > > > >> >>>>> Instead of talking about how to do it, reviewing one PR now > can > > > help > > > >> >>> the > > > >> >>>> case. > > > >> >>>>> Also, it's reasonable to close inactive PR if there is a > > > successor. > > > >> >>> But do > > > >> >>>> not let a bot do it, which will create many corner (bad) cases. > > > >> >>>> > > > >> >>>> I observe that those stale comments like a spammer in some > > > >> thread[3][4] > > > >> >>> and > > > >> >>>> IIRC some audiences reacted with negative emoji to those > > comments. > > > >> >>>> > > > >> >>>> Thus, I'd like to know whether you gain some value from the > stale > > > >> bot. > > > >> >>>> > > > >> >>>> To me, it seems a potential spammer, frustration maker, and > > > resource > > > >> >>>> consumer (we run a workflow to label them, and even tried to > > > optimize > > > >> >>> its > > > >> >>>> resource occupation[5]). > > > >> >>>> > > > >> >>>> Best, > > > >> >>>> tison. > > > >> >>>> > > > >> >>>> [1] > > > https://lists.apache.org/thread/xxmxwnhnlcptv8wr73200qvprnvrfjt1 > > > >> >>>> [2] > > > https://lists.apache.org/thread/0lm9tyjqtgtvwkfowkfhbxy24nh8tyxh > > > >> >>>> [3] https://github.com/apache/pulsar/issues/15100 > > > >> >>>> [4] https://github.com/apache/pulsar/issues/13864 > > > >> >>>> [5] https://github.com/apache/pulsar/pull/14466 > > > >> >>> > > > >> >> > > > >> > > > >> > > > > > >
