Auto-label "stale" issues and PRs

[chuckwondo]

At today's Collaboration Cafe, @saberbrasher, @asteiker, @andypbarrett, @danielfromearth, and @chuckwondo agreed that we would like to automate identification of "stale" issues and PRs to help with their management, and ideally encourage traction and movement on such issues, so we can be a bit more responsive.

While we realize everybody's time commitment varies, sometimes a periodic reminder is all someone might need to provide or request a follow-up, or make some incremental change, or make a final push to get something over the proverbial "line."

We would like to make use of the Close Stale Issues and PRs GitHub Action to automate marking issues and PRs as stale, but NOT auto-close such issues (at least not initially).

This particular action provides extremely fine-grained configuration, which should meet our needs (even ones we're not currently aware of), while also providing sensible defaults for the vast majority of the options, requiring only a handful of overrides.

We suggest the following overrides, which we can tune as we get a better feel for what might make better sense:

• days-before-close: -1 (never close issue or PR)
• stale-issue-label: stale (all lowercase, consistent with existing label convention)
• stale-pr-label: stale (there is no "stale-label" setting that covers both issues and PRs)
• stale-issue-message: "This is a call to action because this issue has been open 60 days with no activity. It has been marked as stale. Add a comment (or other activity) to automatically remove the stale label and reset the stale timer." (there seems to be no way to dynamically insert the value of days-before-stale setting into the message)
• stale-pr-message: "This is a call to action because this PR has been open 60 days with no activity. It has been marked as stale. Add a comment (or other activity) to automatically remove the stale label and reset the stale timer."

An important note is that we have roughly 90 issues that have been inactive for at least 60 days, so the initial run of this action would trigger a notification for each such issue, which could be a bit of an onslaught for those who are watching all activity in this repo.

If this is a concern, we have a couple of dials we can turn to mitigate this:

• Set days-before-stale to a value greater than 60 (the default); perhaps 90 or 120
• Set start-date to a specific value (this skips labelling issues and PR created before the specified date)

We could use them in combination (or simply incrementally move start-date back a few times) to provide a bit of a "trickle" instead of a "full blast." After wading through the initial "phase" of notifications, we could adjust them to open a subsequent phase, and continue with more phases (if necessary) until all stale issues have been labeled as such. Perhaps we can wade through them in phases of 10-20 issues each, or we could just rip off the bandage in one, swift go.

cc: @betolink, @mfisher87, @jhkennedy

[chuckwondo]

Note that if we want to label issues in phases:

• Moving start-date incrementally earlier, the phases would be ordered in reverse chronological order based upon creation date of the issues and PRs (newer issues and PRs first)
• Setting a large days-before-stale value and incrementally decreasing it, the phases would be ordered from most stale to least stale (independent of creation date, but rather from longest period of inactivity to shortest period)

So it depends on the order in which we might want to review them.

[saberbrasher]

Thank you so much for putting our chat into (eloquent) words, @chuckwondo! Interested to hear thoughts.

[mfisher87]

I think there's some value in prompting reporters to revisit their issue. The post could include a simple prompt to verify the issue exists on the latest version and then post "still an issue on vX.Y.Z" or something to remove the stale label. But I think we then need to figure out a way to triage those issues instead of putting those users in a constant loop of bumping their issues. The latter wouldn't be healthy for maintainer's time and notification exhaustion. Notifications are useless if the signal-noise ratio isn't good and we tune out... I think we should keep our minds open that this may have a higher cost than benefit, but I don't have a strong position on that right now.