Voting for bugs (Was: Re: [Bug 20969])

[James McKenzie]

On 11/4/10 4:03 PM, Tom Spear wrote:
> On Wed, Nov 3, 2010 at 2:38 AM, Dmitry Timoshkov 
> <dmitry at codeweavers.com <mailto:dmitry at codeweavers.com>> wrote:
>
>     Yaron Shahrabani <sh.yaron at gmail.com <mailto:sh.yaron at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20101104/19d7115a/attachment.htm>