[Meta] Feature request that's a candidate for backlog has no way to gain visibility and uses arbitrary metric

[scscgit]

When @vscode-triage-bot recognizes a feature request, it says:

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

However, I'd like to challenge that this approach isn't productive and doesn't scale well, as I believe "number of votes" are definitely a less objective metric than discussing and rating. Right now there's no way to gain visibility of your issue, other than being lucky and having people be mad at the same problem right at the same time as you, and there's no incentive for users to judge and iteratively improve less visible feature requests. The number "20" doesn't even seem to correlate with popular issues that have a high user activity; for example there's recently even been one (#100717) where people misunderstood the rules and upvoted the bot's comment instead. My first suggestion is that there should be some official channel where people would be incentivized to read others' issues, and to at least provide them any feedback; possibly even by providing a link from the VS Code application itself, so that the affected "end users" are ones who do the upvoting, and not just "vscode contributors and issues' authors". But at the very least, the feature suggestion authors could be the ones trading votes, because right now if you go out of your way to review 100 issues (by using GitHub search with a feature-request tag filter, which is definitely "intuitive") and upvote some of them, your effort isn't reciprocated at all (and there's no difference between a closed issue that had 2 votes or 3, so you effectively just waste time and don't help anybody - but I doubt there are many users who go around it so directly, so I'd like to hear from the people who came up with this rule if they even do it this way themselves, as it'd be a hypocrisy otherwise). And when it comes to any public discussion channels, there's barely a Discord channel linked on Reddit, which has some users, but you're lucky if you get few upvotes or one reply.

The triaging wiki documentation describes that after 60 days, an issue is closed without any compromise, so basically even if you get 15 upvotes, it'll be simply rejected, and there's no plan to ever re-open it. I'm not sure if this means that you're still able to open a duplicate with the same content and try to gain the same traction anew every 60 days, or if duplicates are against the rules. In any case, my second suggestion is that while an issue is still growing its number of upvotes, there should be at least some extension (even if it means increasing the number of required upvotes a little bit) - I believe that organic growth is supposed to be exponential, so I don't really care about how the issues are prioritized, if it takes two years for the momentum to grow then it so be it, just don't kill the momentum using arbitrary means. Note that this wouldn't be a problem if GitHub allowed issues to be re-opened by users (isaacs/github#583). Though to point out an opposite end of the spectrum, look at how some issues describe a basic necessity any IDE must have #26339 and yet even 200 upvotes over 3 years weren't enough to even receive a reply from a developer (but luckily there's an extension for this, you just need to exactly know what you need without relying on sane defaults).

My third suggestion is that instead of only counting upvotes, the decision to reject a proposal should be based on a ratio or count of upvotes and downvotes. Unlike an issue closed because nobody found it, if there's any reason why people dislike the feature, if nobody wants to use it (even after they are given the option, because people obviously don't know what they want until they have it), if there are better alternatives already available (like extensions), or if there's actually a technical limitation why it would be hard to implement (which I doubt is the case for most subjective UX-related issues); then it should be suggested to close the issue simply based on community rejection. Even a feedback in the form of "this looks unnecessarily complicated", "it's hard to understand", or basically "TL;DR" should be solicited in order to motivate the feature suggestion author to refactor the specification to match the needs of users. A silent treatment doesn't improve anything.

---

And to advertise my latest UX feature suggestion with a use-case analysis, you can check out if you'd like to have the option to hide the Tab Close Button (X) on inactive tabs, and to have it always displayed to prevent misclicks: #100782

[oscarrutt]

I agree with @scscgit. There are tons of great suggestions for new features that have disappeared simply because of this dumb system. THIS IS A MAJOR ISSUE which needs to be fixed. I'm sure there will be other ideas for fixes but the obvious one is to have a page of suggestions with voting on the same page. Even a modicum of human intervention would be better than this clueless bot.