# 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:** 4
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [June 30, 2021, 4:40pm UTC](https://community.fibery.io/t/feedback-management-problems-now-you-can-vote-now-you-have-up-to-100-votes/1735/4 "2021-06-30T16:40:53Z")
Your feedback is insightful as always 🙂 > [@Oshyan](#): > > Do you think most users are going to make appropriate decisions about how/where to put their feature request in your internal organization of everything? No, I don’t think so. I still think that it is good to separate requests from our real features/ideas/stories, since people don’t want to think hard about our product structure and we should not put this burden to users. However, some part of the model can be exposed, for example, high-grained product areas like Integrations, Automations, Search, etc. It’s relatively easy for a user to add requests into Product Areas and then we’ll link them to features/… Then our team links feedback as usual, and the good thing for us here is that we still can show a total number of votes from all sources for the request (we can get it from Feature/Idea/etc as a lookup field). When we’ll have blocks, it will be also possible to include blocks from other source into request, thus providing a more complete view and spark better discussions. Here is the rough idea. ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/2/219766e7f935de96a2067051f9bc42752815449c.jpeg) Note how you can react on every use case (block) and have thread discussion about every use case. It will help us to define what use cases are more important and prioritize our MVP accordingly. Now we mainly have to guess, since requests are often too broad. For example, take this request > [@Versioning in Rich Text Fields (and entities as a whole, too)](https://community.fibery.io/t/approved-versioning-in-rich-text-fields-and-entities-as-a-whole-too/260): > > Hi, I think versioning in general is an important feature and versioning of each entity as a whole is not only useful, it is a requirement in certain compliance context. To begin with, the rich text fields should have versioning (and afterwards diff view between versions, revert back to a specific version, etc. too). In general, using an event-sourced architecture greatly helps with features like versioning, undo-redo, etc. Thanks! It has at least 5+ use cases. Diff, revert, named versions, etc. What is more important? We can guess, but sometimes guesses are not so good. And roadmap report can be quite easy to show, since we can add Start/End date and Status for Request as lookups and just create a Timeline that will show all requests. Everything will be in sync and there will be 0 manual effort to keep feedback and plans consistent. > [@Oshyan](#): > > Canny is the best one I’ve seen so far, at least for the front-end/user experience, but it too has some issues, and more importantly it lacks in integrations with most actual product and dev management tools except through e.g. Integromat. And if it’s all implemented right, i.e. in a flexible model as Fibery has been so far, then it should be useful for lots of other things I would think. I agree about Canny, most likey it is the best at this moment. They get many things right. But if we replace Discourse with Canny, we’ll get almost zero benefits. --- _[View the full topic](https://community.fibery.io/t/feedback-management-problems-now-you-can-vote-now-you-have-up-to-100-votes/1735)._