New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
meta: merge stalebot and update timings/messages #52712
base: main
Are you sure you want to change the base?
Conversation
Review requested:
|
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
I'm have to refresh my memory in terms of how the endDate helpd us meet our requirements. I think it was to meet what we had agreed in terms of handling what to consider stale. I think https://github.com/nodejs/node/blob/main/doc/contributing/feature-request-management.md will need an update. |
We should also be careful about the impact. We don't want everyone to suddenly have 500 new notifications. |
+1 to what @targos said, I was very careful to avoid that when I introduced it in the first place. |
Yes, that is a lot off issues :-/, WDYT should be done? |
That in part is why I added the end date. If I remember correctly I very carefully moved that a bit at a time so that we would not get a flood of notifications. |
Still, if we look at issues older than a year, it's a large portion of issues, and no matter the end date, floods may still occur. |
After looking at the stalebot docs, there is a parameter https://github.com/actions/stale?tab=readme-ov-file#start-date, so we could only apply this change to newer issues, to prevent the flood of notifications |
Also, in v9.0.0, the stale API now uses the Actions Cache, which will decrease the time it takes to run and the amount of API operations it performs. Based on the issue cache from the help repo's first run of the new stalebot, I estimate that ~209 to ~409 API operations will be spared. |
This PR will consolidate the
feature-request
and pull request stalebots into a unified workflow that targets all issues and all pull requests.Focusing solely on
feature-request
issues seems unnecessary, as other issues can also become stale.Instead of relying on @mhdawson's fork, which has been great, this PR will update the stale-bot to the latest version (v9.0.0).
However, there's a trade-off. Without the fork, the stalebot loses the
endDate
controlling environment variable. To address this, I've set the stale timeout to a middle ground between theendDate
and the stale timeout (8 months).Previously, the check was for issues older than a year with no updates in the past 6 months. Now, it will check for issues without any updates in 8 months. The middle ground would technically be 9 months, but I think 8 months strikes a good balance in this case.