The feature request threads are obviously being provided to stop people from spamming their requests in separate threads/forum boards, and to provide a platform for users to vent their wishes/issues/(sometimes)anger. What you are suggesting is inverse to the current setup and won't happen.

Although you are naturally correct. If you don't get a request to the front of the thread, let's say the first 5 to 8 pages, users will likely never read your feature proposal. And I do indeed doubt that anyone can read through the whole thread, to check if the feature they want to request, has already been written down somewhere. It's a nightmare, especially because search on these forums gives you mixed results and isn't easy to operate.

Problems with the current setup:

Biased voting

Unmaintainable

Duplicate Requests

A separate thread for each request won't solve the issues. In my opinion the better idea would be to limit the amount of posts a user can submit to a feature request thread to exactly one. Deleting all duplicate requests and non-feature request posts should be an additional measure (keeping it clean).

One thread with 100 posts is no harder to search than one forum with 100 threads.

The only practical solution requires considerable effort from moderators or a little more effort from users, neither of which is likely to happen. Perhaps, if the moderators were ruthless, users would learn to follow the rules:

Limiting the number of posts per day will only hamper feedback, which the developers want to encourage, not discourage. Just keep it concise, and post it in the right place after checking that it's not already been done by someone else.

You both got me wrong. Not 1 post per day, but 1 post overall. The number of posts in a feature request thread would thereby directly represent the number of users who have suggested/requested a feature. Everyone just posts the feature most important to them and can upvote the other features they are interested in posted by other users. Would work out just fine and make much more sense. Especially considering that the number of engaged users should potentially (and hopefully) rise exponentially over the coming months/years.

Feature Requests are wonderful - but I think Vivaldi needs to do a reality check and perhaps consider another approach going forward.

The reality is:

Vivaldi has a small development team that’s busy and at capacity.

There are major new features (Mail, Sync, Mobile?, and likely others) that are still in the works, at various degrees of completion, that need to be completed.

There is a huge list of bugs (even after triage) that still need to be fixed.

There's a practical limit to the number of new features that can make it into a snapshot cycle, and that's only if the next Chromium release doesn't cause major issues.

Vivaldi has probably received enough feature requests to keep them busy for YEARS. Some of those feature requests likely merit their own version number.

Chrome/Chromium 59 will get released next week and we still haven’t seen a Vivaldi 1.10 public snapshot build based on this code base.

Feature Requests serve to keep the Vivaldi community engaged and Vivaldi gets indirect feedback about product sentiment, but that’s about it. The threads get unwieldy and there's no feedback (in the reverse direction) as to what ideas are being considered in short-term or long-range product plans.

At this point, we’ll be better off if Vivaldi simply publishes a Roadmap (subject to change at any time) outlining what suggestions they plan to implement next. (They can still have "secret plans" that they withhold for competitive reasons.)

As Vivaldi progresses, people will still share their feedback (as they have done in the past) and Vivaldi's priorities, in turn, will evolve and change.