Improvement needed on Feature Request thread
-
Suggestions below.
-
To be frank: The Feature Request thread has become useless.
"Feature requests for 1.6" was ten months ago and it was a fine idea and now we have got "Feature requests for 1.13". In between there were 1.7, 1.8/1.9, 1.9/1.10, 1.11, 1.12. To seriously participate, users each time have to spend hours paging through hundreds of already existing requests and their respective comments and posting what is still missing. The result is more or less the same each time. It is no use asking the same question again and again and again and most probably I am not the only one to have become bored asking for the same functionalities every six weeks. This thread only makes sense again after the most asked for requests from past threads have been integrated. -
96% of feature requests will not be realized in near year. So this thread is basically useless (for browser).
-
It's totally useless to refill the same feature requests over and over, make the thread sticky and delete double requests and newly implemented features must be marked with "implemented from version x.y.z"
-
- 1 feature request post per thread per user
- No non request posts of any kind or form (duplicate/implemented requests can be flagged instead of replied to).
-
- Feature request platform (...or:)
- One request-post at day per user: just to allow to do easy cleanups and handle any feedback given, remove/merge dupes and delete off-topics. (I hope votes could be merged. I really don't know).
- Move often requested features posts for any new version in a different locked thread - but it should allow voting.
-
@ghpy said in Improvement needed on Feature Request thread:
This thread only makes sense again after the most asked for requests from past threads have been integrated.
That's precisely what I have done for the last few threads — adding the top rated features requests to the first few pages. So now the thread does make sense.
We already tried earlier the idea of a first post with a list of the most popular feature requests, but then no one can vote for individual features, so that dd not work well.
Any system should not make a load of work for volunteers. I use notes to add each request, which takes about 5-10 seconds for each post. Times 50, that's still only five or ten minutes at most.
These are the main points:
- Where possible, use chat to comment on individual posts
- Moderators could delete off-topic discussion and duplicates if they have time
-
Judging by the number of threads and posts asking for improvement of Feature Request thread I would say that it obviously needs improvement but on every thread where this is discussed it ends up with the conclusion that any other method of gathering/managing Feature Requests wouldn't be much better than the one we got now.
Even I opened the thread on this subject while ago and there I said that separate site/platform for feature requests would be the best option in my opinion.
UserVoice platform would be the best and easiest way of managing feature requests in my opinion.
Someone also mentioned UserVoice just a few days ago in a thread on this same subject.
I'm not sure how pricey is that platform so I obviously don't know if that would be cost-effective for Vivaldi.If we are specifically talking just about improving the Feature Request thread that already exists than the only thing that I think would improve it is to have a recap of a previous version requests on a new thread.
For example, the first post on the newest Feature Request thread would have a list of Feature Requests from the previous versions and the total amount of votes for each feature. It would be also nice to have some kind of input from developers where they can tell us which feature requests they are already working on, which ones are planned and which ones are declined. That way you would know what not to request anymore and plus we have some kind of insight.That, however, would require more moderating work. That's why I mentioned UserVoice because all those actions would be automated and altogether would be a more convenient way of gathering requests and ideas.
-
@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.
-
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).
-
Need SORT BY VOTE, im too tired of scrolling through hundreds of post to support hot request.
-
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.
◊ More CSS Mod ◊
-
@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.
-
Oh! Ok, didn't saw that. Thanks for the info.
-
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
-
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
-
@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.
-
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).
-
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.
bug logging monkey
How to write good bug reports -
@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)
