Per Ned, I am forwarding this request. See above URL for reference, thanks
I'd vote for this one but I can't seem to find the "add vote for this bug" link/button... Oh wait! :-D
Overwhelming support seems to be in favor of enabling this feature.
The thread on -dev wasn't very specific on how this was going to be used. It was more of a "let's turn it on and figure out the rest later." How about, "let's figure out how we're going to use it, make sure the rest of the team agrees, and then turn it on." Consider this a WONTFIX for now, but I'll leave the bug open so folks can iron out the process.
I think the voting system is an important feedback from users, as they may find that what they were going to report is already there, but wish to emphasize the importance of the issue. look at KDE, they have voting enabled.
I don't think there needs to be a formal process for dealing with this. I would suggest turning it on, and just noticing the vote count when you peruse the bug list. A "view bugs with most votes" link would be useful, too. Look at the KDE bugzilla.
ok, I think its a nice idea. A pity that it has not been implemented. What can I do to get this implemented and get the bug fixed?
klieber: what about sending a message to gentoo-dev, and ask if there are any objections against it and then implement it? http://www.bugzilla.org/docs/2.14/html/programadmin.html#VOTING Explains how to enable it.
See comment #3
"let's figure out how we're going to use it," http://www.bugzilla.org/docs/2.14/html/programadmin.html#VOTING There is explained how to calculate the number of votes per bug and such. "make sure the rest of the team agrees," send a mail to dev: "I am going to enable voting in bugzilla, any objections?" "and then turn it on." I do not understand where your problem is, or what needs to be done?
It's been said before (and not just by me): give each user 20 votes, like on bugs.kde.org. It seems to work well for them. Frankly, I'm not sure the amount matters at all, since users can and usually do spend more than one vote per bug. If we set it too low (e.g., 3 votes per user), it might be a problem.
No... "let's figure out how we're going to use it," Meaning, so we turn voting on and folks start voting on bugs. Now what? This bug has 5 yes votes and 6 no votes. So what? What problem are we trying to solve here? How is this going to solve it? Is there another way to solve it? Earlier in the discussion on -dev, someone had said, "well, let's just turn it on and devs can choose to use them or ignore them as they please". That's not going to fly. If we turn this on, people are invariably going to turn it into a bludgeoning stick. "Didn't you see 10 whole people voted yes on this bug? FIX IT!!!" And there isn't going to be any clear process in place to define who and how the bludgeoning should be done. So basically, by enabling this, we're encouraging random bludgeoning of our users and devs. I'm not about to do that. Explain how it's going to be used. Get consensus (or at least a majority opinion) and then we'll talk. In other words, write a GLEP.
You're looking at this too literally. But the value of this has been stated in the -dev thread (repeated even) but you seem to ignore it. Maybe it because it isn't relevant to you. And that's fine -- but it clearly is relevant to other people. It doesn't have to be useful for you to be useful in the context of how other users and developers use Bugzilla. Simply stated, it gives users (and potentially devs, too) the ability to say, "please fix this bug before the others". We have the option to ignore it, just as the users have the option to vote or not vote. But I won't ignore it, and I know many other devs won't ignore a highly-voted bug. Users already complain about bugs that are important to them on -dev, I don't see voting changing that one bit -- except that there will be an actual number we can weigh one bug against others in terms of votes. Asking people to CC: themselves on every bug that's important (and deal with the mail traffic) is not an alternative to voting, sorry. Is there another way to solve it? Possibly, but it would require seperate software at the very least -- voting is an inherent and easy-to-enable feature in Bugzilla that other projects (like KDE) already use and see success with. If it becomes a "problem", it can be disabled just as easy as it was enabled. I really fail to see why you put up so much resistance to this. Nobody stopped and said, "What's this voting being used for?" when using the voting system on phpBB. There was no GLEP for that. In fact, almost all of the widely used .g.o site features have no GLEP associated with them -- why does this need one? Are you so put off by this that you're going to force it down the GLEP track? It's a simple and easily reversible change. It doesn't require a lot of effort to implement and doesn't affect any other aspect of our operations whether it succeeds or fails. It's opt-in; nobody is required to use it.
The voting system would also help to solve http://www.gentoo.org/proj/en/glep/glep-0017.html because we could then determine what ebuilds the users need most. There is a general agreement that we want voting, so why do you want us to write a GLEP? Its very easy to turn it on in the config, both users and developers want it. "So basically, by enabling this, we're encouraging random bludgeoning of our users and devs. " Is this bad? Do you know what is currently going on? Many bugs are just ignored by the devs. So this is something that we want to achieve. Better relations between users and developers. Get developers to work on their bugs to solve them. All this will get a boost when we enable voting. In fact we should tell the users, that they have not much chances that there (ebuild-)bug will get fixed if they do not email/talk directly to the developer. Or do you fear that users could get to much control? Please explain yourself
"Simply stated, it gives users (and potentially devs, too) the ability to say, "please fix this bug before the others". We have the option to ignore it, just as the users have the option to vote or not vote. But I won't ignore it, and I know many other devs won't ignore a highly-voted bug." That's the problem. You're offering this as a tool, but you're not establishing any sort of consensus (or even anything close to a majority) on how it's going to be used. So, users may vote for one specific bug, it gets fixed and their expectations are now set that voting helps to get bugs fixed. So, they go and vote for another bug and that developer chooses to ignore it. Now the users are pissed (even more than they were before) because they were led to believe that voting on a bug would help it get resolved more quickly. This isn't about me being put off by anything. This is about folks wanting to use a tool without any sort of instructions on how to go about it. My position is that, as you've currently proposed it, you're going to make things *worse* than they are now.
Closing; pointless to pursue when the main infra guy is not listening and will probably make sure it never happens.
So, if you don't have to do any work to make it happen, then it's worth implementing, but as soon as it gets to the point where you might have to expend a little effort, then you can't be bothered? Guess it wasn't that important to begin with.
Those statements don't logically follow. This was handled poorly Klieber.
1. We're at a point now where we can't enable a feature on a piece of software we already use without submitting a GLEP (read: red tape for something simple, just because it's not anything YOU want.) Food chain issue. So yes, for me, it's a little like pissing into the wind when someone in your position seems intent on blocking this. 2. GLEPs are really meant for large changes that affect everyone, require significant implementation effort, and have widespread effect/consequences. This feature is opt-in (nobody is required to use it) and can be reversed as easily as it was enabled. Does that really sound like a GLEP issue to you? I remember when Gentoo wouldn't get bogged down in bureaucracy for small enhancements; we just made it happen. If it didn't work out, we got rid of it. Now every little administrative minutae is a big stinking deal. The noise generated by this change, mostly on your part and Cianrm's, is inversely proportionate to the complexity of the change. That's the bottom line.
I'll try to explain this one more time and then I'll write it off as a failure to communicate. "2. GLEPs are really meant for large changes that affect everyone, require significant implementation effort, and have widespread effect/consequences. This feature is opt-in (nobody is required to use it) and can be reversed as easily as it was enabled. Does that really sound like a GLEP issue to you?" You are potentially telling our user community that they can now use voting to show what bugs are or are not important to them. For right or wrong, this sets their expectation that, if they use this new voting feature, their opinions will be duly noted and acted upon. This won't be the case unless you also get the devs to agree (or get policy changed so the devs have to agree) As a good example, let's look at metadata.xml files. It's been 2(?) years since we put those in place and there are STILL packages that don't have them. Consequently, they cannot be relied upon which causes even more confusion and grumblings. (see robbat2's post on -core yesterday for one example of this) If this means I'm handling things poorly or creating red tape where there wasn't before, then I guess I'm guilty as charged. However, I'm not going to turn a feature on willy-nilly and see what might happen as a result. --kurt
"You are potentially telling our user community that they can now use voting to show what bugs are or are not important to them. For right or wrong, this sets their expectation that, if they use this new voting feature, their opinions will be duly noted and acted upon. This won't be the case unless you also get the devs to agree (or get policy changed so the devs have to agree)" I assume we have still a chance, to get you to implement it. Your Prolem is that users could expect something, so how is your way to tell them different? Is it telling the users that it will be enabled and they cannot expect devs to note votes or act upon them? Maybe in gwn? Or how should we tell this the user?
I don't think user education is the right way to go about this. If we're going to start using bugzilla voting, then we should use it across the project, meaning we should all adhere to whatever policy and process we put in place with respect to it. I am not and have never been opposed to using the voting feature of bugzilla. I think that, used properly, it can create a valuable way for users to communicate with developers in a concise fashion. I *am* opposed to the idea that we should simply turn the feature on and have its usage spread organically, figuring out things as we go. I believe that will cause more problems than it fixes and create more confusion for our users and developers both. I'm not willing to support that.
*** Bug 71744 has been marked as a duplicate of this bug. ***
I just want to say, as to the problem that voting could make users expect stuff, I think it should be considered in perspective. Gentoo is free software; if users expect that its creators have an obligation to fix certain bugs when they don't want to, then of course they are already greatly mistaken. But users who think like that already bug people about bugs; if voting is allowed, it might give them something extra to rant about, but it won't change their mind about the nature of free software. Remember that anyone is allowed to fix bugs. Regular users who are also programmers might actually want to be able to see which bugs are the most-hated, so they can do something about them if they feel like helping out Gentoo. This feature wouldn't necessarily be just for official developers, but for anyone who wants to help improve Gentoo. I agree with Kurt that in general, we should first make a plan rather than trying stuff and seeing what happens. In this situation, I'd suggest that the way voting "works" is that the voting info is there and people can do whatever they want with it, including ignore it if they want. Furthermore, I can't think of any other way it could possibly work; surely developers can't be forced to work on bugs with the highest vote count, especially since they might be the ones that are practically impossible to fix. I don't know what a GLEP is or what manner of red tape or politics are involved but I'm pretty sure that this is what everyone means when they talk about votes. No user is going to honestly believe that if they're getting something for free the developers have an obligation to fix it, even if it has many votes. By the way, why is the bug marked CANTFIX? Wouldn't WONTFIX be more accurate?
