I thought about this too, and also came to the conclusion that inverse linear is not ideal. Furthermore, I would like to avoid fractional scores. A possibility that occurred to me was this: everyone has a 'budget' for favoring variants, and can choose to favor a variant multiple times. To favorite a variant N times would take N squared out of his budget, though. This should be enough to discourage excessively favoring a single variant.
E.g. if we set the budget to 128 (which is enough to accomodate the situation described in a posting lower down in this topic thread), people that would want to favor only a single variant could favor it 11 times; more typical people that favor 8 variants could assign each of those 4 times (giving the 'all on one' attempt not even 3 times as much weight), and less critical people who want to favor 127 would have to do with a single favor for each of those.
This would need enhancement of the interface to also allow users to favor variants multiple times, and 'unfavor' those they favored before, in order to make room for more favored variants. If we feel it is unnecessary for a user to distinguish between variants he favors, the current interface would suffice. But in reporting the score the votes of each user would be weighted by multiplying those with a number N, which is the largest integer that, squared and multiplied by the number of variants favored by the user would not exceed 128.
To implement the latter it would only be necessary to modify the script that prepares the overview page. I don't think we would need a new 'awards program' for that. We can even have this page show both numbers: the weighted sums, (on which the variants are then sorted), as well as the number of users that contributed to this total (as it does now).
The weighted totals could be calculated in two iterations: the first one would discard all self-voting. After that it would be calculated how many weighted votes each user received, and how many self-votes this would earn him. In the second iteration the self-votes of users that did not go 'over budget' in self-voting would be counted in the weighted total.
I thought about this too, and also came to the conclusion that inverse linear is not ideal. Furthermore, I would like to avoid fractional scores. A possibility that occurred to me was this: everyone has a 'budget' for favoring variants, and can choose to favor a variant multiple times. To favorite a variant N times would take N squared out of his budget, though. This should be enough to discourage excessively favoring a single variant.
E.g. if we set the budget to 128 (which is enough to accomodate the situation described in a posting lower down in this topic thread), people that would want to favor only a single variant could favor it 11 times; more typical people that favor 8 variants could assign each of those 4 times (giving the 'all on one' attempt not even 3 times as much weight), and less critical people who want to favor 127 would have to do with a single favor for each of those.
This would need enhancement of the interface to also allow users to favor variants multiple times, and 'unfavor' those they favored before, in order to make room for more favored variants. If we feel it is unnecessary for a user to distinguish between variants he favors, the current interface would suffice. But in reporting the score the votes of each user would be weighted by multiplying those with a number N, which is the largest integer that, squared and multiplied by the number of variants favored by the user would not exceed 128.
To implement the latter it would only be necessary to modify the script that prepares the overview page. I don't think we would need a new 'awards program' for that. We can even have this page show both numbers: the weighted sums, (on which the variants are then sorted), as well as the number of users that contributed to this total (as it does now).
The weighted totals could be calculated in two iterations: the first one would discard all self-voting. After that it would be calculated how many weighted votes each user received, and how many self-votes this would earn him. In the second iteration the self-votes of users that did not go 'over budget' in self-voting would be counted in the weighted total.