Improvement needed on Feature Request thread

[luetage]

@longlife Yeah, outsourcing the requests makes sense. It solves the problem where to direct users to, if they have a request, cleanly. What we haven't considered up until now, is Vivaldi Forum losing its by far most active and most visited threads, and that there is less reason to join the community in the first place, if you can just bring in your ideas on a third party site.

It's also worth mentioning that the pressure on the developers concerning requested features would rise, since everyone could see clearly for how long a request is up, and how popular it is/has become. Right now this information is obfuscated, and I'd argue only a handful of users had both the knowledge and the incentive to find out exactly up until now.

[Dantesoft]

I wouldn’t outsource it.

If the developers’ prime directive is “Add it as an option”, I think the requests should be a first-class citizen of the forums, until the bug tracker is opened.

We would ideally have a dedicated Feature Request forum, with ideas as threads, and a default sorting of “Popular first”.

The threads themselves would emphasize official moderator/developer/Jon replies, and have an “I recently needed this”/“I never use this” button instead of the up/down vote, that one could select multiple times.
(The sorting of the popularity would need to be changed, from a numeric sum of votes to something like a modified ratings distibution.)

The first post would of course always show the VB-99999 bug name, and an estimated timetable (short term, mid term, long term), with ideally the internal feedback (I realize this would duplicate the effort in the internal bug tracker, and potentially discourage developers to be frank).

Other sorting options for the threads would be the usual: Hot, New, Controversial, Most bookmarked/watched.
Using the built-in forum tags should also help to explore the requests.

Somewhat related, all officially planned features should be included (who keeps track of non-English interviews that reveal future features?), specifically which subset of Opera Classic features, and general direction (e.g. on Privacy, where a built-in ad blocker is currently off the table).

[dude99]

Need SORT BY VOTE, im too tired of scrolling through hundreds of post to support hot request.

[dude99]

TOP 25 VOTE POLL from previous version, to keep older hot request visible to newcomer. This would help developer to see what community really wanted from all time.

[Pesala]

@dude99 I have already done that (see above)

Sort by vote count is already possible too. The drop list is available at both the top and bottom of the thread.

[dude99]

Oh! Ok, didn't saw that. Thanks for the info.

[doum]

you should just use a uservoice like !

It's really easier to find already asked features, vote for them, post our new feature request, see which feature have been rejected/approoved/in dev etc

[Catweazle]

I think it would be more productive to open a thread with 'Feature request' without further, where developers can review the things that are missing and discard the things that have already been resolved. So you don't need to always put the same things for each new version

[Pesala]

@dleon said in Improvement needed on Feature Request thread:

We already have this flag mechanism, why not use it.

I do use it quite often, and I noticed a lot more posts getting deleted.

I also use Chat to notify users if a Feature Request already exists, or to ask them to edit their post if it contains more than one FQ.

IMO, mods should just edit posts and add a note in the post to say why they did it. Users will learn much faster if they see their long-winded posts with multiple requests edited to a single line or a couple of paragraphs.

Other users seeing the moderator's comments will also get the message sooner. Rather than just deleting a post, edit it to say: "Deleted as a duplicate," or whatever.

On the Serif forums, I delete duplicate threads with a link to the other thread. The title reads as "Duplicate Thread," and the content leads to the duplicate.

[ataraxial]

Making version-specific megathreads seems really weird to me. Why does a new thread need to be made for each version? But more importantly, why use megathreads that give no space for discussion when each request could be its own thread?

If each feature is its own thread, it not only allows for discussion and makes duplicates less likely, it also allows for easy organization and communication for the developers. The state of each request would be represented by the sub-forum it's placed in: completed, in-progress, planned, undecided, rejected, etc. This makes it very easy for the developers to respond to requests and reassure the community that they are listening.

Then again, it might be worth looking at a different platform. Something like GitHub Issues could be more convenient (example: https://github.com/madcowfred/padherder-issues/issues).

[QuHno]

Votes in the feature requests thread(s) should not raise the users "reputation" because it does not reflect in any way if the user made a good post or not, but only that someone else wants to have that feature too.

[Hadden89]

@quhno then I'll lose most of my rep points and I won't be a VIP anymore
But, yeah, probably it has sense.
(Even if I prefer the legacy "thanks <3" button which is useless for FR thread)

[ghpy]

@dude99
It is already possible to sort the posts by vote.
But chance is that even with the posts sorted by approval you will still have to read all/most/a lot of them to know whether someone has already posted the one feature missing that you are currently thinking about or whether you have to add it.

[ghpy]

Having separate threads for the most wanted feature requests in my opinion will make it too complicated to keep track - for developers as well as for users. It might make sense for some special feature where a lot of input is needed, but right now I can't think of any feature needing that.

In my opinion it would be a good idea to follow the principle to start the "new" feature request thread with the 20 most wanted features from before, one post each. This has been started or tried before, but it seemed somewhat chaotic to me. My suggestion would be to make the feature request thread visible/accessible to the public only after forum moderators have supplied the first 20 posts as mentioned above. These posts should each contain:

• A bold headline with a short description or name of the feature

• A description of the feature's functionality and options where the headline is not self explanatory. This helps to ensure that everyone (developers as well as users) thinks or talks about the same thing and not about two different features sounding alike.

• A brief information about the status within the roadmap (something along the line of "sure to come next version", "working on it, but takes more time", "very difficult, might collide with the Chromium-base", "new idea, we're still thinking on whether and how to implement this"). For me the current feature request thread had started to seem like a black hole which devoured users' feature requests - the features hardly ever seemed to end up in Vivaldi itself. This will help prevent us - the users - from getting this idea.

A forum software is probably not the ideal base for a feature requests thread which is kind of a mixture between brain storming and opinion poll. But I think changing the thread this way would at least make voting more effective. It will surely reduce the number of double-postings for the same feature. It suppose it can also reduce the number of posts as a whole as the explanations for the most wanted features will prevent misunderstandings leading to questions and answers and additional remarks going back and forth which make the current thread time consuming to digest.

[Pesala]

@ghpy Note: To search for feature requests that have already been posted use the search icon in the black header, e.g. to find recent posts on Bookmarks. I think most of the popular requests have been added already.

[duarte.framos]

There is one big issue which is skewed voting.

The first posted feature requests get a lot more attention because of the very high visibility, regardless of feature quality or desirability, when compared to most recent posts. Obviously no one in its right mind will scroll trough 40+ pages or repeated stuff nor bother reading through.

Then there is the plague of repetition, because it is not easily searchable people post the same stuff over and over again. A per post search feature like "search this thread" for the forum would be highly useful here.

If these are taken seriously I'd also strongly encourage either for a dedicated feature request system, or if we lack the manpower to implement one properly, them just use some third party service.

It would obviously have to be moderated, i.e. someone would have the boring job of going through all new posts and merge all duplicates with the proper "master", and ideally categorize/tag/organize them into general/specific areas of focus, like "Bookmark Management", "Security", "Privacy", "UI", "Interaction" "Performance", "Optimization", etc.

Creating new requests would suggest existing ones before committing, and upon visit users would be presented with a random set of posts, so most frequent don't accumulate unwarranted votes.

GOG has a relatively decent system with "Most Voted This week" to prevent favoritism while still presenting frequent requests.

[michaa7]

@ayespy

Unfortunately the "feature request" section is an unorganized dumpster.

[Pesala]

@michaa7 Don't be silly! It's a very well organised dumpster. You just need to learn how to search properly.

[iAN CooG]

haha! admittedly the search function is messy in this forum

[luetage]

@ian-coog Opera is advertising and highlighting nodeBB's superior search functionality on their forum introduction just now