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

[Nathaniel Catchpole]

Just to make it clear, I think voting with the restriction of one person N
votes is a good idea. I don't think prioritising issues by age is a good
idea at all.

Old issues are usually:
1.Not valid any more
2. Not interesting to many people
3. An absolute pig to fix requiring vast amounts of effort.

And I say this as someone who personally has gone through many hundreds of
old issues trying to sort the good from the bad in the past 18 months, not
just for core, but for views, cck, location and panels.

If you want to find old issues, you can look at any patch queue, and click
on the last link of the pager, and there they'll be.

If we have a sensible voting system, then some old issues will rise to the
top, we don't need an extra 'how old it is' weight to this.

For example, I personally don't care if user's can delete their old accounts
or not, nor do all that many people given the relative number of responses
vs. age for http://drupal.org/node/8 - an average of 14 posts per year.

Nat

On Tue, Nov 4, 2008 at 4:17 PM, Nathaniel Catchpole  wrote:

>
>
> On Tue, Nov 4, 2008 at 4:04 PM, Jakob Petsovits  wrote:
>
>>
>> One possible way to achieve that goal:
>> 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.
>>
>> Combined with age multipliers, I think this might make for a voting system
>> with a reasonable trade-off between popularity and necessity.
>>
>>
> This has been discussed elsewhere in the project metrics and redesign
> groups, and I think it's a good model to follow for this (and project
> reviews/voting if we introduce this later on).
>
> Nat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081104/351e321a/attachment.htm