github workflow stale threshold does not provide sufficient time for review of pull requests

[bpow]

This issue is prompted by the automatic closure (twice) of PR #7297 as "stale" (pull request was filed 2022.02.21, auto-closed 2022.05.12, manually reopened 2022.05.12, then again auto-closed 2022.08.06).

Steps to reproduce

1. File a pull request
2. Await core developer response

Expected behaviour

Threshold should be long enough for core developers to have enough to time to accept or otherwise comment on the feasibility or improvements needed to the PR.

Actual behaviour

If no response in 30 days, the issue is marked by the bot as stale. 5 days later, if there is no response, the PR is automatically closed. While it keeps the "pull request" list fairly clean, it has a few disadvantages:

1. It is not very "community friendly" by not acknowledging the potential contributions of community members. I'm not sure if the appropriate response is just to re-submit the pull request, but that creates additional burden for contributors. To me, a "wont-fix" is better than closing without response, because then at least I know not to try to press the issue.
2. It can make it harder for developers or users to find issues that have not only already been identified but for which someone has done some work to try to address
3. Related to the second point, this auto-closure makes the number of open pull requests not be an accurate metric of development activity

Browser/system information

Not relevant

Additional details

I can think of a few potential approaches:

1. Lengthen the general threshold in .github/workflows/stale.yaml to allow core developers enough time to respond to pull requests.
2. As discussed on Slack, pull requests from community members
   could be tagged as such so that such pull requests would not be automatically expired as stale.
3. Implement internal procedures to ensure that core developers can respond within the existing threshold
4. If it is not determined to be practical for core developers to triage/respond to PR within some fixed amount of time, or if there are other mechanisms preferred for small contributions, these expectations should be clarified. For example, some of the test of the current contributor guide may need to be revised:

   For trivial changes, such as documentation changes or minor errors, PRs may be submitted directly to master. This also applies to changes made through the GitHub editing interface. Authors do not need to sign the CLA for these, or follow fork or branch naming guidelines.