Tomos at Wikipedia wrote:
First, let me thank Eric for his effort on this.
Second, I am wondering if some further clarification might help.
Some are not necessary for this time, but nevertheless important
issues for the future multilingual voting. So I list them anyway.
(1) If we should be a registered user in meta in order to vote.
This should be essential, but we have no way of preventing people from
having multiple registrations.
(2) If we should vote in individual language-wiki.
(3) How to count votes of those who have multiple usernames
across multiple languages.
(4) If we need any weighing of votes by language - balancing
voices from less-populated wikis with populated wikis.
This will matter in some issues, but not all
(5) If we care preventing a username.
Probably not practical, and the banned users are likely to be so few as
not to have a statistically significant influence on the voting
(6) If we need some time to make translations of the
voting page
in multiple languages.
The importance of this will vary with the issue
The more I think about this kind of procedural
difficulties, the
more I feel uncomfortable relying on voting as a measure of
conflict resolution. Especially when the stake is high and
there is some serious disagreements, I suppose designing a
good voting system could be very difficult. We might need
some bureaucracy for it.
The usefulness of voting varies inversely to the importance of the
subject. There are numerous opinions on the matter of article count,
but nobody sees this as a core value for Wikipedia. A voting procedure
here helps us to choose between a number of reasonable alternatives,
that have not reached conflict level. Having Wikipedians vote for an
official stand on the Israel/Palestine conflict would be insane.
In applying Erik's proposal we are experimenting with trying to find
what works
And here is another issue. This one definitely needs
some
clarification, though it has nothing to do with multilinguality
of the issue.
With this type of voting, we may vote on each combination
of the options only when the number of options are small enough:
*size=20+; restrictions=stub flag+ comma; additional=frequency
by 50bytes.
*size=20+; restrictions=stub flag+ two paragraphs; additional=none.
*size=205+; restrictions=none; additional= A4 pages
and so on. Currently, we have:
4 options in size category,
4 options in further restrictions category (except for
no-restriction), and
5 options in additional stats category.
This already means 4 * (2^4) * (2^5) = 2048 combinations.
Well, so I guess we wouldn't like to do that.
This sort of problem is inevitable when the number of options is open-ended.
An alternative would be to vote separately on each
item,
disregarding the combination.
Weighted voting can help here, but I find that Erik's proposal to use 1
for the preferred option and 6 for a less interesting one to be backwards.
Then of course, there would be a risk of resulting in
a
combination that no one favored. (e.g. 250 bytes in size
and two-paragraphs as the further restriction turn out
to be the best of each category.)
That risk is always there
Another possibility that I can think of is
multi-staged
voting. We first vote on size. Then given the result,
we vote on further restrictions. Then with the size and
further restrictions in mind, we vote on additional stats.
I guess this would be a good way, except that it takes
more time to finish.
In these circumstances the purpose of the first ballot would be to
create a short list. With numerous options available, very few will
receive more than one or two votes. When the first ballot is finished
eliminate anything that did not receive more than 10% of the total vote,
or some other workable criterion.
Eclecticology