Add stale issue and label actions workflows

[thompson-shaun]

This PR adds in a couple of GitHub Actions to support common triage/support activities and help ensure stale issues are dealt with in a timely manner.

Label actions

Use label actions to automate responses, @ authors, and auto-label for some common use cases. Most new labels would fall under the auto/* group and apply status/* labels as appropriate.

Stale issues

Automatically nudge contributors if issues or pull requests have gone stale after a set number of days and close after a configured number of days post-nudge. As initially configured, the first prompt would occur after 14 days, with closure 7 days after the prompt for a total time of 21 days before closure.

[crazy-max]

I think this would only matter when transferring issues not part of the org. For issues within the org we can use the "Transfer issue" functionality: https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository

[thompson-shaun]

Yep, that was the hope. This set of labels was supposed to convey to the author that the issue was going to be transferred. Likely a silly state and something we can express with status/

[crazy-max]

I don't think this one is necessary, we already have a feature to convert an issue to discussion: https://docs.github.com/en/discussions/managing-discussions-for-your-community/moderating-discussions#converting-an-issue-to-a-discussion

[thompson-shaun]

Agreed -- removing

[crazy-max]

Don't think we should have this for PRs as we don't have any template atm.

[thompson-shaun]

Agreed. Prepping updates to the project processing guide which will have revised labels.

[crazy-max]

What will happen for current issues opened? Will this add a comment for 300+ of them? I don't think we want that 🙈. Can we avoid this for old issues?

[thompson-shaun]

Great question! The start-date was set in this PR to help avoid this situation. The bot will only process issues after the date. As we become more comfortable with it we can move the date backwards.

[crazy-max]

Not sure we want this for PRs 🤔 Some can still be relevant if we want to carry.

[thompson-shaun]

For PRs that we want to exempt from stale processing, we can attach any of the labels under the exempt-pr-label setting. There is an equivalent for issues as well. At the moment this is set to not-stale but frozen seems like a popular option.

[crazy-max]

14 days look quite short and would probably comment on 300+ issues. Can we first extend to smth like 360 and decrease in follow-up?

[thaJeztah]

Just some quick blurbs 🙈

• Generally, I try to be more "permissive" (conservative) on feature requests than bug reports
• ☝️ many feature requests don't go "stale", but they may be collecting feedback/use-cases (which can ultimately lead to an implementation of a feature - not necessarily exactly the feature that was requested). I've seen many feature requests that were not a "hard reject", but also not (yet) clear on use-cases (which are important to consider a design).
• ☝️ Admitted, some of this is from "before discussions existed", but having a public ticket for users to "add their use-case to" can be useful to get a picture of use-cases, and sometimes a "cluster" of feature-requests starts to form, which can be the start of working on a design.
• 👉 bugs tend to be different; most bugs that are still open are either poor reports, lack a reproducer, and have not been confirmed (because of that); I do agree that 14 days is much too short, but after some months, it's ok to post if the issue still is observed by the reporter(s).
• ☝️ that said; we should take care to not automatically close if a ticket has not been triaged at all. I've seen some of our issue trackers where valid tickets were reported, but due to limited bandwidth of engineers not been looked at, and closed automatically. That's a bad experience (effectively we're blaming the user for not having their issue being looked at within a reasonable time-limit)
• ☝️ ideally we'd have a flow that excludes such cases from being automatically closed (or in reverse; them going stale being an indicator to the engineers to do triage)

For the "thank you for your pull request" comment; I'd avoid adding that comment, unless the comment adds value (e.g. the PR to be adding a comment "this is what will happen next"). Even in that case, perhaps limit it to post for first time contributors. Such comments can add a lot of noise (which GitHub already creates a lot of).

[thompson-shaun]

Closing this PR and creating a new one with adjusted scope.