Help Maintainers Manage Issue Priority by Encouraging Voting

still a good idea

yeah, I've been thinking of this to. The notorious reasons for "spam" on the issue tracker are:

1) +1
2) Subscribing

Where a issue should have a subscribe button and +1/-1

Moving to the right queue. Also, see the (now duplicate) #218877: Provide a "Vote for your favorite" feature request for a little additional information.

Indeed, Project issue voting solves this need. However, I wouldn't quite call this "fixed", since there's now the question of deploying the functionality on d.o itself. That would introduce a dependence on VotingAPI, so that might be a source of contention. Also, I'm going to be AFK until Sept 1st, so I doubt this is going to happen before then (although perhaps hunmonk is interested in helping see this through). So, I'm moving this into the right queue for further discussion, to get approval of the new dependency, and to coordinate getting this live.

The issue has come up before, and it has indeed been a source of concern. In the past, Dries has said that he didn't want VotingAPI on d.o., as it would be another unacceptable dependency. Performance issues are also a concern. While the Drupal 6 version of VotingAPI has quite a few performance enhancements, the original API used in the D5 version tends to choke when huge numbers of votes are cast on huge numbers of items.

If we're talking D6, though, and Views is already part of the equation, I don't think there should be too much concern.

In the past, upgrading votingapi from one version of Drupal to the next has been cake; it's almost entirely "API" and thus doesn't require much refactoring unless real opportunities for enhancements are discovered. The D6 version was actually ready for testing only a month or two after the D6 beta came out.

+1

I feel the need to add "+1" along with some 'non spam'!

Dreamhost does this as well, for suggestions to add new features. Every user gets a set of "points" and each issue gets a number set 1-5 (depending on how hard it is to implement). Users can then "suggest" from a list set by Dreamhost. Seems to work rather well to find customer needs and requests.

I've posted a first review of the module at #328648: Module review, and have to disagree: issue voting can be handled independently from d.o redesign.

+1 for the original proposal to turn "+1" and "subscribing" into simple counters that will help prioritize issues. IMHO this is crucial for onward efficiency of the whole Drupal project.

I would prefer rating or highlighting of issue comments, to separate signal from noise and make it easier to read up on an issue.
#682254: Allow multi-dimensional rating of issue comments

Not saying that voting on issues would be a bad thing.

Any technique like this would be a big step forward.

Even flagging by the originator or something. If there was just a way to fiind out which patch was the one currently considered to be under discussion!

It would definitely be useful to have some sort of mechanism for voting on a useful answer - something like http://stackoverflow.com, in order to help when searching. I'm often frustrated when I search drupal.org, only to find a forum topic where someone is asking the same question without an answer.

I could be wrong, but isn't this feature already contemplated in Drupal.org redesign? Or at least it should be already planned to implement a way to find similar posts given a title.

It seems that won't fix is a better status for this report.

Now that we got #34496: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment fixed and rolled in d.o, we finally killed the "subscribe" comments. Now, lets kill "+1" comments too. Shall we?...

Adding a "+1" comment subscribes you to the issue, having the exact same effect as adding a "subscribe" comment. So, sometimes people use either "+1" or "subscribe" comments interchangeably to achieve the same thing. We need to clarify though that there is a distinct difference between these two types of comments, since for example one might want to subscribe, but in fact would "-1" instead of "+1". They even might want to simply subscribe out of interest, but they currently don't have an opinion on the matter at all. In other words, the number of subscribed people (we'll probably be calling them "followers" now) in an issue doesn't necessarily reflect consensus and it certainly is no means to make conclusions of "popular demand".

It might not make sense to allow voting for/against bug reports or support requests, but it sure as hell does for feature requests and perhaps tasks too. Besides, adding the Voting API to the list of modules used in d.o could help us take advantage of the voting ability to cover other areas too. So it would definitely prove helpful in the future.

How I imagine voting would help in general:

- It would help in decision making (instead of having to guess/argue over what route is best or most popular - like it's done currently).
- It would help track "most wanted" requested features (per project / for core / in general) and thus help project maintainers & coders focus on these.
- Allowing the community to vote for what they want to see implemented (and in what way), would give members the feeling of having more control of how things evolve. That would in turn make them more active in other ways (for example helping with testing and/or documentation).

Of topic (kinda): ...we could even have an annual -as in "all-year-long"- contest of most popular project(s) (allow voting for projects) and/or most popular member(s) (allow voting for users). The outcome of the contest would then be used to split the amount donated by people among winning projects and most active community members. That would motivate people even more. It would be a little something (other than plain "thank you"'s and "well done"'s) in return from the community for all their hard work. I know we already allow sponsorships for codding, but these won't be something coming from a single person or a company in the form of a payed job/contract thing. They would be more like Christmas/New Year/Hanukkah gifts from the whole of the community! If you don't like the idea of offering money, then think of collected votes by users as "credits" next to each member's name in the form of "thanked x times, by y people, for z issues" ;)

...allowing voting for uploaded files would help too. For example vote for patches offering different solutions or voting for UI mockups.

@klonos (#17),

The meaning of an issue can change over time.
In the past this was the issue title that would change, nowadays even the body ("issue summary") can change and evolve.

If you were "-1" about the initial proposal, you might be "+1" about the re-worded version, which now favours an alternative solution to the same problem.

Instead of voting on an issue, we should allow voting on "votable statements" within that issue, which are then supposed to remain stable over time.
Unless we invent something new for "votable statement", the only candidate is a comment. So we end up with comment voting.

The only thing where voting on the issue itself could make sense, is to determine priorities.
An issue with a high vote count is super important to be taken care of, but this says nothing about which solution should be preferred.

Good catch Andreas - never thought of it that way. The only way I could think around the problem you mention about the potential "rigging" of results by any future scope change(s) of an issue is the addition of a reset-of-votes feature after issue title/scope change (only certain people would have that permission). But then again that is way too intrusive and equally potentially apt to "rigging".

Anyways, I think we should allow voting of issues as a generic way to see if there is consensus in accepting the request (more "-1" than "+1" would of course lead to wontfixing it). If we had that implemented already, then Alberto wouldn't have closed this issue back in #16 only to see me come back to re-open it ;)

I do also agree with allowing voting on comments in order to fine-grain the initial "Yes, lets fix this" vote to "Fix it this/that way". Perhaps now that we have flag integration, we could use a special flag in order to mark certain comments as "proposals" and these comments could then be "votable" (is that even an actual word?).

Just a note/thought here: If these proposal-comments are not locked in some way, they too can be edited and that is again potentially risky of "rigging" too. So perhaps we should be keeping revisions of such proposal-comments too.

...title change to reflect latest discussion. Once we've given this enough thought, I'll even edit the summary because it deserves a proper one (complying to the Issue summary standards template).

Perhaps now that we have flag integration, we could use a special flag in order to mark certain comments as "proposals" and these comments could then be "votable" (is that even an actual word?).

I think this would be quite nice.
The simpler thing is to have just +1 on comments, as we already have on groups.drupal.org.

If these proposal-comments are not locked in some way, they too can be edited and that is again potentially risky of "rigging" too. So perhaps we should be keeping revisions of such proposal-comments too.

Yep.
But, that is much less likely to happen, that a comment totally changes in its meaning.

...that is much less likely to happen, that a comment totally changes in its meaning.

Yeah, I know. Just being the devil's advocate here, in order to emphasize on the fact that if people need to intentionally "rig" voting results, then they can find ways ;) ...thankfully, we are a community that its members aren't biased (...to that extent I mean).

- Preventing "subscribe" comments is a duplicate of #1303644: comment validation to prevent '+1 subscribe' comments

- Voting on comments has been discussed before for the "Follow" flag implementation and will not happen on drupal.org due to performance reasons.

Not quite so fast. ;) The specific implementation approach of flagging comments is won't fix for performance. But, we could perhaps use the same thing they've got on g.d.o for this. We don't *need* to do this via comment flagging. I think there's still value in continuing this discussion.

Yep, that's right, keeping say... a top 10/20/whatever list of most voted (thus most desired) open issues in an obvious place could help bring focus to them. This could be community-wide and/or per project. Hitting these "popular" issues fast(er) would give the sense of things actually getting done.

Should we not keep this separate?
#682254: Allow multi-dimensional rating of issue comments

"voting on issue priority" does not have the concerns mentioned in #19.
The proposed solution might change over time, but the priority tends to be more stable.

...one issue currently intensively discussed is #1302972: Decide on a specific set of libraries, extensions, and icons for BUEditor as used on drupal.org. People trying to figure which features should be enabled and which not. If we had this voting feature implemented, we could break each set of libraries/icons in its own separate proposal-comment and then each user could vote. It would be so much easier to decide. I mentioned that fact over there too ;)

I happen to agree with @dww on this one.

We can use the vote up/down widget like on groups.drupal.org but only for the original issue. Especially now since we have issue summaries, it would make sense to only vote on the issue and not really worry about the comments so much.

I guess the question is how do people feel about adding votingapi to d.o.

There's previous comments with some concerns, but if the vote up/down approach works for everyone, I would say lets set up a d.o sandbox and start working on that. (Sorry if thats not the correct path. I'm new to the Infrastructure queues) ;)

I rely on having the ability to vote in d.o in my proposal here: #1308176: [meta] Battle plan for stopping spam/"subscribe"/"+1"/"thank you" comments (and cleaning up old ones from the db too).

...please let me know your thoughts and thanx in advance.

I'd really like to see this happen asap. What's the next action item here? It sounds like we're all in agreement as to the general approach, and the importance of this issue.

+1 for this initiative ;-)

+1 from me as well. I'm thrilled to death with the follow button getting rid of useless "subscribe" posts bumping stuff up in my tracker but, as a maintainer, I know how it important it is to be able to get a feel for how common an issue is for use in prioritizing.

Michelle

Currently we do not even see how many people are following :(

If someone would like to work on this, http://drupal.org/node/1018084 has instructions on getting a d.o sandbox.

And that's how you get access. We'll I'm super interested in this issue as stated above. I just filled an issue over at #1460462: Review drupal.org development site for issue voting

As mention in #32 & #34 I'm going to the votingapi route. Assuming I get access.

Closing old issues. Please re-open if needed.

I think this is very much still a desired feature, although there hasn't been much activity on it lately.

...yes indeed, but on the other hand, a lot of issues were postponed till after d.o D7 launch.

Was under the impression that the "Follow" button would act as a defacto way to gauge community interest.

http://screencast.com/t/U5yz00lX8v1

Would like to see those numbers surfaced in the issue list que.

http://screencast.com/t/R6c28lvW

moving

Yes, this was long ago resolved with the follow button, and mostly the community has learned how to use the follow button and not use subscribe comments.

I am now unfollowing this issue.

Was under the impression that the "Follow" button would act as a defacto way to gauge community interest.

Following an issue just because one is interested to see what the outcome will be does not necessarily mean they +1ed it. Some of the issue followers agree with the idea while some might not. Some may even be neutral/undecided. So, we need a way to know how many are for the implementation compared to how many are against.

In general number_of_followers ≠ +1 and this feature request is pretty much still perfectly valid. What we need is something like Vote Up/Down:

PS: this is one of the few similar/related features I expect d.o to have some day soon. Others include:

- a "Top-10 most wanted features" block (leveraging the count from this feature request here) per project in each project's page.
- Drupal core's "Top-10 most wanted features" block exposed in the https://drupal.org/getting-involved page.
- a "This problem affects me too" link with along with a counter per issue.
- a "Top-10 most important bugs" block (leveraging the "This problem affects me too" counter).
- a "This helped me" (next to patches for example) link that would provide a counter for the tested by the community part of RTBC.

As I said #2186453-4: Survey Users Drupal Motivations & Interests I like how this could be useful to help maintainers prioritize issues that will benefit the greatest number of people.

I don't know that Follows are the best way to set priority. It indicates that you think you might be able to help and are interested in watching the progression. Might be a slightly different thing....

@rfay If we're going to be using Follows to judge priorities, then we need to be able to sort by that.

Yeah, I know that following might simply mean a remote interest, but that's something that we already have in place and perhaps could use sooner than another solution. If we are going for something more specialized though, it might be worth doing something like the "bug heat" over at Ubuntu/Launchpad:

...though I think that the points assigned for duplicate issues might be easily used to "compromise" the feature and so should not implemented. Anyways, it's the main idea I was aiming to put on the table.

Nice & transparent. Thanks for pointing that out!

Maybe we need a new issue item to track Drupal's Bug heat link!

I wish I could just tap a 'Like' button on comments and have the number of likes be counted in the Bug Heat Score.

Referenced in #2183843-3: Roadmap for a New Stable Release

EDIT: Also worth looking at Mozilla's example in their forums https://support.mozilla.org/en-US/questions/987714

Interesting view of why this works with the stack overflow community:

http://meta.stackoverflow.com/questions/56469/what-aspects-of-psychology...

The challenge is, would adding this random reward take away from the intrinsic value of participating in the issue queues?

Back from the Prairie Initiative, here are some ideas from the issue queue about the importance of voting:
http://www.disambiguity.com/prairie-initiative-kickoff/
https://disambiguity.notableapp.com/posts/960b8ce5781fb3cca2aadcec808f68...

Worth looking at https://www.youtube.com/watch?v=Yn7e0J9m6rE and probably buying the book.

Stack Overflow-like earning userpoints is definitely a way to go. I miss a feature to vote up/down a comment, and it would be great to combine drupal.org userpoints with IRC karma! It would instantly spice up the community with a juicy added value... senior (valuable) members could be distinguished instantly from noobs. It would be much easier for any valuable member to get a Drupal related job and that would be a great motive for anyone to contribute more, to provide a better quality of their contribution, so they could get ranked higher. I don't know why this feature is so underrated and why it takes so long to be included, but there is a huge potential and benefit for all of us. Therefore: +1 :)

If I could +1 your comment and tag you, I would, @jazzitup.

:-)

A related issue about let sort by followers in issue queues.

We added this issue to the DSWG spreadsheet to keep track of it as something we should consider next time we are evaluating ideas for prioritization.
This does not seem to be something that would be an immediate change to the roadmap https://www.drupal.org/roadmap
Removing the WG tag.