[Wikipedia-l] Article count reform

[Ray Saintonge]

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

>