Thanks a lot for the discussions. I just merged https://github.com/apache/beam/pull/35052 with 150 days (stale) + 30 days (warning).
On Tue, May 27, 2025 at 12:04 PM Kenneth Knowles <k...@apache.org> wrote: > +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 >>>> >>>>
