rating for feature requests

• 2018년 3월 25일 - 23:14

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


논평

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

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 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 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 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!

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:

  1. Giving the impression that "voting" for a bug actually means it will be fixed.

    • "500 people have voted for this bug and it still hasn't been fixed!"
  2. Starting arguments over the order in which bugs get fixed.

    • "Why did this bug get fixed? It's got way fewer votes than this other one!"
  3. People abusing the voting system.

    • downvoting all the bugs that don't matter to them.
    • creating extra MuseScore accounts to vote with.
  4. Developers not fixing bugs precisely because they are popular!

    • "Well if this bug is really popular then someone else is bound to fix it, so I needn't bother!"

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 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 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 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 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 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 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,

Do you still have an unanswered question? Please log in first to post your question.