Re: Voting for bugs (Was: Re: [Bug 20969])
Tom Spear <speeddymon(a)gmail.com> wrote: [Message arranged in top to bottom posting order to comply with mailing list rules/guidelines]
On Tue, Nov 2, 2010 at 12:01 PM, <wine-bugs(a)winehq.org> wrote:
http://bugs.winehq.org/show_bug.cgi?id=20969
--- Comment #19 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2010-11-02 12:01:23 CDT --- (In reply to comment #18)
Those of you with this issue, make sure you vote for this in bugzilla so that it can be confirmed, if you haven't already.
Voting for bugs in Wine bugzilla is useless and does nothing except adding noise.
Can/should voting for bugs be disabled if it is 'useless and does nothing except adding noise'?
Thanks
Tom
Tom: Voting for bugs does two things, and I don't think Dmitry wants to do the first: 1. It confirms that a bug does exists and possibly on multiple platforms. 2. It advises developers that more than one system/configuration is affected by a bug. I agree that adding thousands of votes to a long standing bug is 'noise'. Given that we have a limited resource of developers, having users verify bugs and to vote for them to give an idea of how severe a bug is might be helpful. Just my .02 USD here. James McKenzie
On Tue, Nov 2, 2010 at 7:23 PM, James Mckenzie <jjmckenzie51(a)earthlink.net>wrote:
Tom Spear <speeddymon(a)gmail.com> wrote: [Message arranged in top to bottom posting order to comply with mailing list rules/guidelines]
On Tue, Nov 2, 2010 at 12:01 PM, <wine-bugs(a)winehq.org> wrote:
http://bugs.winehq.org/show_bug.cgi?id=20969
--- Comment #19 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2010-11-02 12:01:23 CDT --- (In reply to comment #18)
Those of you with this issue, make sure you vote for this in bugzilla so that it can be confirmed, if you haven't already.
Voting for bugs in Wine bugzilla is useless and does nothing except adding noise.
Can/should voting for bugs be disabled if it is 'useless and does nothing except adding noise'?
Thanks
Tom
Tom:
Voting for bugs does two things, and I don't think Dmitry wants to do the first:
1. It confirms that a bug does exists and possibly on multiple platforms. 2. It advises developers that more than one system/configuration is affected by a bug.
I agree that adding thousands of votes to a long standing bug is 'noise'. Given that we have a limited resource of developers, having users verify bugs and to vote for them to give an idea of how severe a bug is might be helpful.
Just my .02 USD here.
I think that voting for bugs is a great feature, otherwise there would have been many annoying comments like: it happens to me too and what info you can get out of it? Voting helps setting priorities for bugs without nonsense comments. This is my 7 Agorot...
James McKenzie
Yaron Shahrabani <sh.yaron(a)gmail.com> wrote:
I think that voting for bugs is a great feature, otherwise there would have been many annoying comments like: it happens to me too and what info you can get out of it?
Adding such a comment is pefectly acceptable. Confirming a bug and voting for it are two different things. Once a bug is confirmed its state changes from UNCONFORMED to NEW, and usually once sombody else bisides the reporter confirms a bug, a person with appropriate bugzilla rights sets bug state to NEW. But asking people to vote for a bug is a waste of effort, since that doesn't change anything. There are bugs in Wine bugzilla with huge amounts of votes on them, but that doesn't suddenly make a bug more important to developers for various reasons.
Voting helps setting priorities for bugs without nonsense comments.
That's the bug severity is for. -- Dmitry.
On Wed, Nov 3, 2010 at 2:38 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com>wrote:
Yaron Shahrabani <sh.yaron(a)gmail.com> wrote:
I think that voting for bugs is a great feature, otherwise there would have been many annoying comments like: it happens to me too and what info you can get out of it?
Adding such a comment is pefectly acceptable.
Confirming a bug and voting for it are two different things. Once a bug is confirmed its state changes from UNCONFORMED to NEW, and usually once sombody else bisides the reporter confirms a bug, a person with appropriate bugzilla rights sets bug state to NEW. But asking people to vote for a bug is a waste of effort, since that doesn't change anything. There are bugs in Wine bugzilla with huge amounts of votes on them, but that doesn't suddenly make a bug more important to developers for various reasons.
Voting helps setting priorities for bugs without nonsense comments.
That's the bug severity is for.
-- Dmitry.
My point in making the statement is that voting for the bug should confirm the bug once a certain threshold has been reached. People other than the reporter making a comment that a bug occurs for them too doesn't necessarily make the bug valid, and certainly doesn't change it's status. There are bugzilla installs for other projects, IIRC, that do change the status of bugs from UNCONFIRMED to NEW once there have been several votes, which helps the developers in terms of how much time they spend doing what they like (coding) vs doing maintenance (marking bugs as invalid). Being that the only way I can contribute to the project is by helping out in the bugzilla, since I have almost no programming experience, I was not certain that it was a valid bug since I cannot reproduce it using the reporter's exact same steps. So even though I have the ability to confirm bugs, I did not want to do so in case it was actually an INVALID.
From a user and testing perspective, I know that people like feeling as though they have some sort of control over the overall direction of a bug (and by extension, a project), and if they can, as a collective through voting, change the status, then it gives you guys a better idea of where priorities should be. Of course you are still free to decide to work on something that has low or no votes if you want to, but it's something that encourages more user participation in the project, without having to know how to program [1].
To give you an example of how I would like to see the voting system work (bugzilla should already be equipped to handle most, if not all, of this): Give every user 100 votes, of equal weight, which can be divided among their favorite bugs however they want. [2] Every user can remove their votes from a bug at any time to put them into a different bug. All bugs marked resolved have all votes removed automatically with the votes being refunded to the user that placed them on that bug. All bugs marked resolved, closed or REOPENED are made not votable until status is changed to something else. Make it so that each bug with votes keeps track of not only how many votes are given to each bug but also how many people have voted on each bug. Make the bug confirmation threshold based on how many people voted on the bug, not on how many votes are towards a bug, let's say 3 people voting confirms the bug, for this example. User A puts all of his votes toward bug 1 User B puts 80 votes toward bug 2 and 20 toward bug 1 Users C and D put 10 of their votes each toward bug 1 and 90 of their votes toward bug 3 Bug 1 has 140 votes, 4 people voted on it Bug 2 has 80 votes, 1 person voted on it Bug 3 has 180 votes, 2 people voted on it. Bug 1 should be confirmed but have a lower priority than bug 3 because more people voted on bug 1, but it is not ranked highest in terms of the number of votes. Bug 2 should get lowest priority, and since only 1 person voted on it, should not be confirmed until other bugs are solved. Bug 3 should get highest priority even though it is not confirmed, because it has the most votes. The initial work would of course go toward confirming the bug, after which it could then be worked on. </example> I will admit that there is one caveat, which could potentially be worked around pretty easily. The best example of the caveat is to say "let's assume that 100 users put all of their votes toward the DIB engine bug"... Well, for one, the fact that it has the most votes still doesn't require anyone to work on it, and for two, it should be possible to set certain bugs as not votable, (even if by resolving as LATER or WONTFIX, which IMHO the DIB engine bug should be resolved with LATER since it is a beast) Per the footnotes below, all of this could, IMO better the wine project from both the developer and user perspectives, and could potentially accelerate development as well as helping provide a better view of the overall implementation progress of various things I've seen being tracked on different pages such as the AppDB, Dan's red/yellow/green tracker that I've seen in years gone by (sorry Dan, I've forgotten the URL and the name you gave it), and the more recently started API progress tracker wiki (again, sorry to who is working on that since I can't remember what you called it). [1] Outside of bugzilla, someone can maintain a page that pulls the stats for each bug, on page load, to display how many -people- voted on each bug and how many votes each bug got, in a sortable and filterable list This page can be used to give new code contributors an idea of where to start It can also be used as a starting point for SoC discussions, wineconf, etc each year Since working on bugs by priority is not required (which would be difficult to do anyways), you developers are free to continue working on whatever you like working on. [2] The number 100 is an arbitrary number that I feel accurately represents the size of the wine project as a whole. Given that you have 1,000 people that vote on bugs, 100 votes per person is 100,000 votes total, so one person voting all of their points on something trivial means relatively nothing in the bigger scope, but say that 50 users put their votes together on a single bug to total 5,000 votes.. That's pretty impressive and says that that bug should be a higher priority than what it currently is. Tom
On Thu, 4 Nov 2010 18:03:38 -0500 Tom Spear <speeddymon(a)gmail.com> wrote:
My point in making the statement is that voting for the bug should confirm the bug once a certain threshold has been reached.
It already does. -- Rosanne DiMesio <dimesio(a)earthlink.net>
On 11/4/10 4:03 PM, Tom Spear wrote:
On Wed, Nov 3, 2010 at 2:38 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com <mailto:dmitry(a)codeweavers.com>> wrote:
Yaron Shahrabani <sh.yaron(a)gmail.com <mailto:sh.yaron(a)gmail.com>> wrote:
> I think that voting for bugs is a great feature, otherwise there would have > been many annoying comments like: it happens to me too and what info you can > get out of it?
Adding such a comment is pefectly acceptable.
Confirming a bug and voting for it are two different things. Once a bug is confirmed its state changes from UNCONFORMED to NEW, and usually once sombody else bisides the reporter confirms a bug, a person with appropriate bugzilla rights sets bug state to NEW. But asking people to vote for a bug is a waste of effort, since that doesn't change anything. There are bugs in Wine bugzilla with huge amounts of votes on them, but that doesn't suddenly make a bug more important to developers for various reasons.
> Voting helps setting priorities for bugs without nonsense comments.
That's the bug severity is for.
-- Dmitry.
My point in making the statement is that voting for the bug should confirm the bug once a certain threshold has been reached.
People other than the reporter making a comment that a bug occurs for them too doesn't necessarily make the bug valid, and certainly doesn't change it's status. There are bugzilla installs for other projects, IIRC, that do change the status of bugs from UNCONFIRMED to NEW once there have been several votes, which helps the developers in terms of how much time they spend doing what they like (coding) vs doing maintenance (marking bugs as invalid). Tom:
That already exists. I don't know the threshold of when a bug is moved from UNCONFIRMED to NEW, but it already exists. We already have pool voting but you are restricted to the number of votes per bug. My concern is that we get a bunch of 'me too' comments that have no other substance (like this happens when I do X but not if I do Y or see the dump file on Ubuntu Lucid when the bug was reported with a Fedora build) will start to happen. That is why the bug vote system exists. Yes, there are bugs with thousands of votes, but that just shows the scope of effect of a particular bug. It DOES not mean that the bug will be fixed faster or even a developer exists to fix it. Dmitry is correct in that the bug's priority is set by the development team and is not influenced by the number of votes. However, voting does give users input to which bug should be corrected, not that it will ever be. The reason that I pointed out bug 421 as one that has many votes, has a high priority, has been open for years, but still has not been fixed. This is the reality of life. There has been no developer, to date, that can build code that meets the standards of the Wine development team and successfully implements this function. This does not mean this will never happen. So for now, the vote system does what it is supposed to do and the priority system likewise. This is my additional .02 USD on the subject. James McKenzie
On Fri, Nov 5, 2010 at 4:02 AM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote:
Yes, there are bugs with thousands of votes, but that just shows the scope of effect of a particular bug.
I'm not sure where you got that idea: http://bugs.winehq.org/buglist.cgi?query_format=advanced&votes=100&order=vot... -- -Austin
On 11/4/10 9:22 PM, Austin English wrote:
On Fri, Nov 5, 2010 at 4:02 AM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote:
Yes, there are bugs with thousands of votes, but that just shows the scope of effect of a particular bug. I'm not sure where you got that idea: http://bugs.winehq.org/buglist.cgi?query_format=advanced&votes=100&order=vot...
Looked at the list and one of the bugs has over 150 votes and it was CLOSED DUPLICATE and the votes were not moved to the original bug. This is another shortcoming of using bug voting that exists or existed in Bugzilla. James McKenzie
On Sat, Nov 6, 2010 at 4:27 AM, James McKenzie <jjmckenzie51(a)earthlink.net>wrote:
On 11/4/10 9:22 PM, Austin English wrote:
On Fri, Nov 5, 2010 at 4:02 AM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote:
Yes, there are bugs with thousands of votes, but that just shows the scope of effect of a particular bug.
I'm not sure where you got that idea:
http://bugs.winehq.org/buglist.cgi?query_format=advanced&votes=100&order=vot...
Looked at the list and one of the bugs has over 150 votes and it was CLOSED DUPLICATE and the votes were not moved to the original bug. This is another shortcoming of using bug voting that exists or existed in Bugzilla.
I think Launchpad has the exact same issues but somehow in Ubuntu the voting is much more useful than in Bugzilla... One of the best ways to trace a common mistake in Ubuntu right after the release is to look at the votes, these issues usually get a lot og attention and they automatically get a higher priority...
James McKenzie
participants (6)
-
Austin English -
Dmitry Timoshkov -
James Mckenzie -
Rosanne DiMesio -
Tom Spear -
Yaron Shahrabani