Regarding automatic closing of issues older than a few weeks

[cipriancraciun]

In 2021 I've opened a feature request (#1248) that @hairyhenderson said it seemed as a good idea, but one that would perhaps (if ever) take a while to be implemented. (Which, just to stress this point, is quite fine! This is open-source, nobody owes anything to anybody!)

However today the "bot" slapped a "stale" label on the issue, and gave a few days notice until relegation to the recycling-bin.

Now, given my non-involvement in the project (I'm at best a passive consumer), it's not quite my place to comment on "automatically cleaning issues older than X days", however as many others have pointed out (on the internet), this policy doesn't work quite well for open-source projects, especially for feature requests.

For once it could lead to duplicate issues (as by default GitHub searches only in open issues), secondly it could send good ideas (that didn't yet get implemented) into the recycle-bin. Also, again given the open-source tendency to happen "in spare time", it's not unheard-off a feature being implemented 4 years after it being requested. (For example I'm tracking some Firefox issues that are almost 10 years old and still being discussed from time-to-time.)

So, I'm very OK with a maintainer closing any ticket for any reason (because it's their time and effort), however I think it's counterproductive to automatically (as in a "bot") closing everything that hasn't been touched in a while.

Moreover, even as a passive consumer, I took some time to give a thorough explanation of the feature request, and then in a few replies to refine the idea. But afterwards, just because there was no activity on that issue, a "bot" would just throw away all that. So now, say next time I want to use gomplate I find another feature request (or even complex issue); do I allocate any of my time to describe it, knowing full-well that, given the chance of it being implemented in 60 days might be close to zero, a "bot" would throw all that away in 60 days? I would say not... I'll just apply a workaround and move on.

[hairyhenderson]

Hi @cipriancraciun, thanks for posting.

Gathering feedback and re-engaging people in issues was one reason that I enabled the stale workflow, so while you may disagree with the fact that I enabled it, this is exactly the effect I was hoping for 😉

I'll answer a few of your points below:

as many others have pointed out (on the internet)

Who? Where? the Internet's a big place - I'd appreciate links rather than a hand-waving "people say that this is bad".

For once it could lead to duplicate issues [...]

This is a risk, to be sure, but it's not an issue that I worry about a lot to be honest. If this becomes a problem, I'll address it then.

secondly it could send good ideas (that didn't yet get implemented) into the recycle-bin. Also, again given the open-source tendency to happen "in spare time", it's not unheard-off a feature being implemented 4 years after it being requested.

This is absolutely true. However, just because an idea is "good" doesn't mean it should be implemented. I've made the mistake a number of times of implementing something that seems like a great idea but turns out to be unused and simply results in technical debt. One example in this project is the BoltDB datasource.

My current thinking is that if a feature is truly worth being implemented, there will be demand from multiple interested parties. If the issue is closed after being stale for 60 days, and then not further acted on for 14 days after that, it's likely that demand simply doesn't exist.

Besides, it's fine to re-open closed issues.

So, I'm very OK with a maintainer closing any ticket for any reason (because it's their time and effort), however I think it's counterproductive to automatically (as in a "bot") closing everything that hasn't been touched in a while.

Given that I'm the one who configured the workflow, maybe it's easier to think of it as the maintainer closing the issue for a very specific reason (it hasn't gone anywhere for 74 days, and the maintainer has no time or interest to deal with it). While I may not personally comment on stale issues or close them, the automated workflow is an time-saving device for me.

Moreover, even as a passive consumer, I took some time to give a thorough explanation of the feature request, and then in a few replies to refine the idea. But afterwards, just because there was no activity on that issue, a "bot" would just throw away all that.

I empathize with this. However, issues will be be closed, not deleted. None of your work is being wasted.

Besides, is it a lot to ask to simply re-engage with the issue and post a comment like "I'm still interested in this feature"? That's all that's needed for the issue to no longer be considered stale.

next time I want to use gomplate I find another feature request (or even complex issue); do I allocate any of my time to describe it, knowing full-well that, given the chance of it being implemented in 60 days might be close to zero, a "bot" would throw all that away in 60 days? I would say not... I'll just apply a workaround and move on.

I honestly hope this is not the case. I really do appreciate receiving feedback and feature requests. Given that this is a single-maintainer open-source project, there's obviously no guarantee that any feature requests or bug reports will be acted on. But I hope that based on past history you'll see that I do end up implementing plenty of feature requests, and fixing plenty of bugs reported by users.