If you insert new fields from a custom view, do you mean that these fields are only available in / associated with that view?
Or are you actually just creating fields for the type itself?
The former sounds a bit like subtypes, which has been discusded elsewhere, with pros and cons of course
And I can’t help but wonder again how this conversation would be unnecessary if this board had some basic feature voting, or at least organization of features. As it gets older, requests are starting to proliferate that are the same.
As far as I can tell, here in the Fibery community the only hope to avoid duplication of requests is reliance on the Discourse native search: it will suggest that you are repeating a post as you type a new one, and you can search the forum for something you are about to post, and possibly Discourse will return the request if it’s already been made.
But as requests proliferate, repeat, and have unclear weight and visibility, I think the flaws of the reliance on Discourse’s search as a means to run a proper Feature Request Forum are becoming more evident. Compare this with the clarity you get with tools like Canny or UserVoice, which can do things like show trending, popular, recent, etc. requests. Not to mention some basic categorization of requests. I mean here in Fibery we have a category “Feature Requests” which has double the posts of the next biggest group - Bugs - and within the Feature Request category - zero subcategories! It is getting messy. On top of this, there is an unclear and inconsistent manual process that the Fibery team undertakes to edit posts with a status, further adding to confusion about how requests are really handled. At the very least they could publish an article defining what the statuses are, and what they mean, like Wrike does.
I, for one, am starting to lose steam when I come in here and see, more and more frequently, the same requests being made anew. And, the only thing tying them to the existing request is when good samaritans like yourself or @Chr1sG taking their own valuable time to try to merge or reference old requests. Other tools have staff that puts in time and monitors forums such as these to vet requests, merge, and communicate with posters about the existence of similar requests. The Fibery team does not do much of this. They respond here and there, but I have seen very little, if any, activity of them merging requests, or referencing similar ones to each other. I think hands down both you and myself have tons more posts in here than the combined Fibery team that link to repeated requests, try to bring similar request into one post, and so on. And ironically, we are actually leveraging some of the features of Discourse that that also make Fibery shine such as auto-linking, highlights, and others!
Fibery made the choice to use Discourse to track Feature Requests, and Discourse isn’t designed to do that. But since they made that decision, I expect more involvement here from Fibery directly to keep these repeated and concurrent discussions organized.
To that point, here is what Discourse is about:
On that page, you do not find the word “feedback” or “features” anywhere. Discourse is not designed to do what most of the people using the Fibery community - as evidenced by the huge disparity in post volume in the “Feature Request” category vs. all others - are trying to use this community for!
I really hope Fibery will rethink the way they publicly handle Feature Requests. Where would you rank Fibery in this regard among the tools in this list?
As a tool that is presenting itself as a Product Management and Feature Prioritization leader, I feel like Fibery needs to do this better than anything else in the market. Do you think that’s the case?
I don’t really feel like Discourse is non-functional for managing feedback, but I agree it needs more hands-on maintenance to work ideally. Canny and others arguably also need such maintenance to e.g. merge similar/duplicate feature requests, etc.
We both agree that the addition of a “vote up” plugin here would be nice, but that may be somewhat mitigated by Fibery’s own direct support of Discourse, depending on how the interactions here are ranked. I know you are frustrated by how opaque that is, and I don’t disagree that I’d like to understand it better. But ultimately I do have some trust in the team that they want to understand real usage and feedback as much as possible and they do a lot of deep thinking about development processes, prioritization, etc. (as evidenced by many articles in the blog), so I have to trust that they are choosing sensible approaches to incorporating feedback, even if I don’t know the details.
I also don’t mind contributing to organization and interlinking here, as time allows. And while I agree it is the company’s responsibility, I also know resources are tight for startups. Since I want Fibery to succeed, I am willing to trade some of my time and energy to try to help that in ways like this. Certainly it should not be an expectation on their part that anyone but them do so, but I don’t think it is. That said I also think they might benefit from empowering a few people here as mods, with thread merge capability, which might help keep things tidy. But I can understand them not wanting to do so.
Things are imperfect, no doubt. Improvements could be made, and hopefully some will in time. I tend to feel like there are some compromises that are difficult to avoid at this stage. And I’m still glad I’m here and not with Notion. Would I like to see ClickUp’s pace of development here? God yes. But they’ve been at it longer, have more funding, etc. And so far they haven’t actually introduced the functionality I need anyway, which are the powerful arbitrary Types and various kinds of relationships, among other things. So here we are, no better place to be for me, even with the frustrations.
Yes, it does work the search, but I think the use of it here in the way the team has structured its Discourse instance to track Feature Requests is in and of itself limiting. What I mean is the requests are organized the right way - distinctly in groups, or merged so we have less duplicate posts. Or, we could have something like guidelines from the Fibery team to limit your Request to just one feature, and if somebody comes in and lists a bunch in one thread, a mod would need to merge that to the relevant existing requests and delete it. This way, Discourse’s search can be used to its fullest.
The problem with the way this Fibery Discourse is set up is you don’t really have anything close I think to a Canny-type approach. I’d be curious how you think Discourse is functional at handling specifically Feature Requests, not general “feedback” which is what you mentioned above - although maybe you meant the same thing?
At this point here in the Fibery community, we have one mass of requests all organized in one category, growing by the day. There is an unclear way to see what is really being worked on. It’s up to the users to connect what’s here in Discourse, with the WIP’s published in Twitter, and more abstract discussions in the Blog, to figure out where their desired feature is on the list, like this one simple feature that remains to me a mystery as to whether we’ll ever get it:
I have been here over 1 1/2 years and still many, many key features remain unclear to me as to where they are in prioritization, or whether they will be done at all. I just don’t think these fragmented sources of info on what’s being developed in Fibery are easy to figure out, and overly helpful to paying users who are in pretty desperate need of some of the stuff that’s missing in Fibery.
I do agree as I just wrote that Discourse has great search, and in general it’s a market leading suite for managing communities. If Feature Requests were outside the realm of that scope, that would be one thing. But they are entwined here with all the other, more typical community areas like “Ask the Community” and “Share your App.” In fact, I continue to hope that Fibery will present a way to manage Feature Requests via Fibery directly, including a public-facing Feature Board, which is a key piece of Aha and ProductBoard that they are clearly going after. And then dogfood on that, leaving Discourse here as a true community piece.