# Feedback management problems → now you can vote → now you have up to 100 votes **URL:** \ **Category:** Methods\ **Created:** [June 30, 2021, 2:44pm UTC](https://community.fibery.io/t/feedback-management-problems-now-you-can-vote-now-you-have-up-to-100-votes/1735 "2021-06-30T14:44:49Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [August 26, 2021, 6:50pm UTC](https://community.fibery.io/t/feedback-management-problems-now-you-can-vote-now-you-have-up-to-100-votes/1735/8 "2021-08-26T18:50:50Z")
Moving this reply to a more relevant thread as it’s mostly about feature voting. Sorry for the long response, but hopefully this illuminates some things, and does not itself require a mile-long response from you. 😄 > [@Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type](https://community.fibery.io/t/polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/42): > > I wanted to just let you know that I moved my vote here over to the request here: > > Right now I need that above request more than Polymorphic, but it’s hard for me to quantify to what degree having said that… That’s OK, I moved my vote too 😉 It’s interesting to see how I have felt the desire to shift them around depending on various factors over time. For example, for me it is not just about what I need most right now, but also what I think is most likely to get done “anyway” vs. something that may “need more support”, as well as relatedly whether something has “enough” support _without_ me, and I can thus use my votes for “underdog” things perhaps. 😃 > [@Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type](https://community.fibery.io/t/polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/42): > > I would really like to also point out that I don’t understand the 5 vote limitation. In particular for many of us veterans of the forum, it would be nice to be able to vote on more posts. I think Team Fibery could give us some good faith that we won’t go voting willy nilly. I think it’s odd and artificial that I have to remove a vote here because I don’t have enough. The number of votes is actually intentionally limited in the way the plugin was developed. It allows the forum admin to set a specific number of votes for each “trust level” ([a Discourse concept explained in more detail here](https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/)). I would say the defaults of the plugin are rather low, but the idea is arguably sound, which is that more long-time members of the community, who are thus more “invested”, get more ability to influence things with their votes. The reason for vote limits at all is it should better represent the real value of things to people since they can’t just go upvote _everything_ that they care even a little about. It’s not perfect, but it’s a simple and reasonably effective approach, at least in theory. But one problem with this - which is not Fibery’s fault, but a limitation of the “vote” plugin for Discourse - is that the votes count for both feature requests _and_ bugs (well, I should say, they count for _any_ category that voting is enabled on). [I have recently advocated for allowing per-category vote limits](https://meta.discourse.org/t/category-based-vote-limits/58486/10?u=oshyan), which I think would be very helpful and sensible (particularly in the distinction between bugs and features), but so far there is no real traction on that. If Fibery was interested in contributing a little money to the problem, I imagine I could get some “matching” funds. Say $100-200 or something. I’m not sure if that’d be enough to fund development, but it’s worth mentioning. Anyway, as I said the number of votes depends on your Trust Level. Somehow you are a “Member” here, which in the plugin’s default config gets 6 votes (you can see your votes here: [Profile - B\_Sp - Fibery Community](https://community.fibery.io/u/b_sp/activity/votes)), while I am “Regular” (as in a “forum regular” I think), which gets 10. Given your activity here I have no idea why I’d be a more “trusted” member than you, and keep in mind this is generally an automated, system-driven trust level “promotion”. So somehow I did something that the system considers valuable that you did not. I would certainly advocate for a manual promotion for you to “Regular” at the least (Trust Level 3, i.e. “TL3”), if not “Leader” (TL4). So for @mdubakov and team, two suggestions, and a request for consideration: - Give @B_Sp Trust Level of at least 3 - Adjust Voting plugin to increase number of votes per-level, at least somewhat (someone who has interacted as much as @B_Sp has should really get more than 6 votes!) - Consider pledging some small amount of money to [funding dev of a per-category vote limit addition to the Vote plugin](https://meta.discourse.org/t/category-based-vote-limits/58486/11?u=oshyan) > [@Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type](https://community.fibery.io/t/polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/42): > > I’d also like to pose the question to @mdubakov around this point, and @Oshyan eager to get your 2 cents too, that do you guys limit feedback in your back channel to just 5 votes per user? So if a user writes in a request a 6th time, how would you figure out where to remove the vote? I’m asking because you’ve generously shared your backlog and votes around features in the past, often showing that requests you get directly from users have far more “weight” in votes - and that’s how you showed them, with actual numerical value - than requests here in the forum. I recall that Polymorphic barely showed up in the chart here: > > [Most Requested Product Areas](https://vizydrop-svc.fibery.io/svc/vizydrop/shared/drop/5f92f75b7f92dd2c10305d92?authkey=34f99b058d01e0b41a96) So the way I see this is that each feedback channel has to be treated differently because the rules, limits, and general interaction paradigms are different. This would be true even if “voting” were not an option. For example let’s say you get 10 requests from a single person in Intercom for a feature that is important to them. You will very likely _not_ get someone in the forum posting 10 times about a feature, because it’s public and considered bad etiquette (not to mention mods generally clean up/merge such things). And with votes or “hearts”, one can only express importance a single time. So how to gauge importance of a feature for each person? Systems like ProductBoard make this explicit such that each user can indicate “nice to have”, “important”, or “critical”: [https://portal.productboard.com/gvwfgxmcwqylldrxlfagmgkw/tabs/2-new-features](https://portal.productboard.com/gvwfgxmcwqylldrxlfagmgkw/tabs/2-new-features) ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/0/02c3be0ae32b3da2a2fade4e4eec446ba93a95db.png) Something similar has been suggested for the Discourse Vote plugin, like “Supervotes” (e.g. being able to use multiple votes on a single feature), but it has so far not been well supported, much less implemented. In any case the point is that the Fibery team needs to have some system for deriving feedback volume and importance, and thus a feedback “weight”, from different sources, in different ways. Discourse makes this easy, to some degree, with the Vote plugin. But it doesn’t exist in a vacuum and so must be harmonized in some way with other feedback sources. For Intercom I imagine it’s harder, but my understanding is that Fibery team gets a lot more volume of feedback through Intercom, so it’s a bit challenging as we don’t see any of that, and unsurprisingly the resulting weights/scores don’t necessarily make sense to us. And of course these things may need to be adjusted over time. You pick one set of ratios and calculations and see if they work and make sense in practice. If not, you have to adjust. There needs to be room for iteration and change. But unless that is made public knowledge, an apparent shift in priority over time can seem arbitrary. A “little bit” of transparency can be arguably more dangerous than total transparency as it tends to invite questions that would be self-evident with total openness. But total transparency is hard too. > [@Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type](https://community.fibery.io/t/polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/42): > > Hope that’s useful. Would really like more votes, because without them I think we have a skewed view of requests. And would really like to know if you impose this limit on the “internal” tracking of users. Thanks! Hopefully you can get more votes whether or not you get bumped up a Trust Level. I think everyone at TL2 should have more. I also think some explanation of how they are calculating weight of Intercom feedback vs. forum feedback would be nice to have. That said, my ultimate hope is to see Fibery (the tool) have a way to expose feature priority information publicly, and for the Fibery team itself to use this to keep us all more in the loop. In the end the data (feedback volume, weight, etc.) is also only one factor in the decision making process, of course. Michael and his colleagues have written extensively and insightfully on the many factors that must be balanced. I imagine you’ve read these, but I’ll post them for the benefit of other possible readers. > **[Use Networks to Prioritize Product Features](https://fibery.io/blog/gems/use-networks-to-prioritize-product-features/)** > > Features prioritization is the hardest problem in product management. Learn how to get better in it using... networks. > **[Enhancing prioritization with networks](https://uxdesign.cc/enhancing-prioritization-with-networks-894760555b04)** > > Prioritization formulas measure features in isolation, missing on powerful network effects. Luckily, there is a fix. > **[How to organize and process feedback for B2B SaaS product \[20/100\]](https://fibery.io/blog/100-posts-about-products/b2b-saas-product-feedback/)** > > Feedback organization helps to prioritize features, build better solutions and engage customers. Let's explore how to do it right in a B2B SaaS product. --- _[View the full topic](https://community.fibery.io/t/feedback-management-problems-now-you-can-vote-now-you-have-up-to-100-votes/1735)._