Automatically mark and close stale issues

[akshualy]

Heya, I've gone ahead and closed a few stale issues I was comfortable closing just now. I think we can probably automate this with one of the bots here on GitHub, what do you think? Considering how active we are, this should bring no issues with it and we can probably configure it to ignore "feature" issues? Not sure, just wanted to throw the idea out there outside of an issue :)

[Kyrluckechuck]

Thank you for dealing with those! I had added the stale label since we'd had no responses for a while, so that made sense 👌

On the flip side, I really dislike bots who do that because I've come across a large number of issues in GitHub projects which have not been resolved and the stale bots have marked and/or closed these issues, so the maintainers no longer pay any attention to them. Then when a new ticket is opened on it, a lot of back-and-forth happens between the old issue and the new one, and details get lost along the way.

I could potentially see going that route would make sense if we had some system to ensure it's only low-quality issues that are getting closed (like things we add a specific 'label' to, such as the stale one), but tbh for now this project is small enough I typically plan to follow up on tickets I've commented on with no responses about a month after 🤔

I see pros for and against, just none enough to push me to implement it, if that makes sense

Curious to hear feedback on that, though!

[akshualy]

I definitely understand that point. I don't want to "take over" your repository, but old issues kind of annoy me. Honestly, my mind just went to "bot", so I don't have to deal with the decision of marking or closing stale issues 😅 If we can outline some general-ish rules, that's fine by me as well.

Some suggestions:

1. Issue is marked as stale if it has not received a response for X days after we asked them to clarify or test changes made.
2. Stale issues are closed after X days of being stale.

X is defined by:

1. Low-effort issue/PR - No meaningful title and or description: 7d
2. Medium-effort issue/PR - Issue is uncommon/not reproducible, PR is not in a state that's mergeable yet: 14d
3. High-effort issue/PR - Anything not considered by the above: 30d
4. Enhancement issues by collaborators and authors: Never, unless the person "leaves" the project, in which case 30d

I'm putting days on it to help others help you keep the repository clean, knowing you will likely be okay with the decision.

[Kyrluckechuck]

Haha thanks, I appreciate you acknowledging that, but I also value any contributor's feedback, and in this case since you're the main/only one aside from myself, it's quite valuable and I don't want to draw any hard lines unless I feel extremely strong about them. In this case, I don't want to draw a super hard line, but I do like this general approach.

I quite like those suggested guidelines, and those timelines seem perfectly reasonable to me 👌

Do you want to document this anywhere or feel like this discussion is good enough? 🤔

[akshualy]

It's fine in here for now, I'd say. As it's - as you said - only a rough guideline and it's also only for me for now 😄

[Kyrluckechuck]

Well, for both of us! 😜