Proposing a fix to the feature requests sub forum
-
The Problem
Currently, a new feature requests thread is created every snapshot cycle.
This gets filled up very fast, meaning people either have to flick through the entire thread or search for their idea to see if it is already posted.
The search system on the forum is not optimised for searching through a single thread, meaning a user needs to do some trickery to guess what timescale to limit posts to. It is not immediately obvious to people how they should go about doing that.
There is lots of duplication between each new thread and the previous one - This is adding unnecessary steps.
There is often discussion regarding feature requests taking place in the feature requests thread itself - which only adds to the complexity of the thread.
This discussion is interspersed with other feature requests which makes navigating a conversation difficult.
This in turn discourages discussion, which goes against the whole point of having a forum.
If a user is informed that they have made a duplicate request there is no way for them to easily delete their own reply, they must edit it to something blank, which again, does not help the complexity of the situation.What the solution requires
- Remove the need to have a new feature request thread each cycle.
- Allow discussion on a particular feature to be contained.
- Allow easy searching of feature requests.
- Allow voting for a particular feature request.
- Allow for a duplicate post to be easily deleted without needing to bother a moderator.
Proposed Solution
Stop using threads for feature requests.
Instead, use the feature requests sub-forum as it currently stands. This means that: A new topic can be created for each feature request. And therefore any replies can be kept neatly within that topic. Topics can also be voted on. Also, topics can be tagged, allowing them to be more easily grouped together.
There would be no longer a need to make a new thread every snapshot cycle, which removes the need to continually duplicate requests each time, and would keep any discussion that may have happened intact.
You can more easily search topics this way, as in search you enter The string, set to search titles only, and in the feature requests subforum, and can refine this with tags. Compared to the previous method where you would need The string, in the feature requests sub forum, and then guess a valid time filter to use, which isn't very granular, and could not refine a search any further. And because you no longer need to worry about changing the time, you can easily direct users to a URL which doesn't need to be kept updated in order for it to work: Click here to search for a feature request.
It would also be nice to change the forum settings to allow users to delete their own topic, I'm still not entirely sure for the reasoning of not allowing that considering the menu items have a delete entry already there.
This would also allow for topics to be sorted by their vote count, view count, replies, which could add more metrics to seeing which features would be most liked by people.Basically, that's my idea. I understand that resources to implement changes are limited, but I saw no harm in at least putting the thought out there.
Hopefully I've put this in the right sub-forum of Forum Feedback. I didn't really think it was a forum feature request. -
best way would be an ad-hoc feature request platform, but probably require time and money.
I hope to see that in future ^^ -
@hadden89 I had considered suggesting something like "uservoice" - as used here: https://feedback.discordapp.com/forums/326712-discord-dream-land but felt it was unnecessary given that the forum, if used properly, could function just as well and not require any additional funds.
-
@lonm True. But a coherent feature platform it's perfect to see any request any time and it's easier to be browsed by devs/mods/users, dupes can easily merged or avoided - as any user can see when/if it's already requested and vote it.
-
We had several threads already on this topic.
E.g.: https://forum.vivaldi.net/topic/17020/separate-thread-for-each-suggestion
Truth is we shouldn't take feature request threads all too seriously, the developers aren't either. What it boils down to is that the main purpose of the current feature request threads is to prevent a flooding of the forum with different threads for each feature. Possibly not only on the dedicated forum board, but also on platform boards, because this was the general situation before they introduced the official request threads. Therefore I don't think they will ever go for the one request per thread solution. What makes more sense is bringing the requests off-site, but I don't think they can spare the manpower to maintain/manage this in the first place.
-
@luetage While writing this I was well aware that it was likely nothing would really come out of it, but I wanted to say it anyway. (I guess kind of like the feature requests I've made.)
-
One thing that might not be too hard is for a moderator to sort the old thread by number of votes, mark all posts above 20, then clone or move them to a new thread for the next version.
Any system must work with a bare minimum of input from devs and volunteers, otherwise it would detract from the import issue, which is working on the browser.
-
@lonm said in Proposing a fix to the feature requests sub forum:
Instead, use the feature requests sub-forum as it currently stands. This means that: A new topic can be created for each feature request. And therefore any replies can be kept neatly within that topic. Topics can also be voted on. Also, topics can be tagged, allowing them to be more easily grouped together.
There would be no longer a need to make a new thread every snapshot cycle, which removes the need to continually duplicate requests each time, and would keep any discussion that may have happened intact.+1
I think 98% of all feature requests from previous feature requests threads are moved to the new thread. Because every new Vivaldi release has only 3-4 new features.