+1 I like 150 days for marking stale, then 30 before closure also. This should help clean up obsolete tickets.
However, IMO the incoming bugs being more than we can address is normal for any healthy project. In fact, I think if we see closed bugs > incoming bugs then it could be a sign of usage decline or users not knowing how to get their issues addressed. I care much more about every incoming bug getting a good triage. We have an "awaiting triage" label for this, with 479 open issues. Only perhaps 25% of them were updated in the last 180 days. So that system is maybe not working so well. Kenn On Tue, May 27, 2025 at 11:00 AM XQ Hu via dev <dev@beam.apache.org> wrote: > Sounds good. Just updated the PR to use 150 days + 30 days. > > On Tue, May 27, 2025 at 10:57 AM Danny McCormick via dev < > dev@beam.apache.org> wrote: > >> +1 to the proposal. >> >> > +1 generally, this seems to be the approach many other projects follow, >> so it seems reasonable. One note - the 7 day deadline feels a little too >> strict. I'd propose to change this to 150 days + 30 days, the total would >> be the same, but people can have more time to react. >> >> This seems reasonable to me, though I will note that reopening an issue >> is always an option. But I probably still like 30 days. >> >> Thanks, >> Danny >> >> On Tue, May 27, 2025 at 10:50 AM Jan Lukavský <je...@seznam.cz> wrote: >> >>> Hi XQ, >>> >>> +1 generally, this seems to be the approach many other projects follow, >>> so it seems reasonable. One note - the 7 day deadline feels a little too >>> strict. I'd propose to change this to 150 days + 30 days, the total would >>> be the same, but people can have more time to react. >>> >>> Thanks for this proposal, >>> >>> Jan >>> On 5/27/25 16:36, XQ Hu via dev wrote: >>> >>> Hi, Beam developers, >>> >>> I was reviewing the Apache Beam repository statistics on OSS Insight ( >>> https://ossinsight.io/analyze/apache/beam#issues) and wanted to discuss >>> our current issue management strategy (the previous discussion in 2020 is >>> https://lists.apache.org/thread/41yvgw5ymvkkzt3ws1160j58t9hbf2mt). >>> >>> According to the "Issues" overview section on the page, we currently >>> have approximately 7,230 total issues. While it's positive to note that in >>> the last 28 days, more issues were closed (74) than opened (56) , the >>> overall size of the backlog remains substantial. A large backlog can make >>> it challenging to effectively triage, prioritize, and address the most >>> relevant items. >>> >>> I am proposing this PR (https://github.com/apache/beam/pull/35052) and >>> suggest the following: >>> >>> >>> - Initial Staling: Issues that have seen no updates or meaningful >>> activity for 173 days will be automatically labeled as stale . >>> - Notification: When an issue is marked stale, an automated comment >>> will be posted: "This issue has been marked as stale due to 173 days of >>> inactivity. It will be closed in 1 week if no further activity occurs. If >>> you think that’s incorrect or this issue still needs to be addressed, >>> please simply write any comment. If closed, you can reopen the issue at >>> any >>> time. Thank you for your contributions." . >>> - Auto-Closure: If, after an additional 7 days, there is still no >>> activity on the issue, it will be automatically closed . A comment will >>> be >>> added: "This issue has been closed due to lack of activity. If you think >>> that is incorrect, you can reopen the issue at any time." . >>> >>> This means an issue would be closed after a total of 180 days of >>> inactivity. >>> >>> Rationale: >>> >>> - Focus & Efficiency: This process, now backed by an implemented >>> workflow, will help us systematically manage the backlog, allowing the >>> community to focus on active and pressing issues. >>> - Clarity & Consistency: Adopting these specific parameters (173 >>> days to stale, 7 days to close) provides a clear and consistent >>> expectation >>> for issue lifecycle management. >>> - Community Input: The 7-day warning period after an issue is marked >>> stale provides a window for community members to intervene if an issue is >>> still relevant or requires further attention. >>> >>> This approach seems like a good balance, giving ample time (nearly 6 >>> months) before an issue is flagged, and then a clear warning period before >>> closure. >>> >>> Let me know if you have any concerns or other suggestions. Thanks. >>> >>> Best, >>> XQ >>> >>>
