I kinda agree with you, but I don’t think you’ll get much more nuanced rankings in a different voting service. If you look at the rankings for Top you get a pretty great picture of what the people want!
1 Like
To use likes and replies as the metric for popularity of a feature is flawed, because there is no way to gauge the weighting of that preference. e.g. if one user has given 3 feature requests a like each, one of those features may be a ‘semi-like’ another a ‘love’ and the final one the user would walk over the Sahara to have that included in the next release. But there is no way of knowing that from a simple like 
Therefore, a proper vote gets my vote.
1 Like
These issues of granularity in crowdsourced data are, as it happens, a core topic of my research. See my latest paper on the subject, “Designing for granularity in data crowdsourcing.”
Sad to say, but all data crowdsourcing platforms are fraught with design flaws that skew the takeaways you can draw from them. An instantiation of democratic decision-making via voting is one route, but what of brigading? How do you deal with the expertise a user is bringing to their feature requests? What of the feature requests that are poorly worded?
Discourse doesn’t save us from these issues. The point is that (a) no platform will really return high quality data and (b) interpreting feature requests is fuzzy anyway. The best quality insights for designers/developers will come from the nuances of discussion. Splitting into even more fora—especially ones that reduce the complexity of feature request discussions—would obliviate that nuance.
Once again, though, this forum is effectively the same thing as what’s being requested on this thread. Sort the Feature Requests category by Top and you get a view that shows the most popular feature requests. You’re not going to get a significantly different list on any other platform.
6 Likes
I don’t doubt that either the forum or a formal voting system could be used successfully. However, if the forum is used it needs to clear what influences new features and decisions (unless the devs prefer otherwise). Maybe I am not the normal case but I don’t like most initial feature requests because they are not thought through well. Only after discussion and sometimes contradicting opinions is it clear what specific implentation may be good. In some cases i would like/vote for a feature only as specifically suggested by someone. There are also a lot of duplicates, which one to like? The other issue is that nothing prevents me from liking every feature - presumably voting forces you to choose and prioritize. A voting system might also allow the devs to curate by time/resource investment - vote for one killer feature or ten meh features . So, speaking for myself, I prefer a vote system
2 Likes
As some have already mentioned, a proper voting system should only allow a certain number of votes that you can dispense. Those who bought a license could have some more votes to dispense, but that is debatable. My idea here was that these users are more probably those who care about the software and use it, and who actively support the developers, so they should have at least a little bit greater say. But developers should not be thought of as being obliged to implement what the license holders or the majority wants. If that would be the only measure, we would end up with another mass market product like OneNote or Evernote instead of an innovative, powerful tool for knowledge workers.
Another important point is that the list of features should be curated - duplicates should be closed or merged together, features that have already been implemented should be closed etc. This is a bit difficult when using forum discussions. Though I must say the discourse forum software used here is awesome - great choice. And I just noticed that merging forum posts is actually possible and already practiced here. So after all, maybe the forum is in fact sufficient. More important is that the forum/list is curated and maintained by somebody.
4 Likes
Hi everyone. Let me quickly chime in on this.
The current idea is to let you freely express yourself and we periodically plow through the forum and annotate what stands out AND makes sense to us.
While it is true that the feature request section is unorganized (with duplicates etc), it is still possible to distinguish the signal from the noise.
We still have a long list of things to do from the initial plan. We’ll add some of the signal to our backlog as we go.
We understand the value of the voting system as (1) it lets us know what features are important and highly requests and (2) it helps us prioritize. But we already get a pretty good idea from looking at the forum from time to time, and (2) isn’t really true, because software prioritization is a lot more nuanced than that.
We have recently added a placeholder text to the feature request topic creation. We suggest users to search and contribute to already open requests.
10 Likes
When you merge 2 similar feature requests, do you also transfer the number of likes at the top to the other request?
All data from a post is merged—we move the posts themselves.
Or do you mean we take the 2 votes on a repeat request’s thread OP and add them to the 24 on a previous thread? In that case, no—but I wouldn’t be surprised if Top sorting takes likes across the entire thread into account. Nonetheless, again, we don’t need not use a raw likes count to know what’s popular or what valuable feedback looks like. See @WhiteNoise’s commentary about regular review.
Can you implement some kind of voting pool to each question related to new features?
So you can get impression about what kind of feature is / will be popular among the core fan people of obsidian app.
We already had some discussion about this (see thread link below). I think the answer was that the forum is sufficient and the feature request template added info about this.
2 Likes
I was wondering from an academic perspective, should feature requests actually be a discussion of what the person would like to do and what hoops they have to jump through instead?
This is a sort of a problem I see where students will ask a question about say code, “is there a function that does xyz?” but when I ask what they’re trying to actually do it turns out they don’t need a function that at all, they need something completely different.
Similarly as users of software we might be asking for features which should be solutions to a specific problem. Instead we should be saying what we’re trying to accomplish?
1 Like
I can see that being useful. Are you suggesting a change to the template text that now shows up with new threads?
Oh haha I was just dumping thoughts (probably should be putting this in obsidian …) sort of along the ideas of “feature requests are solutions to potentially the wrong problems” but yeah something like
- what are you trying to do (and why) 2. what are you doing now and why is it annoying 3. what would you propose instead
For example: I want a recent/recently created functionality similar to starred
-
Locate/see recently created notes in one place because they’re ones that I’m actively working on. It can be difficult to find if I’ve stored them in different folders.
-
manually searching for them. it’s annoying because I have to store what they’re called in my memory and if the note isn’t fully formed, I may not have called it something useful. I don’t want to create a note of recent notes either for similar annoyance reasons of having to curate this. the recents opened in the opener is not enough generally.
-
A recently created/opened functionality.
3 Likes
This is frequently an issue when someone asks for a feature they liked in another program. The request is always for the feature as implemented in that program rather than an explanation of the need they want addressed.
1 Like
Any official response from developers?
Otherwise discussion is pretty useless. 
they read it, they usually don’t respond directly
@WhiteNoise’s (Feature voting - #10 by WhiteNoise) and @ryanjamurphy’s response (Feature voting - #7 by ryanjamurphy) pretty much summarized how we feel about this.
To reiterate, the data available on the forum right now is already useful in our prioritization, and I don’t see how an ordered list by exact number of votes would be more helpful. In our opinion, making a product is not simply churning out feature after another based on popularity. It’s way more nuanced than that.
Therefore, maintaining yet another system of voted issue tracker is not something we’ll invest into, on top of our forum and Discord server, both in terms of time and cost (solutions like UserVoice can cost $499/month or more).
Thanks for all the interest in helping Obsidian create a more organized list of feature requests! Really appreciate it.
4 Likes
I totally agree! There will be popular feature requests that do not align with Obsidian’s direction, and when those pile up, it would seem that the voting system is useless (“why haven’t the top 3 voted features been implemented?!”).
Great point, our amazing moderators are already doing that, and in addition to development we also try to spend time looking at the feature requests and merge them as needed.
2 Likes
Good point, reminds me of a post we did for Dynalist, “How to write good feature requests”:
Unfortunately, like with the help docs, few people actually go through the trouble to read it, so our Dynalist forum is still full of feature requests that tell us exactly what to do without explaining their use cases. We had to ask what their use cases are.
1 Like
Is that also the case with Obsidian?