I reflected on Votes in our community and changed my mind. @B_Sp and other community members’ enormous contribution is helping us to shape Fibery (thank you for that! ), but not everyone is ready to write something just to support the idea. While I still think that Votes are less useful than comments, they are still useful and we will take them into consideration for our decision-making process.
Also I gave serious thoughts to our feedback management process, and the end-game for us is to use Fibery as a Feedback Portal as well. It is a long-term goal, but there is a permanent gap between community feedback and our real product model/plans/priorities. There should be a single space where community members can see the whole picture and help us shape Fibery.
It’s hard to do with any external software and Discourse is not an exception. Here are some problems that should be addressed to have a good solution:
We have a product model as a hierarchy of Product Areas, Ideas, Features, Stories and Bugs. It’s very hard to map this model to Discourse. We might map all Product Areas as categories, but it will complicate feedback submission.
We prioritize Features/Stories/Bugs, but this is not visible here and there is no clear way to do it.
We want to collaborate from a single space, while here we can only sync data into Fibery, but again it is not visible for the community.
So far we’ll try to squeeze value from Discourse, but in the meantime we are thinking how to replace it with Fibery.
This is exciting to see Michael, and I echo Matt’s appreciation of your commitment, consideration, and patience. Software development and community management are both imperfect, messy things, and when you smash them together (as is necessary in a software tool community ), it can get even more so.
I think for now you need to keep them separate and use Fibery relations internally to associate public feature requests with internal features, product areas, etc. And I’m thinking about it and not actually sure how it could be otherwise.
Let’s say you have a perfect Fibery 2.0+ in the future that has the ideal permission model to show your “roadmap” to the public and let people add requests and vote on everything. 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? For example I would be willing to bet nobody would have ever put anything into “Fear management”, because what the heck is that? We in the forums know what it is because you’ve explained it many times here, but the average person wanting to make a feature request never would. I would bet there are plenty of other potential examples.
Of course you could just have all Feature Requests go into a single “uncategorized” type of place and then Fibery team manually moves it where they think it goes, that could work. It is not much different (in my view) from connecting Discourse topics with internal Fibery tracking, although it is a bit more complicated, less integrated, and not bi-directional as you say. But it seems that manual work is necessary to manage it in either case.
So some improvement could be made, but my point basically is that the issues you outline of Product Area, Idea, etc. complexity are not unique to Discourse and I’m not sure you’d want to map that model to Discourse nor fully expose it directly through Fibery even if you could.
This to me is super exciting because I honestly have not seen a really great product in this space! Productboard is surprisingly bad, in my view (no conversation, no participation between users, just isolated feature requests and a form of voting). 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. Public form view and submission, and some way to handle “public” (non-user) interactions for voting and comments, ways to create public-“sanitized” or appropriately limited views for e.g. public roadmap without exposing all internal discussion and details, etc.
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.
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
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.
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.
Oh yes, I agree. I just brought it up as an example of how that product/service space is not that well served yet (from what I’ve seen). Your mockup above looks quite promising vs. the existing options, especially given how it then integrates into the entire rest of the back-end dev/product management power and flexibility of Fibery. Can’t wait to have this available and be able to recommend it to other teams I work with!
So now that you use the Vote plugin, does Fibery import the vote count with the Discourse integration? I don’t have a plugin-enabled instance of Discourse to test this with at present, so I thought I’d ask. If not, it seems important to add!