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
