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