I was contacted by someone at Linux Journal interested in mentioning
us. They were concerned about our performance and concerned about
"slashdotting" us, so to speak. I told them that we'll have all the
performance issues fixed soon, and suggested that I'd like to
volunteer to write an article about the project for LJ.
There's no firm response yet, but it seemed to be a favorably received
suggestion. This fellow said he would ask someone else what sort of
article might be wanted.
If they are interested, it might be good to have a couple of articles.
I could write about our history and culture and ideals, and someone
else could write an article about the software.
That second article, done properly, could be a great recruiting tool
for more developers. The LJ's subscribers would be a great place for
us to get development help.
Who would be interested in writing such an article?
(Note, I'm just raising the idea, there's no guarantee that they would
be interested.)
>It would help if you would read the arguments instead of
constantly
>repeating yourself.
Sorry for annoying you and the rest of everyone. I read the
arguments and I don't disagree with that. I think you
thought I didn't read your arugment because I didn't post a
mail arguing against your point.
Also, you have to notice that the fact is you believe wiki
might not help, and I believe it might. Then what do we do?.
Do I always have to convice you to try something new?
Consensus? Can we always reach the sole agreement?
Actually this is why I hate to partipate in the debate,
which is always endless and counterproductive. See Biography
standard in English wikipedia.
>> 1. The current meta-wiki is dead.
>
>No it is not. Look at the Recent Changes. If you are
missing something
>there, start a new page, hope that enough people (able to
speak the
>language you choose)are interrested in the topic, and see
what happens.
>Maybe announce it on one of the mailing lists.
Yes, and doesn't it mean chaning the policy of meta-wiki? I
am the one who advocates it. Meta-wikipedia can be better,
of course.
Actually both of I and you are right and wrong. This is the
exactly same discussion about some say usenet is dead, some
say no usenet has still good stuff and can have.
Saying meta-wikipedia is dead, I don't want to mean
dismissing the motivation of meta-wikipedia. I agree with
the idea that we need the place.
To make my arguments clear, I advocate proposals below.
1. Let's make discussion about policy in its native language
wikipedia. (What if there is no corresponding wikipedia? It
would be a problem. I don't know about such a case)
If a discussion takes place in the meta but it is not in
English, the problem is the same thing. Putting discussion
together really doesn't mean reflecting their voices.
2. Quit sourceforge. Objections?
3. Publishing wiki sourcecode in wiki and make it editable
just like wikipedia articles.
I don't know if this works but we can try. Probably the
first step is publishing "language.php"s and probably sysop
applies them.
>Yes, there is a lot of crap. If something really annoys
you, start a
>page [[Pages that should be deleted]] and explain it there
or ask on the
>talk page for deletion.
>
> The name meta.wikipedia sounds good to me. Where is the
problem?
Because if meta is the place for development and
administration, the name like admin, develop should make
more sense. Don't you think?
>> 3. Practically meta-wikipedia and maing lists segregate
the
>> majoriy of wikipedians from the decision-making.
>
>So everything should be discussed in the English Wikipedia:-
namespace?
No, no no at all. Discussion about the policy should occur
in the native language.
>The majority of users just aren't interrested in the
software
>developement and administration. Everybody who is can
subscribe to our
>lists and/or go to meta.
Probably. If meta is the place only for those who are
interested in development and administration, I would like
to participate in meta.
>> 3. Publishing wiki sourcecode in wiki and make it
editable
>> just like wikipedia articles.
>>
>> I don't know if this works but we can try.
>
>Source is fragile enough that I'd be very wary of this.
That, and I
>really do want a better editor than Mozilla when working
with code. ;)
>
>> Probably the
>> first step is publishing "language.php"s and probably
sysop
>> applies them.
>
>The current format of those files (a bunch of arrays and a
class
>definition in a PHP source file!) is horrible, arcane, and
very very
>fragile. (About half the updates I get submitted to me ends
up with a
>missing comma, an extra quotation mark, whatever, and hence
syntax
>error. And that includes the ones I make myself!)
>
>What we need is a human-friendly interface for editing the
messages,
>being able to compare all or selected language versions of
each one
>side-by-side. The ability to incrementally and safely
update 99% of this
>stuff without waiting for a developer's intervention will
be a big help
>for newer language sections being established.
I totally agree with that. Then why don't we employ wiki to
improve the sourcecode? Also, I don't know if it will work.
Then why don't we try?
>On Thu, Jan 30, 2003 at 09:38:36PM -0600, Takuya Murata
wrote:
>> 2. The meta-wikipedia is not multilingual at all and it
>> cannot be.
>>
>> I don't see any reason that the sole wiki site has
contents
>> written in several languages. Sure, technologically
>> speaking, meta-wiki is multilingual, but in practice, is
it
>> really? What if I started to post Japanese comments, who
>> will reply to them? If I did, I just only increase the
bunch
>> of mess. You can't discuss one theme in more than one
>> languages. That is for sure. The discussion
>>
>> So, there is no reason to have a multilingual wiki site,
>> hence there is no reason to separate English discussion
from
>> the English-edition wikipedia.
>
>[en]
>Because Japanese Wikipedia is small now and there aren't
many
>people who can understand Japanese here, it's not good idea
to use
>Japanese on meta. But there's nothing special about English,
>and any language understood by sufficient number of
Wikipedians is ok.
>And so will be Japanese in the future.
>
> ....
>
>(yes, i know that my japanese is no good)
No, it is good. I am impressed really. (Nihongo jyuzu desu
ne) Truely the linguistic diversity of wikipedia is great.
Anyway, I don't mean the discussion in non-English language
is meaningless, but I meant it doesn't make sense that the
same discussion conducted in more than one language unless
the participants are generally bilingual.
You may say Japanese speakers discuss in Japanese. Polish
speakers discuss in Polish (Polska?). But if discussions
occur in different language, why do we need to put them
together? The number doesn't matter.
Do you really believe debate in more than one lanugage makes
sense? UseNet, SlashDot, .... I don't see any successful
forum dedicated to discussion in more than one language.
SlashDot in Japanese is active, but it is seprated from
English SlashDot.
I have to reply this, though we should move this discussion
to wikipedia-l. It is because Brion, you got a wrong idea.
>Are you saying that discussion about the site should be
hidden away on a
>secret "hackers-only" wiki where people can't find it
instead of the
>open-to-everyone meta wiki?
1. The current meta-wiki is dead.
I certainly understand the initial motivation of meta-
wikipedia.org. We should talk about development, management,
or policy in the different place than English-edition
wikipedia or meta?? (It seems apparent that the site should
be renamed)
But what kind of contents are there? There is almost
anything but inproper in the main wikipedia. There are
haiku, september 11, ....
As the saying goes, bad eats good (Forgive me. I can't
remember phrase). Weird (at least to most of people) stuff ,
including non-English contents just makes meta-wikipedia
look anything but the place to conduct decent discussion.
What if I submited a Japanese essay? It is acceptable in the
current policy, but it aggregate the situation because no
one can review it.
As I said, if we decided to change the policy of meta-
wikipedia, I certain second it. But otherwise, meta-
wikipedia seems dead or going to be dead.
Buried on the English Wikipedia where
>people coming from other languages won't have a *clue* how
to find
>things, and people who don't speak English don't have a
chance of having
>their voices heard?
Oh, that is great! I can type even Japanese (I tried. See
SandBox)
Anyway,
2. The meta-wikipedia is not multilingual at all and it
cannot be.
I don't see any reason that the sole wiki site has contents
written in several languages. Sure, technologically
speaking, meta-wiki is multilingual, but in practice, is it
really? What if I started to post Japanese comments, who
will reply to them? If I did, I just only increase the bunch
of mess. You can't discuss one theme in more than one
languages. That is for sure. The discussion
So, there is no reason to have a multilingual wiki site,
hence there is no reason to separate English discussion from
the English-edition wikipedia.
3. Practically meta-wikipedia and maing lists segregate the
majoriy of wikipedians from the decision-making.
What is now happing is decision-making occurs in the place
that most of people don't see. The recent changes in English-
edition wikipedia is the critical place where most of people
notice even minor changes. In the reality, meta-wikipedia
practically separate people to express their voices.
You can speak, but only if you go to travel to Alaska. It is
not democratic. The discussion about the policies should
take place in where people are actually living.
>I say NO to that. Closing meta would be undemocratic,
bigoted, and wrong
>in every way.
Closing meta means nothing because meta means nothing.
>But if you mean "democratic" as in voting, then no, we
don't do that.
I didn't mean that. I don't believe in voting.
Actually I am not so sure about what is more democratic
system. I said the system of wikipedia should be more
democratic because it seems to me that the decision about
the wikipedia system doesn't reflect well the opinion among
the majority of wikipedians, if not totally. First, simply
really few people subscribe this mailing list. Second,
changes are somewhat invisible. Basically there is no
announcement about the changes. For example, new text for
new pages. (Forget the talk pages or Village pump. They
exist for conversation not for announcement)
I don't want to mean people who have access to CVS should
speak more (I am implying Brion). I am saying we should make
the management (including decision-making) more visible and
closer to oridanly wikipedians. Sure, now people dicuss in
Village pump or some send direct message to Brion personally
in his talk page. But it is not the democracy in the essence.
Wikipedia is great because not only it is free, open-content
but also because it is democratic. People made decision in
their own. People go where they want to go without
discussion. The important distinction is wikipedia is the
place where not the rulers listen to people's demands but
all of people rule.
Sorry I am just talking about something abstract. But this
is why I felt the management should be more democratic. And
again I don't know practical way. Developing wikipedia
system in wiki? I don't know.
Sure, it is usuall that the system of the site changes
suddenly. Think of amazon.com or google. They are not
democratic. But we can do better.
Oh, anyway, can we set up the wikipedia for developing? Like
hacker.wikipedia.org
I like to document more information about the wikipedia
software and also it would be nice if there is the place the
developers find the tasks wikipedias want and exchange
brainstorms. (Well, there is sourceforge. But no one is
using it anyway. Most of stuff in sourceforge seems outdated
like bug reports several months ago)
Again, I don't want to blame anyone. I just hope the system
of wikipedia is as good as the articles of wikipedia.
(Sorry pieter. I prefer hacker to developer. hehe)
>> Also, I was wondering where such a decision was made.
>
>The new Talk code was requested both on Village Pump and on
the mailing
>list repeatedly. The user page stuff was simply a side
effect of that.
I mean is there someone who made the final decision?
(probably one who has a right to submit a code to CVS) For
example, in Linux after all Linus decided to apply a patch
or not. Of course, he listen to people's opinion but he made
a decision.
>However, if you want to keep up with the latest changes and
possibly have
>some influence, check out the code and start hacking.
>
>http://meta.wikipedia.org/wiki/How_to_become_a_Wikipedia_hac
ker
Yeah, thanks. I don't think I can have influence though.
>Hi Taku,
>
>we *know* that the site is slow. And we *know* that it's
not because our
>server is too small. Our problems are database/lock
related, and putting
>stuff on an even bigger server will not help much when
dealing with O(n^x)
>problems. What we need to figure out is:
>
>- When are our tables/rows locked and why (this behavior
has changed
>drastically with the recent update to InnoDB).
>- When are our queries using indices and when are they not,
and why (MySQL
>index behavior can be very hard to predict).
>
>Solving these two problems should make Wikipedia very fast.
If we cannot
>optimize some queries, we need to think about making them
simpler, or
>caching them. (Also note that MySQL now supports
subqueries, which we
>don't use yet.) We are dealing with *particular* queries in
*particular*
>situations that make Wikipedia slow.
Oh, I see. But are you only talking about searching? I don't
think MySQL can be bottleneck of simple displaying pages.
Without simply extending server capacity, is it possible to
sustain the increase of traffic? (Fortunettely or
unfortunettley? the wikipedia seems still to grow.)
>Not practical. Too many queries require access to a single
centralized
>article database, even an index alone won't suffice. Think
of stuff like
>Most wanted, Orphaned pages etc. Besides, it won't make
things any faster
>because our problem is not a too small server.
I am not sure I understand you. Whatever algorithm is too
stupid, the increase of capacity always makes the site fast,
if not . Think of brute-force algorithm. I am not talking
about adding just 2 or 3 more servers but possibly hundereds
of servers. Maybe I am wrong because I am still not sure how
to implement my idea.
Surely we can't have the server that Google or Amazon has.
The strength of wikipedia is its democratic structure. Why
don't we employ it for hosting too?
Maybe my idea is not practical. Then can you tell me how so?
I am working on the replaceInternalLinks function, trying to improve
speed. Tracking the "does this article exist" mechanism, I ended up at
the preFill function in LinkCache.php, which reads all existing links
for a page in a single query, avoiding zillions of queries later.
Now my question: Is there a reason why it doesn't pre-fill the "bad
links" array as well? That would save some time on all pages with more
than one broken link, would it not?
Magnus