[development] Voting on issues (was Re: How to post bug reports andpatches)

[Tomas Fulopp]

I disagree with Derek, Nat (nothing personal, I am sure you know that) and
Bugzilla who prefer the limited vote number system. It introduces the need
for an arbitrary value (how many votes per person is fair?) and discussions
that would stem from it.
Simple accumulative voting on issues (+1 system, one per user per issue) is
a) simpler and therefore more elegant, and even more importantly:
b) people use it intuitively already - they add those cluttering
"Subscribing" messages because they have no other way of doing this. If
limited vote was applied, bumping the issue by saying "Subscribing" would
continue whenever one runs out of votes (even if such messages would not be
counted as votes).

Also, I think that old issues, even if they rise up due to accumulated votes
(or age) can still be easily dismissed if necessary - by saying they need to
be re-done against another version, etc, so I don't think that's a problem.

Important - if age is included somehow as discussed above, it should be age
since last comment in that thread. Means if somebody reacts in some way the
added weight based on time is re-set to zero, which is fair because the
patch contributors need to react on it. Otherwise even useless patches /
issues would keep rising in the queue, despite all critique.

Keep up the good ideas flowing, let's make the best system possible.




On Tue, Nov 4, 2008 at 5:51 PM, Derek Wright <drupal at dwwright.net> wrote:

>
> On Nov 4, 2008, at 8:04 AM, Jakob Petsovits wrote:
>
>  Bugzilla (at least in the version used on bugs.kde.org) grants each user
>> a
>> limited amount of votes for each project which the user can then assign as
>> desired. If the user doesn't have any votes left, she needs to take them
>> back
>> from unimportant issues and reassign these votes to the more pressing
>> ones.
>>
>
> That's exactly how project_issue_voting.module already works.
>
> Age modifiers seem like needless complication, and something that's bound
> to make whatever performance concerns we have about running this on d.o even
> worse.  Let's not over-complicate this problem to the point of making it
> infeasible to deploy...
>
> Cheers,
> -Derek (dww)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/58ffcbbb/attachment-0001.htm