Unleash / unleash-client-rust

Unleash client SDK for Rust language projects
Apache License 2.0
23 stars 17 forks source link

meta: add stale bot config (reference unleash/.github) #43

Closed thomasheartman closed 2 years ago

thomasheartman commented 2 years ago

This change adds a stale bot configuration with a reference to the org-wide Unleash configuration.

About the change

We're adding stale bot as a way to help us manage issues that don't see any activity. When that happens, it's usually because we don't have further resources to work on something or because we're missing information. These issues often go forgotten and end up lying around open. This is an attempt to get around that.

The config file contains the details for how long the bot waits before touching an issue and then how much longer before it closes it if no further activity occurs. (Currently set to 30 and 10 days respectively.)

Keeping issues open

If there are long-standing issues that should not be closed or marked as stale, you can label it with one of the exemptLabels in the stale config file (for instance: pinned). That'll keep stale bot from touching the issue at all.

For maintainers

We know there are differing views on whether stale bots are healthy or not, and we would not want to impose a bot on a repo that we do not control. So if you're not sure this is a good idea (or if you're sure that it isn't), let us know, and we'll have a discussion. If we come to the conclusion that it's not the right decision (for whatever reason), then we're happy to leave the bot out.

Further, if you're happy to accept the stale bot, but don't like the org-wide configuration, then we can also override parts or all of the config to make it fit better with this repo.

rbtcollins commented 2 years ago

I think this is a very bad idea. Lets talk about it.

rbtcollins commented 2 years ago

A bit more colour on my perspective: when incoming > outgoing, any collection of work will grow without bound. When the absolute numbers involved get large (100's+) I'm in favour of automated reduction of requested work to keep cognitive load low.

However there is a difference between 'known defects' (an asset, not a request for work), and stalled discussions (whether discovery, exploration, or troubleshooting for a user). The former should not be closed unless the cognitive load itself is a problem; the latter should absolutely be closed once they go quiet, because they are debt, not an asset.

However today, the rust SDK has such low numbers that cognitive load isn't a problem to solve, and we don't have any open tickets that are stalled discussions (even the stuck PRs are ok IMO, expect perhaps one). They are potential assets waiting on time.

So, 'very bad idea' is too simple. Lets revisit when there are > 2 pages of bugs.

thomasheartman commented 2 years ago

Thanks for the input! I'm very happy to leave this out until we get "> 2 pages of bugs".

I agree with you on what you're saying and also your classifications between known defects and stalled discussions. (This is also the reason why we have certain labels that'll keep the bot from doing anything.)

And I agree that this client itself doesn't really have enough issues/prs that it's much of a cognitive load. However, Unleash in general has more than enough issues and repos to warrant automation, which is why we're applying this now. But because we share this repo with you and because you are as active and vigilant as you are, I'm more than happy to just close this.

So in summary: appreciate the input and agree with your points. Closing until it becomes an issue 😄