92440 - Automatic vote spreading on dependencies

Status: RESOLVED DUPLICATE of bug 16153

(Bugzilla :: Bugzilla-General, enhancement)

Description

[xyzzy]

A vote for bug A, which is dependent on Bug B, is implicitly a vote for bug B as 
well.  It might be nice to allow a preference to "spread" this downstream vote 
across all bugs on which it depends.  This could help weight the upstream events 
correctly, especially when one bug blocks several high-vote dependencies.

The "spreading" need not be uniform, but that is an obvious first-choice...

See also bug 65801 (Pending/Weighted Votes) and bug 27553 (Resolved Bug 
Whining).

Comment 1

[Matthew Tuck [:CodeMachine]]

This was originally filed as bug 16153, but the problem is that it can easily be
abused my creating a tracking bug.

What we could do is to specify the number of votes on blocked bugs on the page
as a separate field, but not actually include that value in the query.

Or we could make votes a real number down to a few decimal places so we can
reasonably split votes.  If we do this we might allow people to split their
votes on a lone bug up like this too.  Dunno if that kind of goes against the
administrators max votes setting.  And indeed whether it would be worth the effort.

If we left it as real we could split up the vote and round down to the next
integer, but that would lead to a value of zero on most installations.  Or we
could keep it as real and add up the fractions between users, only rounding down
at the end, but this would make it hard to attribute specific numbers of votes
to individual users.

Comment 2

[xyzzy]

I can't believe 16153 slipped through the cracks...

I like the idea of seeing a blocked vote count.  The idea behind the spread 
votes was to do it automatically, not allow the user to deal with fractional 
votes.

If votes are counted to tenths, then it is just like being able to have 10 times 
as many votes, with limits of 10 votes per bug.  Not a good idea, IMHO, 
easier to petition for more votes, multi-vote capability.

Changing summary to avoid dup, and leaving open for more discussion.  Think 
there is some meat here, potentially.

Comment 3

[Matthew Tuck [:CodeMachine]]

My issue is that this wasn't going to have much effect on an installation like
mozilla.org, but I guess if a bug had 100 votes then the bugs that block it
could get a large number of bugs.

I don't think an uneven spread is something we should consider, as there's no
reliable way to determine which bugs should get the extra votes.

I guess we could do something like this:

Votes: 4 on this bug + 2 votes received from bugs blocked by this one = 6 (total
of 9 votes of bugs blocked on this one, split amongst this and other bugs)

This system certainly couldn't be abused by creating tracking bugs, but I'm
wondering if people could abuse this by creating fallacious dependencies to make
their vote go twice as far.

Maybe we could distribute the votes down, and say that any bug has an effective
vote count of 0 until the dependencies are fixed.

All this is very complicated to explain to the user though and I can see us
getting all manner of bug reports.

Comment 4

[Nathan Bidwell]

Another thing to consider is email notification when comments are added.  While
I personally would probably like all comments on dependant bugs, I doubt
everyone would.  (I think I'll file an RFE on this anyway, as I don't seem to
find any existing ones yet.)

Comment 5

[Nathan Bidwell]

My last comment was filed as bug 93957.

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

Moving to new product Bugzilla

Comment 7

[Knud Sørensen]

Bug 158140 is a better way to weight the upstream events 
correctly

Comment 8

[Bradley Baetz (:bbaetz)]

*** Bug 164529 has been marked as a duplicate of this bug. ***

Comment 9

[Dave Miller [:justdave]]

Reassigning all of my "future" targetted bugs to indicate that I'm not presently
working on them, and someone else could feel free to work on them.

Comment 10

[Dave Miller [:justdave]]

Reassigning all of my "future" targetted bugs to indicate that I'm not presently
working on them, and someone else could feel free to work on them. (sorry for
the spam if you got this twice, it didn't take right the first time)

Comment 11

[Jason Bassford]

I disagree with the actual premise of this bug.

> A vote for bug A, which is dependent on Bug B, is implicitly a
> vote for bug B as well.

Perhaps, perhaps not - certainly not in my case.  If I want a certain feature to
be implemented and I vote for it, but it's dependent on some other technical bug
- I almost certainly do NOT vote for the other bug.  In fact, looking at the
bugs I have voted for, and seeing their dependencies, I've never done so.

The number of votes you have are limited.  Why would I waste all of my mine to
vote on a single bug and all of it's dependencies (if it has a lot)?  This seems
completely redundant to me.  If a bug blocks another bug with a high number of
votes then, by implication, it's important that it be fixed - but I see no
reason why the bug that's blocking things should ALSO take everybody's votes -
let alone automatically.  (If I want to vote for dependencies I have the choice
of doing so myself - I would be really annoyed if Bugzilla simply assumed that I
want to and did it for me without asking.)

At best, the bug information page could have vote counts added to the dependency
fields - so that not only does it list the bugs in the dependency chain, but
also the number of votes being "blocked" by it, or depending on it.

Comment 12

[Zack]

Could Bugzilla just have something like:
Votes: 21 + 48
where 21 is the number of votes for the bug and 48 is the total number of votes
on all the bugs it blocks?

for example: If there are 11 votes for bug A, which blocks bugs B and C then if
bug B has 44 votes and bug C has 22 votes then for bug A it would say:
Votes: 11 + 66

This way, votes could be made for one bug and get noticed on bugs it depends on
while not having votes count for more than one bug nor using multiple votes for
one bug, unless the other bug is specifically voted for.

Comment 13

[Frédéric Buclin]

*** This bug has been marked as a duplicate of 16153 ***