rating for feature requests
an option for if you agree that this is a high priority: a thumbs up or 1 to 5 rating. then a column showing the number of people who agree with the topic
Do you still have an unanswered question? Please log in first to post your question.
Comments
Why not. A quicker way to say that I like your idea. Perhaps just thumb up is enough?
It's not a bad idea, but open source isn't a democracy in the traditional sense. It doesn't matter how popular a feature request is if nobody is willing to step up and implement it (i.e. write the code for it).
The open source mantra is "Those that do, decide".
In reply to It's not a bad idea, but… by shoogle
While I agree that having this be done automatically / democratically is not necessarily that valuable, I do think this would be a valuable field to add to the issue tracker to be managed manually. It has the same value for bug reports too. It's different from severity - all crashes are "critical" in severity but some might be relatively low in priority because they are unlikely to be triggered very often. Separate severity and priority fields were a part of the first tracking systems I used back in the 80's, and I've always missed them here.
In reply to While I agree that having… by Marc Sabatella
What we can do is add a 'subscribe' button which is bascially a way to stay notified of updates on the issue. At the same time, the subscriber count could give an indication on how many people are 'following' or 'interested in' the issue. We can fairly easily experiment with this feature.
In reply to What we can do is add a … by Thomas
That'd go both ways though, thumb up and thumb down :-)
Still not a bad idea
In reply to What we can do is add a … by Thomas
Question. If I reply to a response and automatically get notifications of updates, am I automatically counted as subscribed? Another situation, I get no notifications from MuseScore.com or .org, I only look for what interests me. I don't want to subscribe and have my mailbox filled with things I'll look at if I want to any way. I don't know how many other people do this. I agree with the idea of a like and don't like button for user feedback to help with prioritization.
In reply to Question. If I automatically… by mike320
If you reply, you're automagically subscribed. You can manually (un)subscribe too. Subscribed means getting emails.
In reply to If you reply, you're… by Jojo-Schmitz
So if I don't get any notifications I will never be counted as subscribed?
One more concern if this feature is to even be added. If you hide it under the 3 dots people will not subscribe. They don't understand the dots and don't use them to edit their posts already. Using the dots will be a waste of time.
In reply to So if I don't get any… by mike320
They would probably use the dots if the subscriber count was made visible. At the moment there is no reason for them to go looking for a "subscribe" option, unless they already know it is there.
I think it is better without that "easy" option.
If you support something, say so, and add your experience. That is a much richer approach.
but it would seem that if a contributor noticed that 5 million users wanted a feature, that might be a direction to work towards. reading 5 million text commentaries will not likely interest very many contributors as they are too busy contributing.
The important question is What problem do we try to solve by this topic?
Could you please give the details about the reason of your proposals? I see the fundamental reason here is that a lot of feature requests are in the heap of less valuable issues in the tracker. So that, we need to solve another issue - how to make the tracker more suitable for contributors needs?
All these ratings and followers are fun, but again, why? :)
In reply to The important question is… by Anatoly-os
To me the main value is simple: development resources are limited, and when a developer or potential developer has some time to turn to finding issues to address - whether feature requests or bug reports - it would be fantastic to be able to get a prioritized list of the ones deemed most important. One could then scan the list for ones that look like a good fit for one's own interests and abilities. Experienced developers might have a pretty good read on this already, but not necessarily so for newcomers.
Another is to make sure important issues don't fall through the cracks.
In reply to To me the main value is… by Marc Sabatella
exactly!
In reply to To me the main value is… by Marc Sabatella
I'm absolutely agree with you, Marc. That's why I want to organize the tracker. I want to introduce epics by topics and actual priority for the issues. So that, developers would pick the most critical issues if they want or the most important feature request as well. Also, providing description/instructions of how the tracker is organized and placing them in get started guide would be great. It fully addresses your concern.
There are two questions. First one is how to help developers who are interested in particular topic? Simple, they can use search by keywords and find related issues/requests. Second one is how to define the priority? This is the most complex one for me. In a corporation, I would define the priority as a product manager, so that the most valuable issues be the first. Open source product is not led by business needs, so prioritization is not clear for me.
In reply to I'm absolutely agree with… by Anatoly-os
After some meditation, I've understood the main priority, which is fundamental. The priority is 3.0. All the bugs/issues/features related to this version ought to be addressed to the everyone who wants to contribute.
Looking further, the second priority may be developing topics related to some particular big feature like a virtual singer or VST support and concentrating on this one. One more priority is covering full notation capabilities for some particular instrument and concentrating on it.
FYI, I've summarized more than 80 issues related to MusicXML import/export. Good place to concentrate on.
Waiting for comments from lasconic!
In reply to To me the main value is… by Marc Sabatella
Well spoken!
Or should I say: +1 ?
Or maybe: 👍
I agree with the above points by @Marc and others that a rating system is good for the (rare) occasion when a developer sits down at their computer and thinks "Well I've got some free time, what shall I do? I know, I'll fix a bug in MuseScore! There aren't any bugs bothering me at the moment, so I'll go and have a look at what's bothering other people." That does happen occasionally (particularly around this time of year when prospective Google Summer of Code students are looking to make a good impression), but it is extremely rare.
Still, a rating system might be valuable even for those rare cases, but then the question becomes how to implement it without:
Giving the impression that "voting" for a bug actually means it will be fixed.
Starting arguments over the order in which bugs get fixed.
People abusing the voting system.
Developers not fixing bugs precisely because they are popular!
Now those are just reasons why a rating system might not be a good idea; I'm not against experimenting to see what actually happens in practice. @Thomas' suggestion of a subscriber count seems like a good compromise to me, just as long as everybody understands that volunteer contributors can still spend their time fixing whatever they want to fix; prioritising issues by "popularity" is just a suggestion.
In reply to I agree with the above… by shoogle
For me the case you mentioned is not rare at all. Happens a lot for the weeks / months leading to a release. Right now we rely on an adhoc "hit list" that I got very tired of maintaining for 2.0 and the first few point releases after that. A priority system would have helped immensely - it would have saved me hours of work, and led to more than a few bugs not slipping through the cracks.
But I agree, voting is not the way to implement it.
In reply to For me the case you… by Marc Sabatella
I don't think you're a representative example @Mark ;)
I also don't think the priority system you need is the same as a popularity system, or to put it another way, your priorities as a developer and as an experienced user are different to the priorities of the average user. Around release-time Developers are mainly interested in "showstopper" issues, and deciding whether issues are suitable for the current release type (major/minor/patch) or should be deferred to the next bigger release. Users are (generally) more interested in cosmetic issues like the quality of the SoundFont, or fantastical feature requests like Google-docs style collaboration or OMR.
A popularity system is probably only really useful for the core team to look back at long-standing issues that are highly popular, but no progress has been made due to a lack of specialist knowledge required to implement them. This is where the core team can decide to step in and make something happen, as was done with the SoundFont.
No doubt the core team already have a good idea of which long-standing issues have the most interest.
In reply to I don't think you're a… by shoogle
I might not be representative, but I do think that as the number of contributors grows and new people start taking on more responsibility, the value of what I am suggesting increases.
And yes, again, absolutely, I am not talking about user-driven "popularity" - I am specifically talking about developer-driven "priority".
In reply to I agree with the above… by shoogle
But most if not all of those things happening would be a symptom of a severly broken comunity - and then the like/importance rating would be the least problem to fix.
And if this really turns out to be a problem it can easily be solved by a per-user "credit" system. Give each user n "rating coins" per month. If an isssue/feature gets more than a certain amount of "coins", the price drops etc.
In reply to But most if not all of those… by rmattes
We already do see this in the issue tracker, with users "upgrading" the severity from "minor" to "major" for the issues they care about. (Perhaps the severities should be more category based: "crash", "corruption", "unexpected behaviour", "cosmetic".)
I don't see how a coin system would help any of those problems, and it would create a new problem; the more effort you put into designing such a system the more users are going to think that their votes actually have a meaning. If all we want to do it give an indication of which issues people care most about, then the simpler the solution is the better. We mustn't give the impression that voting for a solution will actually get it fixed.
In reply to I don't see how a coin… by shoogle
With all due respect, this thread seems like a distraction (to me, at any rate). The initial post suggested that the developers would benefit from this. As far as I can tell, the developers who have spoken to this issue basically do not support it.
As I said in an earlier post, I think it is important to have particular, considered feedback rather than an easy way to post an opinion, with no reasoning or use case.
Best regards,
Please, see my ideas https://musescore.org/en/node/270810