Stale bot - "pinned" label?

What are people’s thoughts on having some form of “pinned” label for GitHub issues / pull requests so that stale bot never marks them as stale?

I’m bringing this up after seeing @adrian’s comment on #1893 - it sounds like we should keep this open until a solution is found, and continually bumping it every 60 days will just add spam to the issue.

Is it worth setting up some form of label to disable the tale bot? It seems like there’s a configuration option exemptLabels which could be used if we do set one up.

Hey there! That sounds perfectly reasonable to me. For that particular ticket (and maybe others?) another reasonable option might be to just turn it into a discussion-tagged ticket, because it’s not clear whether there’s any particular action to be taken but folks are welcome to keep digging and adding their thoughts there if they want.

I had been thinking about this too, and I actually think it may be good to close, but continue to allow discussion. This way it keeps the open issues to only actionable things. Then, once it becomes actionable, it could be re-opened.

In this vein, it would be discouraged to un-stale the issue by commenting just to bump, rather than providing progress towards making it actionable.

(Couldn’t find another discussion of the stale bot itself)

Now that the bot has been run on all the years of beet issues, I think 60 days is too short of a window, especially when some of these issues require deep thought or massive reworks. Beets does not see that many contributions in 60 days. What’s the count, ~25 accepted commits in 60 days?

We now have months of the stale bot running. What do we gain from it? To me it creates a false sense of success. Just because I’m not logging in to tediously say “yes” every 60 days doesn’t mean I don’t care about the issue. Sure, that’s a sign that it’s a very low priority (and devs unaffected by it should perhaps focus attention elsewhere), but I don’t see the harm in having 459 issues vs. 459+1 issues.

I was initially skeptical, but I’ve actually been pleasantly surprised. Basically, our old system for issues (not PRs) was to comb through needinfo issues periodically and close them; this more or less automates this process, which is great.

The problem is that a huge volume of issues get filed but not followed up on enough to be actionable. This means it’s harder to find open issues that actually have some sort of concrete work to be done associated with them. Making sure we actually understand the problem well enough to mark it as a bug or feature request is a good minimum criterion for staying open. (The stale bot does not automatically close those ones; they stick around forever.)

1 Like