Upcoming Feature Requests Reset - suggestion

0 favourites
  • 9 posts
From the Asset Store
Flip Timer for Games
$17.15 USD
65% off
Goodbye to sprite fonts, when you have something new on the anvil for your upcoming Games !
  • Hi Ashley,

    First, I’d like to thank you and the team for all the hard work you put into making Construct 3 better year after year.

    However, I believe the annual purge of feature requests might need a rethink. It doesn’t make sense to delete great ideas from November or December just because of a calendar reset. To use an analogy, this is like tossing out ALL the food in your fridge every month to avoid spoiling.

    A more balanced approach might be to set a rolling cutoff period — remove feature requests that are over 12 months old and have not received a significant number of votes. This way, older ideas naturally phase out, but newer suggestions still get a fair chance. It would also cut down on people reposting the same ideas, which inevitably happens at the start of every cycle.

  • 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.

  • 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.

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

    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.

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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?

  • Ashley The current system is inherently unfair to users who submit their ideas later in the year. These suggestions often don’t get enough exposure before the annual reset, meaning excellent ideas risk disappearing unnoticed. Meanwhile, mediocre suggestions are repeatedly reposted at the start of every year, cluttering the list.

    A 12-month expiry period for all suggestions would ensure equal treatment, as every idea gets the same amount of time to gather votes and attention. At the end of the 12 months, the number of votes would accurately reflect the suggestion's usefulness and popularity. You could then decide the next steps for most popular suggestions — whether approve them for development or decline and archive.

    This approach could also help reduce the number of reposted suggestions, which aligns with your goal of keeping the list short and relevant. If users see that their idea hasn’t gained many votes in 12 months, they’ll be less likely to repost it, as it no longer provides the advantage of being at the top of a freshly reset list.

  • 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.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)