[QoL/Misc] add stale issues/PRs workflow

[flx-sta]

What are the changes?

I've added a github action workflow that will run at At 01:30 AM, every day (cron 30 1 * * *) and check for issues and PR's that have been idle and add a message to inform authors about possible closing. If that message is ignored for another 5 days the issue/pr will be closed. (the numbers are subject to change. See Files changed tab)

Here is an example of this message:
flx-sta#1

Why am I doing these changes?

200+ issues and 100+ PRs is a lot to manage.
I personally think if an author cares about his issue/PR he will nudge devs/contributors about it when receiving this message. If not, RIP.

What did change?

github workflows were extended

Screenshots/Videos

flx-sta#1

How to test the changes?

You can test it on your fork:

1. activate the issues tab
2. create an issue on your fork
3. add the .github/workflows/stale.yml file to your main branch
4. Make sure to change the cron schedule to */5 * * * * to run it every 5 minutes
5. Make sure to change days-before-issue-stale to 0
6. Be patient...
7. after some time you should see the stale message on your issue

Checklist

• There is no overlap with another PR?
• The PR is self-contained and cannot be split into smaller PRs?
• Have I provided a clear explanation of the changes?
• Have I tested the changes (manually)?
  • Are all unit tests still passing? (npm run test)
• Are the changes visual?
  • Have I provided screenshots/videos of the changes?

[OrangeRed]

I personally think that auto closing PRs is bad so I would instead prefer you just add a stale tag or something along those lines and then a dev can close the PR if they don't think its worth keeping open.

[Icehawk78]

What is the intended "action" for a PR that has been ready for a while, but simply has not been responded to by the maintainers?

[flx-sta]

What is the intended "action" for a PR that has been ready for a while, but simply has not been responded to by the maintainers?

@Icehawk78 Well you can either nudge with a comment or usually there is changes on main thus you could just sync it with that one to refresh the timer

I personally think that auto closing PRs is bad so I would instead prefer you just add a stale tag or something along those lines and then a dev can close the PR if they don't think its worth keeping open.

@OrangeRed
https://github.com/marketplace/actions/close-stale-issues#days-before-close

You can disabled the closing feature and instead just put a tag/label on it, sure.
I want to hear some more opinions before changing any code

[j-diefenbach]

seems like a good idea to me, are you also planning to do the same for issues? I know some issues that have been solved and can be closed but haven't yet. Maybe a similar process but could have a much longer timer

[flx-sta]

seems like a good idea to me, are you also planning to do the same for issues? I know some issues that have been solved and can be closed but haven't yet. Maybe a similar process but could have a much longer timer

Both stale PR and issues support (almost) the same functionality. So yeah both can be configured the same or separately.

[flx-sta]

The (dev) team decided to not proceed with this approach