Hi, TL;DR:
If you find an issue tagged as Stale or lifecycle/stale or generally inactive, be confident to close it as not planned. Close as not planned is a GitHub Issue feature[1] and here is an example[2]. The longer version: I started a discussion about the stale bot and stale issues/prs weeks ago[3]. Apart from suggestions in the thread, it's agreed that currently, committers omit Stale or lifecycle/stale labels when they triage an issue. After an offline discussion with @codelipenghui we agree that spending time on handling issues is better than writing more automation or rules. One thing to help us handle the backlog is close stale issues directly as not planned[1]. As committers can be confident close stale issues, we can significantly reduce the backlog. A good example is Apache SkyWalking who has less than 100 issues because they close stale issues frequently (total 4000+ issues vs. Pulsar total 5000+ issues, same order of magnitude). If we reach similar status, we don't have to worry about stale bot at all and even simply remove it - our committers should be able to handle such traffic. Don't worry if the issue is still valuable to continue or investigate. Since we ask issue creators to search before creating, anyone can bump a closed as not planned issue or reopen. If no one continues the thread, it's definitely valueless. Keep a large number of open issues while no one is actually interested in handling hurting the community instead of helping it. Close as not planned shows that the issue does get resolved, and that provides enough information to collaborate. Best, tison. [1] https://github.blog/changelog/2022-03-10-the-new-github-issues-march-10th-update/#%F0%9F%95%B5%F0%9F%8F%BD%E2%99%80%EF%B8%8F-issue-closed-reasons [2] https://github.com/apache/pulsar-site/issues/146 [3] https://lists.apache.org/thread/tv774jqohdpx8x0dymsskrd90xwwfvgp
