On Wed, Nov 3, 2010 at 2:38 AM, Dmitry Timoshkov <dmi...@codeweavers.com>wrote:
> Yaron Shahrabani <sh.ya...@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
