I know i know, but this was not even a good idea 
Well to explain my thoughts about it: as a developer i like prioritizations, especially if said prioritization is done by a democratic majority.
Helps you get the fixes into peoples hands that are most common. And then you work down the list.
1 Like
I agree on this. And i think this is done internally already.
I like to differenciate these two things. You usually dont run into features that break your workflow, your project or whatever.
Looking back at the weekend, my feature suggestion would be a “moan zone” subforum then😅
3 Likes
And another fair point. Given the lifecycle of products in general that’s something that could be optimized, it takes too long to reach the bottom of the list.
1 Like
For what is worth it, it is possible to set different amounts of votes available based on the user’s trust level i.e. giving members more votes than newcomers.
(Just providing technical information; not endorsing or opposing the idea.) 
I saw that, with the limitation that it only works based on trustlevels and not other groups sadly, which would have been far more practical 
Trust levels are designed in a way that it is difficult to game the system without actually becoming a useful contributor to the community. Putting the incentive in simpler types of activities has the risk of getting people doing whatever (more likes, more posts, more this, more that) just for the incentive.
1 Like
I mean.. for that matter the trust system works exactly like that as well. There‘s only x metrics you can use in a forum for these types of things.
It‘s still just a spontaneous idea at this point and i‘m glad y‘all are spitballing with us on this 
1 Like
No, I think you simply don’t see the whole picture here. Here’s what I think you are missing:
- all bugs should be addressed, but as we can see they aren’t
- a developer’s day has 24 hours, just like your’s, and every hour spent fixing a bug can’t be spent on an new feature, so bugs and features are competing for developer time time, therefore it’s obvious that they need to be prioritized against each other
- everyone uses the device differently, some people prefer bugs being fixed instead of new engines being added, and these people should have their voices heard
Even though it mighlt look like bullshit to you, it is a suggestion that comes from a couple of decades of experience with software development.
Really? Unlimited votes are meaningless, people would just vote for anything that is not outright a stupid idea because they can, and it would be nice to have that feature.
The key idea of a vote is that you express preference, mark what is exceptionally valuable to you. The more things you mark, the less of a preference you express. When everything is a priority, in fact nothing is.
You can see votes as the currency you can invest into new features, maybe it makes more sense then. Your funds are limited, you can change what you invest in all the time, and for stuff that has been implemented, you even get your money back.
Yeah, but that is hard to see for those who want to see what’s most important to us, with votes, they get a ranked list.
1 Like
That’s not a community problem, that has to be adressed internally. So lets not dictate as a user what the dev has to do next.
See above. That is on the companies level. They decide and that’s good.
My words, you have read my comment?
I happily contribute bug reports and like the communication on that.
Well, apparently it is not addressed internally, so some cues might be in order, and I find it odd to vote for features only when there are open bugs that are more important to me.
User feedback is relevant for product decisions, and this is as structured as it gets without Polyend investing much time into it.
From what I hear people say here and elsewhere, what is decided is not universally experienced as “good”, quite the contrary. That goes for the priorization of features over bugs as well as for the priorities of which bugs are fixed, or fixed first.
I mean if Polyend say they don’t want that, that’s fine. But given the current backlog of bugs (and there’s more that are not even tracked here) I’d say some help is in order.
Care to elaborate? As I read it, you are not in favor of votes for bugs, and you don’t offer any alternative for how people’s voices can be heard in relation to their preference of which bugs should be fixed, or at least fixed first.
Well my opinion not being allowed to vote on anything else because you used all your votes is meaningless. Now you have to wait for others to vote for something you want if you don’t have any feature to take a vote from… And well this forum isn’t a very hopping forum and voting takes forever here. So to me THAT is more meaningless in the end.
Believe me, this forum isn’t that active that we’ll have a issue with people just voting whatever and whenever…
The system should be unlimited but only put limits on allowing 1 vote per request and per person. It’s how ableton does it and others and we still get things we voted for when it out does the others.
This. There are far more Polyend customers than these 40 somewhat active members on this forum. With the open wishlist feature now the votes are scattered all over the place, nothing comes even close to the old requests with the 50+ count.
And now imagine 200+ bugs, few are upvoted by what? 1 or 2 votes.
It doesnt represent the majority of customers.
It has been said here on this forum already, high voted things are a suggestion to the devs but not guaranteed.
In addition, most of the roadmap for the year has been made, for fr you now vote on, you’ll have to wait at least mid to end next year.
My count is different, do you see bugs that are not public?
What I see is:
- around 500 open feature request (not counting the archive)
- around 120 open bugs (logged and new)
So adding bugs into the picture does not make that much of a difference.
If you change the rules of the game, people’s behaviour will change, too. If it doesn’t, why change the rules in the first place?
With unlimited votes, when I see an new request, I no longer ask myself “is this more valuable to me than another feature I already voted on?”, but “is this useful for me?”. So all the other feature requests are no longer in the picture, everything is considered in isolation.
As I understand it, this is why you want more votes, you don’t want to think about other features, just the one you’re looking at.
So this change will lead to higher vote counts, that’s for sure. But is it also a better fit for purpose, i.e. will it lead lead to different feature requests getting the most votes, or to a clearer ranking?
The only way to find that out is through an experiment, where we agree on what to try, and for how long, what we would consider a successful outcome. If we achieve that outcome, we keep that, otherwise we’ll roll it back (if we don’t decide to extend the experiment, or update it).
Now, I just checked the documentation on voting, it seems that you need to set an actual number for the maximum of active votes (per Trust Level, but those could be set to the same number if desired), so unlimited votes might technically boil down to “1000” votes. It also looks like reducing the maximum number of active notes will not remove any notes, but people will need to remove any votes that exceed the new limit before they vote again, so we could roll back without too much of a hassle.
So an experiment could look like this (all up for debate, just as an example to illustrate the process):
What we do:
- we take a snapshot of the current state (e.g. a list of all feature requests and their votes, if possible a scatter plot of how many people cast how many votes)
- we increase the number of votes to 100
- we open voting on bugs
- we let that run for 3 months
Successful Outcome
- people who cast a vote while experiment is running cast 20+ votes on average
- the ranking of existing feature requests has changed substantially: when removing any new feature requests from the list, for each device 3 existing feature requests that were not in the top 3 are now in the top 10
- in the top 10 topics for each device are at least 3 bugs
- Polyend confirms that the new ranking is more helpful, and has led to reconsidering the roadmap because they got unexpected and valuable information out of it
As I said, all just suggestions to illustrate what an experiment might look like.
Yeah i stand corrected, in my list are also the archived ones by design etc.
But…i have a few more on my “to confirm” list here 
hears a distant scream…
In general, the community is great.
My only gripe really is lack of response from mods when I’ve reported bugs. A little acknowledgement goes a long way.
3 Likes