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.
(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.
(5) If we care preventing a username.
(6) If we need some time to make translations of the voting page
in multiple languages.
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.
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.
An alternative would be to vote separately on each item,
disregarding the combination.
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.)
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.
Hope this helps,
Tomos
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
--Tomos--
>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.
--Ray Saintonge--
>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.
----
I noticed some of my explanations were not clear enough. Here is
an attempt to explain further about the last part, the multi-stage
voting. Not that I strongly advocate for this method, but it has
a merit, and I want to make it clear.
What I wanted to mean by multi-stage voting is this:
Stage 1:
We evaluate each of the suggested file-size items, from 1-6.
The item with the lowest average wins. That's the selected
thresold.
Stage 2:
We now evaluate each combination of the suggested items in
"further restrictions" category. Again, each voter gives a
number between 1-6 on each item.
If the thresold is decided to be 500 as the result of the stage 1,
then people would not give good rates on "comma," "stab flag," and
"two-paragraph." Because of the knowledge about the selected
thresold, we can avoid some strange combinations like "500 bytes
and a comma." That's the merit of multi-stage voting.
If there are five items proposed as further restrictions, we
would have 2^5 =32 combinations, including "none" and "all of them."
Again, the combination receiving the lowest average wins.
(I omit the explanation of why we use combination here, instead
of just each item.)
Stage 3:
We evaluate each combination of the suggested items on "additional stats".
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
Please folks, if you want to start a new thread, don't do so by replying to
a random message and deleting the previous subject and contents. When you
do this, the message still contains headers referencing which messages it
is a child of, and those of us with proper threading mail/news clients see
the mutant message in an existing thread on a totally different topic.
There has been a real rash of this in the past couple of days.
--
Richard Grevers
>MOnday afternoon GMT -- wikipedia seems awfully slow........
>I keep getting "connection refused" messages too :(
That is usual. I think it depends on your Internet
connection. I quite frequently get a time-out every day.
>I am sorry Takuya but I didnot understand what you
>meant there...
>Do you mean we should stop to try to set a common
>policy all together, and just all of us go our own
>way, with policy defined on each wiki separatly ? This
>could cause trouble in terms of software development
>if only.
Sorry. I see what I mean was not so clear. Some policities
such as NPOV are inalienable. We are buliding a sole
international, multilingual encyclopedia not the collection
of encyclopedias in different languges.
>Sure.
>We can also claim we don't have exactly the same goals
>as they were defined on the english wiki; we can claim
>we don't use the same means; we can claim the
>community doesnot function the same way. We can claim
>each wikipedia has a set of individual references. We
>may.
>But, still, we share common software, that requires
>common agreement on some points.
No, the goal should be the same, that is, building free
encylopedia, which is under GFDL and edited by everyone.
I have come to see some people fear allowing more automity
might undermine the coherence in the whole project of
wikipedia. I totally agree with that.
What I don't like is that it seems to me non-English edition
tends to replicate the English edition. Non-english editions
should not be translation version of English edition. Comma
is a good example that we simply applied English system to
Japanese edition. And worse, the problem remains unsolved
for long time. Something wrong. No?
Oh, I got. Maybe first we should write a conrete mission
statement writtin in every language we support. It should
not be a translation from mission statement in en wikipedia
but multilingual one. Or is there any already? Writing new
one should not be a snap because there is already a draft.
> Now there is you
>and Aoineko on the Japanese to speak up, we are quite
>a bunch from the french, germans and polish are quite
>present also; there's Elian and Giskart, and others...
Please don't include me. I rather write an article, which is
much more fun.
And there is almost none of Chinese, Korean and never talked
about Arabic and so on.
>You know...guy's stuff...car race...naked women (or
>men...no offense meant) ...football...beers...that's
>is not something I understand very well...;-)
Yeah, I understand while some don't care at all, some does
much. This is a personal preference rather than debatable
subject.
On Sunday 09 March 2003 04:00 am, Brion Vibber wrote:
> For months and months we've talked about revamping the article count
> system, but nothing's changed. The article count is still an extension
> of the "comma count" used to filter out empty articles in a search back
> in the UseMod days.
>
> Currently, a page is counted as an "article" for "we have X articles"
> purposes if it is:
> * in the article namespace (so excludes talk pages, user
> pages, Wikipedia: help and utility pages)
> * not a redirect
> * contains a comma (!)
This is true.
> Now, we are well aware that page-count fever has gripped Wikipedia for
> some time. The obsession with breaking the 100,000-page barrier on the
> English stifled any implementation of reforms for fear of reducing the
> count. Concerns about languages which don't use the ASCII comma
> character have been shrugged off. Well, today I've seen enough.
What? Why are you blaming the English Wikipedia for this? If anything *AT ALL*
people on en.wiki wanted a much more conservative count in order to put-off
hitting 100,000 articles. There was general agreement on that point. But the
agreement stopped there and different people had different ideas on just what
to do and no consensus emerged. I and several others wanted to have the
article count to only count pages in the article namespace that were more
than 500 bytes. However, if this were implemented now, it would reduce
en.wiki's count to below the 100,000 mark and most other wikis would have
their counts cut in half or worse though.
We could have a separate count that has the more conservative definition
(perhaps with a threshold that could be set per wiki). Call it
{{HEADLINEARTICLECOUNT}} maybe. But the {{NUMBEROFARTICLES}} count should be
the same for all wikis for comparison purposes (threshold=50 or 100 bytes
perhaps - or we could simply keep the comma count for {{NUMBEROFARTICLES}}).
I think this method would be able to satisfy the huge en.wiki that is mildly
embarrassed of its inflated count and many of the other wikis that are vying
for second place.
> While the English wiki has galumphed along for ages, secure in its place
> as The World's Largest Damn Wiki, the smaller languages are in intense
> (though friendly) competition with one another for runner-up positions.
> "In real life," Youssefsan tells me, "people look for economic growth;
> here for page growth. Both use 'creative accounting.'"
>
> On the francophone Wikipedia, we have been exposed as the slaves to the
> comma count that we all are but are ashamed to admit. See:
> http://fr.wikipedia.org/w/wiki.phtml?title=3DCULTe&action=3Dedit&oldid=3D33
>= 814
So you want to inflate the count then by removing the comma requirement? I
don't think that's such a good idea for en.wiki since it further weakens our
already weak article definition.
> (Those who have trouble with my PGP-signed mail, go to fr.wikipedia.org,
> look up article 'CULTe', and hit 'Modifier cette page'.)
>
> Yes that's right, people have started adding commas as hidden comments
> just to increase the stupid comma count. NO MORE, I say! Ils ne
> passeront pas!
That's not a good thing - esp for small articles. The whole point of the comma
count is to exclude small articles so adding commas in HTML comments is
cheating for any language that uses ASCII commas as often as English does.
Other languages don't use ASCII commas much if at all so the count is
worthless for them.
> Unless a better count system is proposed, I will replace the comma check
> with a greater-than-zero-size check within twelve hours.
And what about the people who get the digest after your 12 hour deadline? How
about the other people who only check or respond to Wikipedia posts during
the week? Shouldn't they have a say in this?
-- Daniel Mayer (aka mav)
WikiKarma
The usual at [[March 7]]
Thanks Brion for your proposal. I always appreciate that you take
non-English pedias like Japanese one seriously. But I have a slightly
different take on this issue.
1. threshold
Regarding the suggested article count, how about making it 50bytes and
greater instead of 0?
I know that either threshold is arbitrary, but I guess 50 is likely to be
better than 0.
2. English-centrism
It happened to be that Japanese wikipedia became quite active after English
wikipedia reached 10,000 - the achievement was reported in WiredNews, and it
was translated into WiredNews Japan. That brought a wave of new visitors,
some of them still active today.
So, even though the act of resisting any change in article count method
might be that of English-centrism of a kind, somehow Japanese wikipedia
benefited from it. It's good to realize that the English and non-English
sites do not always have zero-sum relation. (And it's good if others can
come up with some win-win type solution for other matters.)
3. Immediate implementation
In my personal opinion, (which could be very different from average or most
popular opinions of others in Japanese wikipedia), Japanese wikipedia does
not have an urgent need to change the article count.
Of course, the change itself is good.
The current system is quite useless for Japanese pages, (because Japanse
writing doesn't include that alphabetical comma much) and I rely on page
counts to understand the growth. It is somewhat inconvenient when it comes
to comparing Japanese one with others. The international statistics on
English wiki reports article counts only. I have to go to other sites
one-by-one, and see the page counts.
And I believe that Brion waited long enough for his part.
But it just happned to be that, in my personal opinion, Japanese wikipedians
are now in the process of forming basic policies and guidelines (naming
conventions, styles, etc. in Japanese language), as well as some
community-like ties among users. Article is growing, but registered users
are not very much, and most posting are from registered users and a few
specific IP-only users. That shouldn't continue very long, but for now, it
is not a bad thing to prepare infrastructure for the next slashdotting.
And anyway, the article count for the japanese 'pedia will not reach some
landmark figures like 5,000 or 10,000 for several weeks or so.
So, while I am thankful to Brion's declaration, I personally think that
Japanese wikipedians might be able to wait a bit if others want to stop him
for some good reasons.
(I'm not sure if anyone can stop Brion, though ;)
best,
Tomos
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
> I also installed the software and the complete
> German wikipedia (~26MB,
> no images, though) on an USB memory stick, so I can
> have it with me at
> all times ;-)
Uh oh. Don't tell me there's finally a good reason to
get a Palm Pilot! Um, that would work on a palm,
wouldn't it?
Chuck
=====
Learn Esperanto! - http://www.lernu.net/
Enciklopedio: http://eo.wikipedia.org/
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
I just set up a little README about my wikipedia offline reader (V0.1
alpha) at
http://meta.wikipedia.org/wiki/WINOR
I also installed the software and the complete German wikipedia (~26MB,
no images, though) on an USB memory stick, so I can have it with me at
all times ;-)
Magnus