Add stale GHA

[henningkayser]

Enables a stale action that labels issues and PRs as stale after 45 days, and closes issues after another 45 days. The action also takes care about warning the author appropriately, and it ignores a set of persistent labels. The intention of this is to really only keep issues open that are persistent explicitly (there is a new label for that), or that belong to a roadmap, milestone, etc.. All other issues should require at least some activity within the 3 months of time it would take for this GHA to close them.

Fixes #1490

[codecov]

Codecov Report

Patch coverage: 16.67% and no project coverage change.

Comparison is base (a27bd6f) 50.91% compared to head (ba1a271) 50.90%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2022      +/-   ##
==========================================
- Coverage   50.91%   50.90%   -0.00%     
==========================================
  Files         374      374              
  Lines       31362    31360       -2     
==========================================
- Hits        15964    15961       -3     
- Misses      15398    15399       +1     

Impacted Files	Coverage Δ
...rajectory_processing/src/ruckig_traj_smoothing.cpp	60.72% <16.67%> (+1.12%)	⬆️

... and 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[v4hn]

I still think this is superficial make-up and the only thing it does is add bloat where maintainer actions are required.
An issue list (even when the issues age) is a valuable resource of user input, not a junkyard that needs automatic discarding. In an ideal world all items in it warrant a manually added "can't reproduce/not enough information/won't fix" label before they are closed without a merged patch.

I guess you weakened the conditions enough to avoid further complains.

[AndyZe]

I thought discussions were supposed to go in the Discussions tab that was the cool new thing a couple months ago ;)

This type of shuffling of deck chairs amuses me. I hope no valuable old issues get lost because of it.

[henningkayser]

Same response as here #1490 (comment).

I still think this is superficial make-up

yes

and the only thing it does is add bloat where maintainer actions are required

it automates superficial maintainer actions

An issue list (even when the issues age) is a valuable resource of user input, not a junkyard

it's both

that needs automatic discarding

it doesn't, but it helps

In an ideal world

...

all items in it warrant a manually added "can't reproduce/not enough information/won't fix" label before they are closed without a merged patch.

We do have that and use it frequently

I guess you weakened the conditions enough to avoid further complains.

I hope so. My concern is really not about rejecting valuable issues. It's about requiring people to think about the content and value of their issue first before posting it in the first place. There is a huge amount of content that is along the lines of "we could...", "it would be nice..." that no one ever responds to because it's apparently not important at all. If only all maintainers would post issues of whatever wishes or concerns they have about the code base, the list would be endless and it would still be just as useless. Let's focus on actual problems and action items that are important enough to discuss them.

I thought discussions were supposed to go in the Discussions tab that was the cool new thing a couple months ago ;)

GitHub discussions are obviously something different than issues but it's hard to argue that issues are not meant for discussions.

btw, if anyone thinks that their issue is important enough to stay up forever, they can use the persistent label