Posted by David Lesieur on December 24, 2005 at 4:54am
Jump to:
| Project: | Drupal.org infrastructure |
| Component: | Drupal.org module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Currently, when one finds that an issue is already filed, if he wishes to raise the importance of the issue, he has to post a comment saying "+1"...
Maybe votes could be helpful when prioritizing tasks. This could be in the simple form "1 member <=> 1 vote". Bugzilla allows this.
Comments
#1
I have doubts regarding this voting idea, but by limiting the total number of votes allowed per user, each user would be able to vote only for his most important issues. If votes had such "cost", it could really mean something when an issue gets a lot of votes.
Maybe such mechanism could help sorting the high number of issues.
OpenOffice's Issue Tracker uses this, as explained here.
But I guess a motivated evil user could still create himself additional accounts to be able to put in more votes than allowed...
#2
still a good idea
#3
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
#4
Moving to the right queue. Also, see the (now duplicate) #218877: Provide a "Vote for your favorite" feature request for a little additional information.
#5
See the Project Issue Voting module.
#6
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.
#7
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.
#8
+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.
#9
#10
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.
#11
+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.
#12
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.
#13
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!
#14
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.
#15
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.
#16
It seems that is a better status for this report.
#17
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" ;)
#18
...allowing voting for uploaded files would help too. For example vote for patches offering different solutions or voting for UI mockups.
#19
@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.
#21
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.
#22
...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).
#23
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.
Yep.
But, that is much less likely to happen, that a comment totally changes in its meaning.
#24
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).
#25
- 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.
#26
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.
#27
This thread touches both voting on issues and voting on comments. The "voting on issues" part was mainly about bringing attention to issues that may be neglected by maintainers and contributors but that are important to users. If the issue lists were enhanced to show the number of followers in a sortable column, I guess that could be a useful tool. Without something like that, the only way for users to raise attention on an issue will be to add more comments (often just adding noise).
#28
#29
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.
#30
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.
#31
...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 ;)
#32
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.
#33
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) ;)
#34
I rely on having the ability to vote in d.o in my proposal here: #1308176: Battle plan for stopping spam/"subscribe"/"+1" comments (and cleaning up old ones from the db too).
...please let me know your thoughts and thanx in advance.
#35
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.