#2

Good point, I’m glad you raised it.

#3

The popularity of feature requests based on replies and likes is the same thing, no? Sort the Feature Requests section by Top.

Also, I can’t speak for the devs, but I don’t think they should value input of license holders any more than other users’ requests. Conformity to the app’s principles, value/innovation of the feature request, and popularity should be the driver of development decision-making… and I’m not convinced of the popularity one.

“If I had asked the people what they wanted, they would have asked for faster horses.”

3 Likes
#4

I agree with you on the licence bit.

Replies and likes are important, and create context, always important, but they are spread over a thread, sometimes very long ones.

Perhaps the way to do it would be to have some sort of summary at the top of the page to show the number of likes. There is a caveat: a like can be for the feature or for the comment someone makes. They would need to be kept separated. Whether that’s feasbile I don’t know.

1 Like
#5

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
#6

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 :slight_smile:

Therefore, a proper vote gets my vote.

1 Like
#7

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
#8

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
#9

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
#10

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.

9 Likes
#11

When you merge 2 similar feature requests, do you also transfer the number of likes at the top to the other request?

#12

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.

#13

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.

#14

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
#15

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
#16

I can see that being useful. Are you suggesting a change to the template text that now shows up with new threads?

#17

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

  1. 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

  1. 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.

  2. 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.

  3. A recently created/opened functionality.

3 Likes
#18

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
#19

Any official response from developers?
Otherwise discussion is pretty useless. :man_shrugging:t3:

#20

they read it, they usually don’t respond directly

#21

@WhiteNoise’s (Feature voting) and @ryanjamurphy’s response (Feature voting) 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