[Wikipedia-l] Article count: Vote result

[Erik Moeller]

Hi,

we have a winner. Because we did everything manually, vote counting has been
a bit of work, but now it's done and even with minor errors, the results are
fairly clear. The new article count system is going to be based on two
factors:

1) An article is counted if, trimmed of all trailing whitespace (blanks,
newlines etc.), it is longer than zero bytes (non-empty) AND
2) it contains at least one link.

Redirects, talk pages, user pages and Wikipedia: pages are not counted.

The vote consisted of two parts, the main vote on article size and a vote on
further restrictions.

The results for the main vote were, ranked lowest (better) first:

1) zero bytes:
   39 votes, averaging 3.1795
2) 100 bytes:
   37 votes, averaging 3.4595
3) 20 bytes:
   38 votes, averaging 3.8158
4) 250 bytes:
   37 votes, averaging 4.027
5) 5 bytes:
   36 votes, averaging 4.4167
6) language-dependent:
   33 votes, averaging 4.5758
7) 500 bytes:
   37 votes, averaging 4.7027
8) dynamic (e.g. depending on stub size):
   35 votes, averaging 5.1142

The votes for further restrictions, of which only one is to be picked, were:

1) at least one link:
   36 votes, averaging 3.1667
2) independent system for each wikipedia:
   31 votes, averaging 4.4516
3) stub flag (stubs excluded from count):
   34 votes, averaging 4.5882
4) minimum number of contributors:
   35 votes, averaging 4.6857
5) language-dependent punctuation (comma etc):
   36 votes, averaging 4.7778
6) two paragraphs minimum:
   33 votes, averaging 5
7) <article> tag
   33 votes, averaging 5.1515
8) no further restriction
   32 votes, averaging 5.1875
   minimum number of edits
   32 votes, averaging 5.1875
9) divide database size by byte size:
   30 votes, averaging 5.4333
10) existing comma requirement
   38 votes, averaging 5.5789

I have done my best to avoid errors, and for the first stage have compared
with Tomos' count, but I cannot be certain. While an error is unlikely to
affect the result, pedants may want to doublecheck just in case. Please note
that votes added after yesterday's deadline should not be counted. I also
did not count the anonymous vote (6 against dynamic).

Analysis of results
===================

The opinion regarding the main size restriction can be divided into two camps:
One group thought simply counting non-blank articles would be enough, the
other felt that excluding very short articles would also be necessary.
Consensus between these two groups was unlikely. The non-blank camp won by a
relatively narrow margin, but those who wanted more restrictions got an
important victory in the second stage of the vote: Only articles including
at least one link are counted, which excludes most newbie experiments.

This, in my opinion, is an almost perfect result that everyone should be
able to live with. It demonstrates well that voting systems can arrive at
compromises not just as well, but even better than simple discussions. How
long would we have needed to talk to agree on this solution and to determine
agreement? My guess is that we would not have arrived at it, ever.

But it is a good solution. There can simply be no valid article in the
Wikipedia system without links -- the whole wiki concept depends on high
interconnectedness. Material copied from somewhere else is not "wikified",
however -- nor are newbie experiments. Such "articles" are now
excluded from the count, as they should be. At the same time, we do not
choose an arbitrary byte size limit that would always remain arguable.
And I do not foresee users adding <!--[[]]--> HTML comments to an
article just to have it counted, as has happened with the comma.

Yet, even with this solution, there are people who feel strongly
that it is a bad one: 8 people have voted that counting only
articles with at least one link is a "very bad" idea (11 people thought
it is a very good idea). Once again, it is unlikely that there would
have been consensus between these groups, further disproving the
consensus model. With groups of 30 and more people, there is simply
never going to be "near unanimous consensus" about anything but the
most obvious questions.

But some results came as no surprise: Keeping the comma count was almost
universally rejected, and it is debatable whether we should have included
that option in the first place. Second place in the restrictions stage, with
considerable distance, was the option to let each Wikipedia decide on its
own. While this option clearly lost, its rank highlights that many
Wikipedians want "their" Wikipedia to have room for independent decisions. A
similar option should thus be included in future polls.

Finally, I would like to point out that the process has led to a remarkable
number of ideas -- some of them awful, sure, but some of them, like the link
idea, have never been mentioned on the mailing list. This, too, demonstrates
the advantages of a formalized brainstorming process.

Analysis of methodology
=======================

What have we learned from the process we used here?

1) The participation rate was very high. Concerns that an option might win
because of neglect were unjustified. HOWEVER, options which were added too
late tended to gather significantly fewer votes. Options which were
apparently written off as unlikely to win also tended to gather fewer votes.

2) Votes tended toward the extremes, i.e. 6 or 1. For most options, however,
the entire spectrum was used.

3) The system used therefore allowed us to gather a very large amount of
information about the opinions held. It would be difficult, if not
impossible, to gather as much information through a non-formalized process.

4) Deadlines and limits on options must be even more strictly enforced. The
deadline for proposing options should be longer, but options should be
discussed more carefully.

5) The combination of options and the possible requirement to split up voting
into stages need to be discussed to avoid ambiguity (e.g. "can more than one
option win?").

6) The voting system used takes some effort to handle manually, but would be
relatively easy to implement in code. Until we have such a software-based
solution, using this system would probably be overkill for small decisions.
In any case, we should try consensus finding first.

These are my thoughts for now -- please add yours.

Regards,

Erik