No subject


Thu Aug 26 14:16:51 CDT 2010


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

--000e0cd6a9fc4e947f0494422c47
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Nov 3, 2010 at 2:38 AM, Dmitry Timoshkov=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:dmitry at codeweavers.com" target=3D"=
_blank">dmitry at codeweavers.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;">





<div>Yaron Shahrabani &lt;<a href=3D"mailto:sh.yaron at gmail.com" target=3D"_=
blank">sh.yaron at gmail.com</a>&gt; wrote:<br>
<br>
&gt; I think that voting for bugs is a great feature, otherwise there would=
 have<br>
&gt; been many annoying comments like: it happens to me too and what info y=
ou can<br>
&gt; get out of it?<br>
<br>
</div>Adding such a comment is pefectly acceptable.<br>
<br>
Confirming a bug and voting for it are two different things. Once a bug is<=
br>
confirmed its state changes from UNCONFORMED to NEW, and usually once sombo=
dy<br>
else bisides the reporter confirms a bug, a person with appropriate bugzill=
a<br>
rights sets bug state to NEW. But asking people to vote for a bug is a wast=
e<br>
of effort, since that doesn&#39;t change anything. There are bugs in Wine b=
ugzilla<br>
with huge amounts of votes on them, but that doesn&#39;t suddenly make a bu=
g more<br>
important to developers for various reasons.<br>
<div><br>
&gt; Voting helps setting priorities for bugs without nonsense comments.<br=
>
<br>
</div>That&#39;s the bug severity is for.<br>
<br>
--<br>
<font color=3D"#888888">Dmitry.<br>
<br>
<br>
</font></blockquote></div><br>My point in making the statement is that voti=
ng for the bug should confirm the bug once a certain threshold has been rea=
ched.<br><br>People other than the reporter making a comment that a bug occ=
urs for them too doesn&#39;t necessarily make the bug valid, and certainly =
doesn&#39;t change it&#39;s status.<br>

There are bugzilla installs for other projects, IIRC, that do change the st=
atus of bugs from UNCONFIRMED to NEW once there have been several votes, wh=
ich helps the developers in terms of how much time they spend doing what th=
ey like (coding) vs doing maintenance (marking bugs as invalid).<br>

<br>Being that the only way I can contribute to the project is by helping o=
ut in the bugzilla, since I have almost no programming experience, I was no=
t certain that it was a valid bug since I cannot reproduce it using the rep=
orter&#39;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.<br>

<br>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 vot=
ing, change the status, then it gives you guys a better idea of where prior=
ities should be. Of course you are still free to decide to work on somethin=
g that has low or no votes if you want to, but it&#39;s something that enco=
urages more user participation in the project, without having to know how t=
o program [1].<br>

<br>To give you an example of how I would like to see the voting system wor=
k (bugzilla should already be equipped to handle most, if not all, of this)=
:<br><br>Give every user 100 votes, of equal weight, which can be divided a=
mong their favorite bugs however they want. [2]<br>

Every user can remove their votes from a bug at any time to put them into a=
 different bug.<br>All bugs marked resolved have all votes removed automati=
cally with the votes being refunded to the user that placed them on that bu=
g.<br>

All bugs marked resolved, closed or REOPENED are made not votable until sta=
tus is changed to something else.<br>Make it so that each bug with votes ke=
eps track of not only how many votes are given to each bug but also how man=
y people have voted on each bug.<br>

Make the bug confirmation threshold based on how many people voted on the b=
ug, not on how many votes are towards a bug, let&#39;s say 3 people voting =
confirms the bug, for this example.<br><br>User A puts all of his votes tow=
ard bug 1<br>

User B puts 80 votes toward bug 2 and 20 toward bug 1<br>Users C and D put =
10 of their votes each toward bug 1 and 90 of their votes toward bug 3<br><=
br>Bug 1 has 140 votes, 4 people voted on it<br>Bug 2 has=C2=A0 80 votes,=
=C2=A0 1 person voted on it<br>

Bug 3 has 180 votes, 2 people voted on it.<br><br>Bug 1 should be confirmed=
 but have a lower priority than bug 3 because more people voted on bug 1, b=
ut it is not ranked highest in terms of the number of votes.<br>Bug 2 shoul=
d get lowest priority, and since only 1 person voted on it, should not be c=
onfirmed until other bugs are solved.<br>

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 confirmin=
g the bug, after which it could then be worked on.<br><br>&lt;/example&gt;<=
br>

<br>I will admit that there is one caveat, which could potentially be worke=
d around pretty easily. The best example of the caveat is to say &quot;let&=
#39;s assume that 100 users put all of their votes toward the DIB engine bu=
g&quot;... Well, for one, the fact that it has the most votes still doesn&#=
39;t require anyone to work on it, and for two, it should be possible to se=
t certain bugs as not votable, (even if by resolving as LATER or WONTFIX, w=
hich IMHO the DIB engine bug should be resolved with LATER since it is a be=
ast)<br>

<br>Per the footnotes below, all of this could, IMO better the wine project=
 from both the developer and user perspectives, and could potentially accel=
erate development as well as helping provide a better view of the overall i=
mplementation progress of various things I&#39;ve seen being tracked on dif=
ferent pages such as the AppDB, Dan&#39;s red/yellow/green tracker that I&#=
39;ve seen in years gone by (sorry Dan, I&#39;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&#39;t remember what you=
 called it).<br>

<br>[1]<br>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 eac=
h bug and how many votes each bug got, in a sortable and filterable list<br=
>

This page can be used to give new code contributors an idea of where to sta=
rt<br>It can also be used as a starting point for SoC discussions, wineconf=
, etc each year<br>Since working on bugs by priority is not required (which=
 would be difficult to do anyways), you developers are free to continue wor=
king on whatever you like working on.<br>

[2]<br>The number 100 is an arbitrary number that I feel accurately represe=
nts the size of the wine project as a whole. Given that you have 1,000 peop=
le that vote on bugs, 100 votes per person is 100,000 votes total, so one p=
erson voting all of their points on something trivial means relatively noth=
ing in the bigger scope, but say that 50 users put their votes together on =
a single bug to total 5,000 votes.. That&#39;s pretty impressive and says t=
hat that bug should be a higher priority than what it currently is.<br>

<br>Tom<br>

--000e0cd6a9fc4e947f0494422c47--



More information about the wine-devel mailing list