Upcoming Feature Requests Reset - suggestion

Some git projects have stalebots that automatically mark stale or close issues after a set amount of time.

Oh! I thought that only those requests that get few votes over time were being eliminated.

Nope. Everything is purged, and then there’s a rush of users reposting their old suggestions, hoping they’ll stand out and get a few votes while the list is fresh. Then others start reposting suggestions they liked from the previous year. Then the original authors return to find their ideas already re-posted — sometimes in a less detailed or lower-quality form.

Really? This seems like a calamity to me.

We've seen this cycle repeating every year. It’s clear that this system has significant flaws.

Without a doubt.

Implementing a 12-month expiry period for posts and automatically removing those that haven’t received, say, 20 votes within that time frame could be a simple and effective solution.

Totally agree.

Existing ideas aren't deleted - they will just be closed and tagged with something like "Archived 2024", so you can still see them all, but they won't be under active consideration any more.

There are all sorts of ways we could organise this and I don't think there is any one perfect way. Sure, we could auto-close suggestions without enough votes, but there is now unlimited voting, so everyone could just vote everything up enough so nothing much ever gets closed, and then the system has failed to keep things fresh again. It's also possible something gets highly voted, but then sits there for several years, becomes redundant for other reasons, but then never gets closed because it remains above the threshold.

The main thing I want to avoid is the feature suggestion list building up with 10+ years of work with such a huge list of individual suggestions that it's too much time for us to even review or administrate it all properly. Over long periods of time it then also ends up full of all sorts of older ideas that are redundant or no longer important for other reasons (e.g. at one point "make an OUYA exporter" would have been popular - now it's irrelevant). Then from our point of view it becomes something of a millstone around our neck: it's such an impossible amount of work it's stressful to even prioritise or consider it, and people start to get more negative about it ("this has had X votes for Y years, why haven't you done it already?", "look at Scirra ignoring the community", etc.)

So by that point it's no longer an effective system. That's pretty much what happened before, and I'd rather avoid anything that might end up the same way. Closing everything and starting afresh every year might be annoying for some, but submitting an idea you care about once a year isn't a huge amount of work. If you have dozens of ideas we probably can't do them all anyway as that ends up creating an infeasible amount of work for us, so we want people to think carefully about their requests, and only submit the most important ones, not flood us with impossible amounts of work. If something remains important and popular, then I expect it will keep coming back every year and being voted up again, and we'll take notice of that.

Ashley If I can ask a clarifying question - how important is popularity is to the feature requests? (You mention it at the end there.)

As an amateur user, I notice that most of the most popular requests are more advanced features, or for more advanced users. Which makes total sense, since they're using the program a lot more, have more ideas, use git more often, etc.

Currently, it seems like popularity is a factor in the decision to implement. But it means - for me, maybe other amateur level users - that I don't bother making suggestions anymore, because they seem unlikely to get votes. (Updates to the typewriter text, for example.)

I agree with the previous commenter that with each reset, an increasingly smaller amount of users are going to repost an increasingly smaller amount of ideas from this year. More casual users are less likely to invest time in reposting. Together this concentrates the votes over time on advanced level ideas. So it'd be helpful to understand how much popularity is a factor - or maybe it's better for me to share ideas on this forum?

Again, there are scripts/bots that can automatically close issues after a set period of time of inactivity, rather than arbitrarily at the beginning of the year. So every issue will be open for a year, then closed, instead of ones opened in January being open for a year and ones from December open for a month before closing.

I'd be willing to put each issue on its own 12 month timer, but I can't find an easy way to set that up - it looks like all the existing stock GitHub actions are for other management workflows, such as only closing issues if they are stale (inactive for a period of time), whereas I want to automatically unconditionally close an issue after a time delay.

If anyone can point me to something easy that does that by mid-January I'll set that up, but otherwise I'll just manually close everything as originally planned - I'm too busy to spend long trying to figure out how to do custom GitHub actions.

I'll take a look at setting that up. Feature requests are regularly reviewed, but as I mentioned before, we get so many it is a very large amount of work even just to respond to them all in any useful way. If any suggestion you care about for any reason is closed due to expiring, and you still care about it, you can just resubmit it - you will only have to do that once a year.

Just an update - I set up a bot to auto-close issues after a year, rather than having a one-off clear-out, and it looks like it's working OK. So I've updated the feature request guidelines to cover that and we'll rely on that going forward, with every submission getting its own 1 year time period.

Thank you!