subject: [WikiEN-l] Expect a Miracle

body:
> From: "Poor, Edmund W" <Edmund.W.Poor at abc.com>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Fri, 27 Feb 2004 11:10:24 -0500
> To: "English Wikipedia" <wikien-l at Wikipedia.org>
> Subject: RE: [WikiEN-l] Plautus
>
> Okay, I thought about it.
>
> I'm unblocking Plautus, and I take full responsibility for him as a
> "parolee" per your terms below.
>
> Kind of like Frodo and Smeagol.
>
> Wish me luck.
>
> Uncle Ed
>
> -----Original Message-----
> From: wikien-l-bounces at Wikipedia.org
> [mailto:wikien-l-bounces at Wikipedia.org] On Behalf Of Erik Moeller
> Sent: Thursday, February 26, 2004 10:09 AM
> To: wikien-l at wikipedia.org
> Subject: Re: [WikiEN-l] Plautus
>
>
> Ed-
>
> you're probably right. Plautus is just a misguided individual. All this
>
> calling other users "dumb motherfuckers" and "fucking ignorant assholes"
>
> has to be expected from a confused newbie. After all you yourself once
> created a "Fucking asshole" account to make a point, remember?
>
> Surely it is acceptable to lose 10 devoted, creative Wikipedians if we
> can
> keep a single crackpot around. I should really stop being so judgmental
>
> and leave the important decisions to the people who got their priorities
>
> straight, instead of looking at silly things like polls and hard
> evidence.
>
> If Ed believes that an individual is reformable, then we need to all sit
>
> back and let the spirit of Sun Myung Moon work through him. I can't wait
>
> to see you do your magic, Ed!
>
> I have just one condition.
>
> If this whole thing blows in your face, I want you to take full
> responsibility for it. That means that I want you to go through every
> single page Plautus satire edited in the last few days, to take diffs of
>
> these edits and fix them if necessary. That includes erased comments on
>
> talk pages, something he is very fond of.
>
> How about it, Ed? Do you want the whole community to share your faith,
> or
> are you ready to fix things up if that faith turns out to be mistaken?
>
> Regards,
>
> Erik
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


list: wikien-l

source: pipermail-mbox

from_name: Ray Saintonge

subject: [WikiEN-l] Feminist agenda (was  Arbitration progress report #6)

body:
sannse wrote:

>Any woman out there want a job?  No pay, lots of hassle, but
>the potential for an occasional warm fuzzy feeling inside.
>
Motherhood!? :-)

Ec


list: wikipedia-l

from_name: Jimmy Wales

subject:
[Wikipedia-l] > 230 request/second - but no Wikipedia news on
	slashdot ; ) what is this?

body:
Robert Michel wrote:
> Am Donnerstag, 26. Februar 2004 19:00 schrieb Daniel Mayer:
> > Note that our daily Alexa ranking has dipped into the 500s - our best daily
> > showing ever.
>
> *g*
>
> BTW Why does Alexa do not rank wikipedia.org on their ranking of
> Encyclopedias???
> http://www.alexa.com/browse/general?catid=251&mode=general

I think it is because we are not listed in the "encyclopedias" category
at dmoz.org,
http://www.dmoz.org/Reference/Encyclopedias/

but rather

http://www.dmoz.org/Computers/Open_Source/Open_Content/Encyclopedias/

I have written to them about this, but you know how dmoz is, not
always responsive.

--Jimbo


list: wikitech-l

from_name: Evan Prodromou

subject: Development Roadmap (was Re: [Wikitech-l] Re: Faster parsing)

body:
So, the words "1.2" have been batted around, but we've got some
important features on the table for "future" consideration (e.g. the
schema changes).

I'm wondering if it's time to do a development roadmap and get an idea
of what we want from 1.2, 1.3, 2.0, dot dot dot.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


from_name: Poor, Edmund W

subject: [WikiEN-l] Erroneous attribution (was: Print edition)

body:
Peter, you mis-attributed the "split out versions" quote to me. It's an
easy mistake to make, when the list is at high volume. Actually, it was
Mark (Delirium) who wrote it, in respones to my "invisible marker"
suggestion, as follows. -- regards, Ed Poor

Poor, Edmund W wrote:

>It's too hard to keep a running list with more than 100 links.
>
>How about an invisible marker like {ready for print} near the top of
>the article text?
>
>
I think we need to split out versions somewhere else, because we're
looking for concise articles, not full encyclopedia articles.  Simply
marking [[World War II]] as "ready for print" doesn't do anything
towards getting us a good one-to-two-paragraph summary of World War II.

-Mark

_______________________________________________


subject: [WikiEN-l] Rick's request to "moderate" Plautus

body:
Gareth Owen wrote:

>"Poor, Edmund W" <Edmund.W.Poor at abc.com> writes:
>
>>If a consensus develops that P. is flooding the list, and enough people
>>insist, I can turn on the moderation flag for any user.
>>
>Please don't.
>
>The last thing his persecution complex needs is some actual persecution.
>
>Those people who don't want to read his emails and don't know how to configure
>their software so they don't have to can use this as a valuable learning
>opportunity.
>
I agree with this.  Even if the posts by him are almost as annoying as
the posts about him, this can be a good opportunity to see if the delete
key works on your own keyboard.

If we are to moderate the posts BY him, then fairness demands that we
apply the same moderation to the posts ABOUT him.

Ec


from_name: Ivan Krstic

subject: [Wikitech-l] Re: Faster parsing

body:
Timwi wrote:
> There is MySQL replication. I don't know much about it though (nor do I
> know much about rsync other than what it's used for), so I don't know.

As far as I know, MySQL replication isn't practical for the one-to-many
scenario that a lot of people would like to see it used for (home users
keeping syncs of the wikipedia database). I've been writing some basic
code that would let us do this type of 1-to-x replication nicely, but
we'll see whether anything comes of that.

> I suppose I could argue that you could couple this with CVS, which can
> produce patches to the dumps, but that's getting hacky :-)

It would hardly be a valid argument. My Feb 15 dump of 'cur' and Jan 30
dump of 'old' are roughly 15.1Gb total in size, uncompressed. I'm not
even sure how diff would behave with files that size; if you compress
them, you'd be looking into binary patches that would in all likelihood
be useless (i.e. someone correct me if I'm wrong, but depending on your
blocksize, a change early in the file would probably propagate
downstream and require retransfer of most of the file).

>> As far as queries are concerned, you can see it yourself on the
>> Special Pages -
>> most of the queries are turned off for performance reasons, so that's
>> not really a good argument.
>
> Ah, but that's not an indication that MySQL, or RDBMS in general, is a
> bad idea. I just shows that the current database schema is ill-designed.

Possibly. In my mind, a database is certainly the way to go; the
question becomes whether a less general implementation, tailored to our
needed subset of SQL92 (as opposed to something implementing the entire
thing and more) is needed. I have no data to speak to concretely, but
I'd suspect that such a drop in complexity could likely produce strong
performance improvements.

> I'm not sure I fully understand what you mean by this. Apparently we do
> update something like the "recentchanges" table on every edit, because
> some people seem to have thought that it would make for better
> performance, but I'm pretty much convinced that this assumption is
> fallacious.

I lay no claims to expertise in this area, but I'm (and I'm sure others
are) more than willing to hear better proposals. How would you do it?

Cheers,
Ivan


body:
Yes, I can put Plautus on moderation. But I have no authority to do so.
When I took this job, it was quite firmly stated that my only task is to
"administer".

If a consensus develops that P. is flooding the list, and enough people
insist, I can turn on the moderation flag for any user.

Ed Poor
Mailing List Administrator
Wikien-l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040227/733f4233/attachment.htm


from_name: Sheldon Rampton

subject: [WikiEN-l] Re: Vigilantism

body:
I wrote:

>  > One solution might be to designate a few trusted individuals as
>>  volunteer "judges" -- people to whom Jimbo in his capacity as dictator
>>  grants the authority to take action instantly, if they feel conditions
>  > warrant. The decisions of judges, of course, would be subject to
>>  review by the arbitration committee, and a judge who repeatedly abuses
>  > his authority would have it revoked.

To which Mark Pellegrini replied:

>Well, if this is done, I'm not sure why we'd really need the arbitration
>committee.  Just to rubber-stamp judge decisions?

No, not at all. Perhaps I should change my metaphor. Instead of
"judges" and "arbitration committees," perhaps it would be better to
use terms like "police" and "juries," along the lines that Ed Poor
has suggested (see below).

What we're dealing with fundamentally is the need to have some system
of governance for the Wikipedia. Everyone here (myself included)
wants to have "as little government as possible," but we need SOME
rules and SOME enforcement. On Wikipedia, we don't have to worry
about the worst kinds of crime, like murder or even theft of
property, but an aggressively obnoxious person can do more harm than
we ought to tolerate. The situation is rather akin to throwing a
party in your home. Jimbo has invited everyone in the neighborhood,
but if some jerk shows up and starts harassing the other guests, it
would be inconsiderate of the other guests if Jimbo DIDN'T tell the
jerk to leave. And as owner of the house, he's entitled to do that.
If the party is large enough and Jimbo can't do this entirely on his
own, he's entitled to ask some other people he trusts to police the
party as his surrogates.

In most effective systems of government, there is a division of
labor. In the U.S. federal government, we have the legislative branch
(whose job is to write laws), the executive branch (whose job is to
implement and enforce them), and the judiciary (whose job is to
determine interpret the laws and their enforcement). Of course, this
isn't a perfect system (nothing is), but it accomplishes certain
worthwhile things: (1) it creates a division of powers, which reduces
arbitrariness and abuse; and (2) it encourages public ACCEPTANCE of
the government's actions.

We have a similar system in the town where I live: A city council
that passes local ordinances (the legislative branch); a mayor and
police who enforce laws (the executive branch); and local courts
where people can seek judgment if they have disputes (the judiciary).
Each branch performs a necessary but separate role. The legislators
establish the rules governing police and the mayor as well as
everyone else. The police perform a necessary role, but they can't
simply arrest someone without cause because they know they have to be
able to defend their actions in court if they are sued. The courts do
not simply "rubber-stamp" decisions by police and the mayor, although
often the courts rule in favor of the police.

One of the reasons to have police and a mayor is SPEED OF ACTION,
because they don't have to go through a deliberative process like a
courtroom before they can take any action. Imagine that you see a
crime in progress in your neighborhood and your only recourse is to
initiate a lawsuit. By the time you even got a court date set, the
criminals would have completed their crime and be long gone.

Ed Poor also responded to my suggestion, writing:

>Should we invest some users with authority which elevates them from
>"vigilantes" and makes them more like a police force ("judges", as
>Sheldon put it)?
>
>This is essentially Erik's idea, dressed up in an official uniform (hope
>I'm not being tactless, here :-)

Actually, though, the point is that people who are invested with
authority ("dressed up in an official uniform") are NOT vigilantes. A
vigilante is someone who acts as a law unto himself and who is
therefore himself a law-breaker rather than an enforcer of laws.

Of course, the difference between vigilantism and police is not
always this clear-cut (a theme that has been explored in several
Clint Eastwood movies), but the basic idea works. We authorize police
to issue fines and arrest people -- even using physical force if they
deem it necessary -- precisely because we don't want EVERYONE in
society using force to have their way. If we are wise, we also limit
police abuses by having clear laws that limit their powers, providing
them with training in proper police procedures, and having courts
that are willing to curb abuses when necessary.

If all of this sounds like a lot of work, it can be. But it's also a
lot of work for Wikipedians to be continually agonizing anew over how
to deal with the latest troll.
--
--------------------------------
|  Sheldon Rampton
|  Editor, PR Watch (www.prwatch.org)
|  Author of books including:
|     Friends In Deed: The Story of US-Nicaragua Sister Cities
|     Toxic Sludge Is Good For You
|     Mad Cow USA
|     Trust Us, We're Experts
|     Weapons of Mass Deception
|     Banana Republicans (Tarcher/Penguin, May 2004)
--------------------------------


from_name: sannse

body:
Mark wrote:

> Perhaps it shows my political leanings, but I don't really like that
> approach.  Certainly we should have all opinions represented, and if
> certain opinions are only represented by women, then we should have
> women represented.  But we should represent all opinions, not based on
> simple categorizations like gender, race, etc.---you can't assume that
> someone has certain personality or characteristics because they're
> female, or male, or hispanic, or whatnot (certainly most people I know
> offline don't follow the stereotypes, and many fit 'opposite' roles
> better).  As far as wikipedia goes, things like inclusionist vs.
> deletionist, pro- vs. anti-banning, etc., are all more relevant
> distinctions by at least an order of magnitude.
>
> So if there's a woman on the arbitration committee (or multiple women),
> it should be because of who they are, not just because we wanted to
> throw a token woman on there.  Which, fortunately, is how Wikipedia
> normally works---I often can't tell if someone is male or female until
> it gets mentioned long after I've interacted with them for a while, and
> there's some surprises (for whatever reason, I thought that evercat was
> female, and that anthere was male).

Generally I agree.  I don't want to see a token woman either (or a token
anyone else).  But I think Wikipedia has suffered in the past from an
invisibility of women, it's only recently that I've noticed more women
around, and I think the (possible) lack of female input in the arbitration
committee is a shame.  But that said, it's not something I'm going to bang
on about.

> And, FWIW, we allowed *everyone* on a committee who wanted to be on
> one.  So at the moment the reason there are no women is because no women
> volunteered.  If someone wants to volunteer, male or female, we could
> use an extra member to keep the numbers at the right level, so talk to
> Mr. Wales asap. =]

At least two women, Angela and I, /were/ available for the arbitration
committee.  Both of us expressed a preference for mediation but an
availability for arbitration.  Jimbo went with our preference and that's
fine, but since Alex pointed out the apparently all male arbitration
committee I've thought that this is an issue that should be addressed if
possible.  If UC is firm on leaving the committee this seems a good
opportunity.  Any woman out there want a job?  No pay, lots of hassle, but
the potential for an occasional warm fuzzy feeling inside.

--sannse


from_name: Brian Corr

body:
Yes, please put Plautus on moderation.

Thanks for all of your work on this,
Brian (Bcorr)

Ed Poor wrote:
>Yes, I can put Plautus on moderation. But I have no authority to do so.
>When I took this job, it was quite firmly stated that my only task is to
>"administer".
>
>If a consensus develops that P. is flooding the list, and enough people
>insist, I can turn on the moderation flag for any user.
>
>Ed Poor
>Mailing List Administrator
>Wikien-l


subject: [WikiEN-l] Print edition

body:
Nathan Russell wrote:

> Agreed.  And we should clean up some stuff, for example "list of
> obscure things" articles before we gather content for any such project.

That has nothing to do with the first Print edition.  Lists of obscure
things are a constructive fact of life on Wikipedia, and they can
provide an endless source of fascination to readers.  Wallechinsky's
"Book of Lists" was very popular when it came out, so we shouldn't rule
out this sort of thing for future editions.  The "clean up" proposal
sounds ominous.

Nevertheless, I don't think we're ready to handle this sort of thing for
a first edition with a tight publishing deadline, so it would just not
be imported.

Ec


subject: [WikiEN-l] Proposal for dealing with reincarnations

body:
uninvited at nerstrand.net wrote:

>The Wikipedia Bureaucracy will validate identities using sensible but effective methods, such as requiring a $1 donation via paypal or personal check, or returning a form sent to the user's postal address.  The identity check will be used to determine whether the user is previously banned, and will be used to enforce a future ban if one should become necessary.  Otherwise, it will remain confidential.
>

This proposal should wait until there is a broad consensus in favour of
having a large paid bureaucracy?

Ec


subject: [WikiEN-l] Print edition

body:
Nathan Russell wrote:

> --On Thursday, February 26, 2004 9:00 PM +0000 Caroline Ford
> <caroline at secretlondon.me.uk> wrote:
>
>> We need to check how this affects our not-for-profit status.
>> I guess that the plan would be for the wikimedia foundation to get
>> some sort of profit share? In the UK this could count as primary
>> purpose trading under UK Charity Law (depending on what the objects
>> of the charity were) - and would be legal. In some cases a trading
>> company would have to be set up.
>>
>> I know _nothing_ about US not-for-profit law - I just thought I'd
>> flag it as a potential issue.
>>
>> Caroline
>
>
> It's an issue to some extent - but non-profit groups - college honor
> societies, churches, etc do fund raising activities all the time.  I
> believe the issue is in what the money can be used for - and it can be
> and is used for employee salaries, specifically.

Any gross revenue that is subject to tax may be reduced by all relevant
expenses.  As long as we continue to need donations it suggests that the
expenses exceed revenue, in which case taxes are a non-issue.  Having
employees, however, could intrduce us to the wonderful bureaucratic
world of tax wihholding and other employment standards.

Ec


subject: [WikiEN-l] Why so upset, Jumbo?

body:
Nathan Russell wrote:

> --On Thursday, February 26, 2004 9:04 PM +0000 Plautus Satire
> <plautus at shaw.ca> wrote:
>
>> Mr. Wales, I do not understand why you are so upset. I asked you if
>> you intended to use wikipedia as a revenue stream, and you indicate
>> that you are intending to do just that. Where is the offense, please?
>> That I suggest you want the information in wikipedia to be popular
>> even where it is inaccurate? I'm sorry, I just am trying to make
>> sense of your position here.
>
> The subject line of this post is enough to mark you as a troll in my
> personal opinion.  Note that that is not my opinion as a sysop, nor am
> I speaking for anyone except myself as a 21 year old college senior.

This post was quickly followed by another that claimed it was a typo.
 Since the "u" and "i" are beside each other on the keyboard, it is a
perfectly understandable one.

Ec


from_name: Nathan Russell

subject: [WikiEN-l] Word of advice to troll mafia.

body:
--On Friday, February 27, 2004 7:43 AM +0000 Plautus Satire <plautus at shaw.ca> wrote:

> Curps is a lousy footsoldier.
>
> Can I please get unbanned now Mr. Wales?
>
> Codie Vickers

"Troll mafia?"  Use of pseudoscience and personal insults?

Can we have a crosscheck versus Khranus please?

Nathan


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Re: Faster parsing

body:
On Fri, Feb 27, 2004 at 09:13:12AM +0000, Timwi wrote:
> Ivo K?thnig wrote:
>
> >I think the bottleneck is using a database mangement system (here mysql).
> >So my question is: What is the advantage of using it?
> >[...]
> >For me it always looks as we use the database just to use the database. So
> >again: where is the advantage?
>
> 1) easy backup
> 2) easy construction of queries (SQL)
> 3) flexibility with construction of *new* queries that we haven't
>    thought of before
> 4) don't (well, shouldn't) need to update hundreds of data structures
>    upon every edit
> 5) databases are designed to do this sort of thing (esp. indexing)
>
> There are probably *loads* more.

Mirroring is the biggest *disadvantage* of MySQL solution.
UseMod wikis are extremely easy to efficiently mirror via rsync,
and it was done with Phase I too. It was even easy to mirror it
in "almost real-time" (like once an hour or so) over very small pipe
(I did mirror Polish Wikipedia like that on 115kbit/s, and it took
only small part of my bandwidth).

MySQL can only produce full dumps, and they are huge, take lot of time
to generate, and lot of time to import at the mirroring site.

As far as queries are concerned, you can see it yourself on the Special Pages -
most of the queries are turned off for performance reasons, so that's
not really a good argument.

And we need to update the data structures all the time for performance reasons.


subject: [WikiEN-l] Print edition

body:
--On Thursday, February 26, 2004 12:45 PM -0800 Jimmy Wales <jwales at bomis.com> wrote:

> Delirium wrote:
>> Well, part of that would hinge on what exactly we're going to be doing
>> for them.  Are we going to give them wikitext and they're going to
>> properly format it and work out the GFDL issues and whatnot?  Or are we
>> expected to provide them material in whatever their preferred format is,
>> and with all the details worked out?
>
> I'd say that's open ended at this point.  Everything is.  We should
> brainstorm about it.

Agreed.  And we should clean up some stuff, for example "list of obscure things" articles before we gather content for any such project.

> Of course any publisher can come in and take the wikitext and make
> their own "Joe's Publishing Company Encyclopedia", without consulting
> us.
>
> But what makes more sense for us, and for a publisher I think, is for
> us to use this to "prove" our quality by going to print, under the
> Wikipedia name.  And for that we probably want to do as much of the
> work as we can.
>
> --Jimbo

Do you/somebody still hold trademark on "Wikipedia?"

Nathan


from_name: Gareth Owen

subject: [WikiEN-l] Re: About Platus Satire

body:
Bjorn Lindqvist <bjrn.lindqvist at telia.com> writes:

> Can you, or anyone else here, with a straight face say that; if they
> were banned, and felt that there was absolutely no reason for the ban,
> would be able to stay completely calm as a saint?

Yes.  I can say that.
It's not as if there aren't other things to do with ones time.
--
Gareth Owen
"And Cunct, please stop being such a prick."
                        -- wikipedia-l (Wed Nov  6 2002)


from_name: Brion Vibber

subject: [Wikitech-l] Re: Faster parsing

body:
On Feb 27, 2004, at 13:51, Andre Engels wrote:
> Does this mean that we will NOT get full text search back soon?

No, it means we'll get it back when we have Geoffrin back online, on
which fulltext search ran just fine. Geoffrin, running on 64-bit Linux
with 4GB of RAM available to MySQL, was able to deal with the large
search indexes in memory. Our current database server is on a 32-bit
kernel and can only assign 2GB of RAM to the database. Less is
available for the (large!) search indexes, and it gets very slow
dealing with them.

Penguin's fixing it, and if they actually do it right this time it
should be back online within a couple of weeks, at which time we can
transition over a copy of the database that's being separately synched
up now and will be ready with minimal downtime.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040227/d3c0c473/attachment.pgp>


subject:
[WikiEN-l] apologies for long lines,
	please don't assume this means I am a "long line" troll.

body:
--On Thursday, February 26, 2004 10:29 PM +0000 Plautus Satire <plautus at shaw.ca> wrote:

> I just realized in the archive everyone else linebreaks.
> I will start doing this in the future, I got lazy, I
> am sorry.

On a lot of mailers you can do this by making your window smaller than maximized size.

By the way, I'm also being lazy and posting from a school machine without access to my key.  If anyone wants a ratification of this message when I'm back in my room, or any other message, mail me here or offlist.

Nathan


from_name: Fred Bauder

subject: [Wikipedia-l] Info for Open Source Directory for Alexa

body:
Someone who has the authority, such as Jimbo, needs to go here and fill out
their form.

http://dmoz.org/cgi-bin/add.cgi?where=Reference/Encyclopedias

Fred

> From: Robert Michel <news at RobertMichel.de>
> Reply-To: wikipedia-l at Wikimedia.org
> Date: Fri, 27 Feb 2004 18:02:37 +0100
> To: wikipedia-l at Wikimedia.org, Daniel Mayer <maveric149 at yahoo.com>
> Subject: Re: [Wikipedia-l] > 230 request/second - but no Wikipedia news on
> slashdot ; ) what is this?
>
> Salve Daniel,
>
> Am Donnerstag, 26. Februar 2004 19:00 schrieb Daniel Mayer:
>> Note that our daily Alexa ranking has dipped into the 500s - our best daily
>> showing ever.
>
> *g*
>
> BTW Why does Alexa do not rank wikipedia.org on their ranking of
> Encyclopedias???
> http://www.alexa.com/browse/general?catid=251&mode=general
>
> rob
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


subject: [WikiEN-l] I think you and I are on the same side.

body:
--On Friday, February 27, 2004 7:47 AM +0000 Plautus Satire <plautus at shaw.ca> wrote:

> I am under no illusions that you intend to turn wikipedia into a substantial
> revenue stream.

That's the understatement of the century, if anyone is unaware.

How much do you think bandwidth for a site that is comparable to Slashdot costs?

Hint: think enough to buy more than one large car a year.

Nathan


subject: [WikiEN-l] Print edition

body:
--On Thursday, February 26, 2004 9:00 PM +0000 Caroline Ford <caroline at secretlondon.me.uk> wrote:

> Jimmy Wales wrote:
>
>> But what makes more sense for us, and for a publisher I think, is for
>>
>> us to use this to "prove" our quality by going to print, under the
>> Wikipedia name.  And for that we probably want to do as much of the
>> work as we can.
>>
>> --Jimbo

> We need to check how this affects our not-for-profit status.
> I guess that the plan would be for the wikimedia foundation to get some sort of profit share? In the UK this could count as primary purpose trading under UK Charity Law (depending on what the objects of the charity were) - and would be legal. In some cases a trading company would have to be set up.
>
> I know _nothing_ about US not-for-profit law - I just thought I'd flag it as a potential issue.
>
> Caroline

It's an issue to some extent - but non-profit groups - college honor societies, churches, etc do fund raising activities all the time.  I believe the issue is in what the money can be used for - and it can be and is used for employee salaries, specifically.

Nathan


subject:
[WikiEN-l]
	http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:Requests_for_mediation&action=edit&section=4

body:
--On Friday, February 27, 2004 7:57 AM +0000 Plautus Satire <plautus at shaw.ca> wrote:

> I initiated the mediation.
>
> Curps refuses to let the proceedings be open, thus, Curps is refusing
> mediation.
>
> Curps is abusing me, he admitted it, I have now superfluosly and redundantly
> proven it.
>
> Why is the process being ignored?

It is not.  If I may make an analogy, Jimbo is using his reserve powers as BDfL.  He happens not to have decided to do that in a little while.

Nathan


subject: [WikiEN-l] Why so upset, Jumbo?

body:
--On Thursday, February 26, 2004 9:04 PM +0000 Plautus Satire <plautus at shaw.ca> wrote:

> Mr. Wales, I do not understand why you are so upset. I asked you if you intended to use wikipedia as a revenue stream, and you indicate that you are intending to do just that. Where is the offense, please? That I suggest you want the information in wikipedia to be popular even where it is inaccurate? I'm sorry, I just am trying to make sense of your position here.

The subject line of this post is enough to mark you as a troll in my personal opinion.  Note that that is not my opinion as a sysop, nor am I speaking for anyone except myself as a 21 year old college senior.

Nathan


from_name: Charles Matthews

subject: [WikiEN-l] Re: Print edition

body:
Ray Saintonge wrote

> We need to consider the way that the work is organized.

I'm a published author, and (more to the point) saw my 'Teach Yourself Go'
(Hodder Headline/NTC) through all stages from an outline template through to
the book on a zip disk ready for the printers. I'd like to say this, about
the copy editing and proof reading stage - I really don't think it can be
done live on Wikipedia, in a meaningful way.  It would really have to be the
case that any publisher started with the Wikipedia text and let loose a team
of pro copy editors to hack it into some sort of shape.  From the
publishers' point of view this is probably only feasible for cost by having
people work from home; but that is hardly a Wikipedia concern.

It is really easy to come up with a list of issues of consistency, mark-up,
demarcation of areas and so on.  I find it hard to believe this can
fruitfully be discussed here, though.

By the way, this is good, positive news, to add to the new servers (which
have hardly been mentioned here).

Charles


from_name: Tim Starling

subject: [Wikitech-l] Re: Faster parsing

body:
Poor, Edmund W wrote:
> Anyone know how to profile MySQL code?

Considering the amount of time Snok and I have spent writing and using
MediaWiki's profiling code, and considering the amount of time Brion has
spent on database optimisation (to great effect), you'll forgive me for
being slightly offended.

We've profiled, we've cached, we've optimised. We've discovered that CPU
  load is generally the bottleneck when viewing pages, and hence spent
time on parser optimisation and several kinds of caching. We have 4 web
servers and one database server and still the web servers are heavily
loaded.

Timwi wrote:
 > My guess is that the slowest part of it is checking whether a page
 > exists, and if it does, checking its size (if the user has set the
 > preference that shows stubs in a different colour), because both of
 > this requires a database query.

What, even with the linkscc cache and the memcached link cache? If you
say so.

Nick Pisarro wrote:
 > The current parser, which performs dozens of passes, probably degrades
 > by the square of the file size.

Really? All the regular expressions I've seen should be possible in O(N)
  time. There's no PHP loops which loop through every character, just
through certain kinds of entities such as every link. I would have
thought that 14 passes at O(N) still produces O(N). Oh well, I'm not a
computer scientist, what would I know.

 > Storing diffs in the 'old' table. This would not affect performance,
 > except when loading or comparing old revisions, but could drastically
 > reduce the size of the database, which has to benefit how manageable
 > it is. There already is a differencing engine in the source, though
 > I'm not sure how reliable it is--it may also degrade by the square of
 > the file difference. Here too, a sequence of diffs can be merged in
 > one pass. Having written such code in the past, I plan to create a
 > write up exploring this idea. Has this idea been discussed amongst the
 > developers? What are the gotcha's?

See http://meta.wikipedia.org/wiki/History_compression

Diffs have not been extensively speed tested, but seemed to be
reasonably fast when I was running my space tests. They produce good
compression in the talk page or incremental improvement situation, but
as expected, perform poorly in the edit war situation. As noted by Rob
Hooft in this post:

http://mail.wikipedia.org/pipermail/wikitech-l/2004-February/008385.html

it should be possible to improve compression in this case by trying
diffs with a few different revisions. As long as the time required per
diff is in the tens of milliseconds or less, this should be feasible.

-- Tim Starling


subject: [WikiEN-l] Plautus

body:
Okay, I thought about it.

I'm unblocking Plautus, and I take full responsibility for him as a
"parolee" per your terms below.

Kind of like Frodo and Smeagol.

Wish me luck.

Uncle Ed

-----Original Message-----
From: wikien-l-bounces at Wikipedia.org
[mailto:wikien-l-bounces at Wikipedia.org] On Behalf Of Erik Moeller
Sent: Thursday, February 26, 2004 10:09 AM
To: wikien-l at wikipedia.org
Subject: Re: [WikiEN-l] Plautus

Ed-

you're probably right. Plautus is just a misguided individual. All this

calling other users "dumb motherfuckers" and "fucking ignorant assholes"

has to be expected from a confused newbie. After all you yourself once
created a "Fucking asshole" account to make a point, remember?

Surely it is acceptable to lose 10 devoted, creative Wikipedians if we
can
keep a single crackpot around. I should really stop being so judgmental

and leave the important decisions to the people who got their priorities

straight, instead of looking at silly things like polls and hard
evidence.

If Ed believes that an individual is reformable, then we need to all sit

back and let the spirit of Sun Myung Moon work through him. I can't wait

to see you do your magic, Ed!

I have just one condition.

If this whole thing blows in your face, I want you to take full
responsibility for it. That means that I want you to go through every
single page Plautus satire edited in the last few days, to take diffs of

these edits and fix them if necessary. That includes erased comments on

talk pages, something he is very fond of.

How about it, Ed? Do you want the whole community to share your faith,
or
are you ready to fix things up if that faith turns out to be mistaken?

Regards,

Erik
_______________________________________________
WikiEN-l mailing list
WikiEN-l at Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikien-l


subject: [Wikitech-l] Hang on to your hats

body:
I'm going to be taking down some of the servers in turn, to unplug
them and put them on the power port, so that we'll have developer
access to power cycle without having the delay of contacting me.

I'll take each one down and back up in turn, so as not to disrupt
things any more than absolutely necessary.  The db server is already
pugged in so it won't be that one.

--Jimbo


from_name: David Speakman

subject: [WikiEN-l] Re: recipes

body:
Ed Poor::
I oppose deleting material from the Wikipedia, just because it fits an
identifiable category. The only "fork" I've seen so far that makes sense
to me is the dictionaries. There's a clear distinction between "defining
a word" and "writing about a subject". But there's nothing wrong with
describing the process of stirring eggs so the yolk breaks and mixes the
white -- unless you're a segregationist! ;-)

Davodd:
An argument could be made that since WP is not paper that even
dictionary definitions are stubs for a future encyclopedic article on
the subject of a word's origin, use patterns and cultural impact. Why
should etymology be the only academic discipline not worthy of
encyclopedic-type entries in Wikipedia?

David Speakman
http://www.DavidSpeakman.com


from_name: Nikola Smolenski

subject: [WikiEN-l] Re: Print edition

body:
On Thursday 26 February 2004 22:27, Jimmy Wales wrote:
> We have 214,720 articles.  Let's assume that this is a total of X
> pages.  But we need to hypothetically pare it down to X/3, i.e. 1/3 as
> much total content.
>
> We can pare it down by editing longer articles into shorter articles.
> Or we can (also) pare it down by simply omitting articles that aren't
> as "important" in some sense.

Just a few thoughts:

While looking for articles that should not go into the paper, I think that
there shoud also be a consideration of articles that should go into the paper
but are not there. Of course, not everything could be added, but it would be
very stupid and easy to fix, for example, if there would be articles on all
kings from some royal house except one or two, or on all electronic
components except one or two, or on all battles of the Second World War
except one or two... at least stubs on the absent articles should be created.

One of criterias for inclusion probably should be importance for other
articles. For example, it might be decided that only places with more then
10,000 inhabitants go onto paper, but a smaller place should also go if it is
birth place of a famous person who will have a paper article or a site of a
battle which will have a paper article etc.

Paper encyclopedias also have "links" among articles, for example marked with
-> . Now, for obvious reason they are not as often as links on Wikipedia. I
think that there should be a way of marking some of links as more important
then others so that they would be preserved on paper. Perhaps these should
stay in electronic edition as well, it would be nice to know which links are
the most relevant; if so, it would not even require changes in software.

I hope that lists will also go onto the paper. Having a themed index at the
end would be wonderful - is there an encyclopedia that has it?


from_name: Bjorn Lindqvist

subject: [WikiEN-l] Re: ding-danged format

body:
> In my haste I forgot to linebreak my last few posts,
>
> Are the long lines objectionable to anyone? I haven't seen any complaint, but
> I will try to rememeber to add linebreaks so that my posts are more readable
> in the archives.
>
> Thanks for your patience, I haven't used an email list in about twenty-five
> years, and then I was using a dinosaur and playing on BITNET relay chat.

They are extremely annoying to me and, I guess, everyone else that
uses a text-based e-mail reader. But as most people use a graphical
reader not many notice whether you use line breaks or not. There are
also other posters that doesn't use line breaks. So, if you can,
*please* turn it on because without line breaks it makes longer
paragraphs completely unreadable. But I understand that most people
aren't very computer-savvy so I wont complain either way.

BL


from_name: Jimmy Wales

subject: [Wikitech-l] spammish iptables

body:
I guess coronelli is setup differently than the other machines?
In any event, a billion trillion messages per second are flashing
on the console there.

Second, it turns out to be not true that these messages are only
on the first console.  I can hit alt-f2, etc. to get to new consoles,
but on all the machines, all this stuff flashes by anyway.

This is only a problem when I'm physically standing here in the
colo, but it sure sucks.


subject: [Wikitech-l] Re: New magic variables?

body:
On Thursday 26 February 2004 21:11, Timwi wrote:
> Nick Pisarro wrote:
> > Wikimedia developers <wikitech-l at Wikipedia.org> writes:
> >>Additionally, I really don't think it should be possible to include any
> >>article in any other article. An article should be clearly marked as
> >>being "includable" (which it is by being in the MediaWiki namespace). I
> >>don't know if it is currently possible to place a {{msg:}} inside a page
> >>on the MediaWiki namespace, but I believe that should be disallowed to
> >>prevent circular references (infinite recursion).
> >
> > If you did implement this feature, as you build up the page you *would*
> > have to watch for circular references. You could do this by stacking the
> > fully qualified names of what your in the middle of including and make
> > sure the new file isn't already on the stack.
>
> It would still be possible to create a ridiculously long chain.

Or you could do something similar to redirects, allow only one level of
inclusion.


from_name: Anthere

subject: [WikiEN-l] Re: Feminist agenda (was Arbitration progress report #6)

body:
sannse a ?crit:
> Mark wrote:
>
>
>>Perhaps it shows my political leanings, but I don't really like that
>>approach.  Certainly we should have all opinions represented, and if
>>certain opinions are only represented by women, then we should have
>>women represented.  But we should represent all opinions, not based on
>>simple categorizations like gender, race, etc.---you can't assume that
>>someone has certain personality or characteristics because they're
>>female, or male, or hispanic, or whatnot (certainly most people I know
>>offline don't follow the stereotypes, and many fit 'opposite' roles
>>better).  As far as wikipedia goes, things like inclusionist vs.
>>deletionist, pro- vs. anti-banning, etc., are all more relevant
>>distinctions by at least an order of magnitude.

I wonder if it might not be interesting to check the % of males versus
females more leaning on each of these sides : deletionist/inclusionist,
pro versus anti-ban etc...

>>So if there's a woman on the arbitration committee (or multiple women),
>>it should be because of who they are, not just because we wanted to
>>throw a token woman on there.  Which, fortunately, is how Wikipedia
>>normally works---I often can't tell if someone is male or female until
>>it gets mentioned long after I've interacted with them for a while, and
>>there's some surprises (for whatever reason, I thought that evercat was
>>female, and that anthere was male).

It is curious because I usually think my behavior is really more on the
feminine side than masculine one, but well. This lack of clarily is
precisely why I started  http://meta.wikipedia.org/wiki/Wikiwomen.

> Generally I agree.  I don't want to see a token woman either (or a token
> anyone else).  But I think Wikipedia has suffered in the past from an
> invisibility of women, it's only recently that I've noticed more women
> around, and I think the (possible) lack of female input in the arbitration
> committee is a shame.  But that said, it's not something I'm going to bang
> on about.
>
>
>>And, FWIW, we allowed *everyone* on a committee who wanted to be on
>>one.  So at the moment the reason there are no women is because no women
>>volunteered.  If someone wants to volunteer, male or female, we could
>>use an extra member to keep the numbers at the right level, so talk to
>>Mr. Wales asap. =]
>
>
> At least two women, Angela and I, /were/ available for the arbitration
> committee.  Both of us expressed a preference for mediation but an
> availability for arbitration.  Jimbo went with our preference and that's
> fine, but since Alex pointed out the apparently all male arbitration
> committee I've thought that this is an issue that should be addressed if
> possible.  If UC is firm on leaving the committee this seems a good
> opportunity.  Any woman out there want a job?  No pay, lots of hassle, but
> the potential for an occasional warm fuzzy feeling inside.
>
> --sannse

warm fuzzy feeling ? My ... sannse, where did you find that ? :-)


from_name: John Knouse

subject: [WikiEN-l] wikipedia access denied

body:
Well.  I was right in the middle of a lengthy edit, and
tried to save it, and got a message access denied.  I've
tried multiple means of access.  Wikipedia seems to be
somehow completely screwed up right now.  Fortunately, I had
the (for me) atypical good sense to save the whole edit on
my local computer before I lost it all.

--
John Knouse
jaknouse at frognet.net


from_name: Mark Christensen

subject:
[Wikipedia-l] > 230 request/second - but no Wikipedia news
	onslashdot ; ) what is this?

body:
> BTW Why does Alexa do not rank wikipedia.org on
> their ranking of Encyclopedias???
> http://www.alexa.com/browse/general?catid=251&mode=general

Because it is on the list of open content encyclopedias.

http://www.alexa.com/browse/general?catid=50241&mode=general

They are just following the categorization scheme used at the Open Directory Project.


subject: [Wikitech-l] spammish iptables

body:
Something was screwed up with coronelli's iptables config and port 80
wasn't open.

It was open *before*, though, so that's a bit odd.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040227/ed821e81/attachment.pgp>


subject: [WikiEN-l] Plautus

body:
--On Friday, February 27, 2004 11:10 AM -0500 "Poor, Edmund W" <Edmund.W.Poor at abc.com> wrote:

> Okay, I thought about it.
>
> I'm unblocking Plautus, and I take full responsibility for him as a
> "parolee" per your terms below.
>
> Kind of like Frodo and Smeagol.
>
> Wish me luck.
>
> Uncle Ed

You might want to count your fingers now.

Nathan


from_name: Delirium

subject: [WikiEN-l] Plautus was kicked off this list

body:
Poor, Edmund W wrote:

>The vote on moderation was:
>
>Support: RickK, Fred Bauder, Brian (Bcorr)
>
>Oppose: Eclecticology, Gareth
>
>The result was: Plautus was unsubscribed from the mailing list, not just
>"moderated". He's name is off the subscriber list.
>
>Plautus cannot post here. He can only read the public archives on the
>web.
>
>
Isn't an informal 3-2 vote kind of a slim margin to kick someone off the
list by?

-Mark


from_name: Andre Engels

subject: [Wikipedia-l] Wiki-images?

body:
On [[en:Wikipedia:Public domain image resources]], there is a nice list of sources, but it is not
easily searchable. It is not clear which if any of these sources could provide me with an image of
(fill in something). Because of this, we will find people either search long for images, not do it at
all, or fail to find them. It's made even worse by sources such as http://www.radiobras.gov.br/
that someone added recently - the site has some very useful content, but searching the site is a
nightmare.

I would propose to start a place where we can keep descriptions of images and image searches,
a search on which could then be used to get free or copyleft images for a certain subject. A nice
start in this direction is made by the GIMP image archive, but:
* It only contains a few sources, and does not have the possibility to add others
* The original image descriptions are not included or linked to, so people when giving descriptions
   cannot use these, which means that for example portraits are worth much less because one does
   not know who is being portrayed.

Could it be made a wikiproject to make such information available? My idea would be a wiki
(we're wikipedia aren't we?) where one could either upload the photographs and add its
description and copyright status, or use a 'normal page' to link to the place where the image
are, and again add a description. Adding keywords would also be a good idea. If a number of
people would work on this for some time, we would thus get a nice, searchable collection of
public domain and copyleft images.

Andre Engels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040227/5971ba40/attachment.htm


subject: [Wikitech-l] Re: Faster parsing

body:
Timwi wrote:
> Tim Starling wrote:
>
>> Timwi wrote:
>>  > My guess is that the slowest part of it is checking whether a page
>>  > exists, and if it does, checking its size (if the user has set the
>>  > preference that shows stubs in a different colour), because both of
>>  > this requires a database query.
>>
>> What, even with the linkscc cache and the memcached link cache? If you
>> say so.
>
>
> I apologise if my comment was in any way offensive to you, but please do
> take note of the fact that (a) I said it was a guess; (b) I did mention
> somewhere else that I have no real idea to what extent memcached is
> already being used; (c) I have not attacked you, or even addressed you
> at all.

You're misjudging my tone, I'm not offended. I'm just making fun of you :)

> With that said, please may I humbly ask what "the linkscc cache"
> actually caches? What exactly is stored in each memcache key here?

linkscc is a database table which stores a serialised, compressed
LinkCache object. This contains an array of "good" links, an array of
"bad" links, and an array of image links from a given page. Hence when a
page is loaded the script only needs one DB query to find out which
links exist. It turns out that only a small proportion of users have a
stub threshold. Viewing pages with a stub threshold does indeed require
lots of DB queries.

In addition, the memcached "lc" keys store an article ID for each page
title. This improves efficiency where linkscc is not used, for example
when saving a page.

> Isn't history compression going to be detrimental to CPU usage rather
> than beneficial? I am still finding it hard to understand why so many
> people here feel that history compression is necessary.

It's detrimental to CPU usage, but it reduces I/O on the database
machine, allows RAM caching of more articles, and reduces the bandwidth
required for backups and slave DB synchronisation. If compression and
decompression can be done in a few milliseconds of CPU time, it's likely
that it will be beneficial overall.

Although CPU is dominant for page views, for many other features it is
the database which is dominant. When viewing history, the database is
the major bottleneck.

-- Tim Starling


subject: [WikiEN-l] Paulus...

body:
Dear Paulus;

Obviously, you have a lot to say :-)
I suppose that you need a public place to post all facts, statements,
and relevant information, as regards the current arbitration process.
I think the best place to do this (it will be much better preserved than
on the mailing list) is for you to head to the proper arbitration forum.
This forum is of course public, and is dedicated to arbitration proper.
You will need to register to post, but no approval is required. Just
fill in the information.

The address is http://boards.wikimedia.org/viewforum.php?f=2

Please, try to focus on writting in the forum place for any arbitration
issue.

You may go on posting for any other issue on the english mailing list.
It will probably take a little longer for the posts to get through though.

I must insist that you choose preferably the board for most of the
current discussions. If you want to discuss the mediation process,
please post on the appropriate forum as well.

I strongly suggest that you do this, in order to help antie and uncle
ensure this forum stays functionnal and a friendly place.

Best wishes

Ant

(co-moderator today)


from_name: Magnus Manske

subject: [WikiEN-l] Re: Print edition

body:
mapellegrini at comcast.net wrote:

>First, let me say that the idea of a printed version of Wikipedia is *GREAT*
>
>I'd like to make a modest logistical proposal for the print edition. I think
>that each article, in addition to having an associated talk page, should have
>an associated "Wikipedia 1.0" page - a page containing a print-encyclopedia
>worthy summary. This is important, because a printed encyclopedia should
>contain no web links, or internal links, but we don't want to remove them from our articles either. Some longer articles need to be shortened for the print version as well. I think this is the most workable way to do it.
>
>

How about a "printable" (or "print") namespace? Or "brief"?

Important functions for this:
* For the "print:" version, show number of (normal/minor) edits of the
"big" article and the time passed since the last edit of the print
version. This will help keeping the printable version up-to-date with
information on the "real" page.
* Some mechanism to lock the page when the deadline approaches. This
could be a page protection after at least two approvals.
* Links in "print:" should automagically link to the "print:" versions
instead of the ":" namespace. That way, it would be easy to see what's
missing (broken link).

A list of articles to include could start as a list of existing
articles, sorted by "how many articles link here" (":" namespace only).

Magnus


from_name: Brian Corr

subject: [WikiEN-l] Plautus rebanned, banned from wikien-l

body: Thanks for the perspective, Jimbo!


subject: [WikiEN-l] Hardbanned user HJ

body:
Caroline Ford wrote:

> Hardbanned user HJ has returned under IP address 66.47.62.78
>
> Has this person been unbanned? Should we be blocking/reverting them?

 From [[User:H.J./ban]]:

        (in response to "Has the ban been lifted?")

 Jimmy Wales wikipedia-l at wikipedia.org
 Sun, 25 May 2003 12:07:20 -0700

 No, Helga is not welcome to edit any wikipedia, she is banned.  If she
 wishes to start again, the same offer stands as always -- she can
 email me and chat about it.

----

So it would appear she's still banned, unless something has happened in the months since May '03.

-Mark


from_name: Poor, Edmund W

subject: [WikiEN-l] Nine-fingered Frodo

body:
Nathan,

I counted. Here's the result.

http://www.tolkiengathering.com/artgallery/art201.html

Ed Poor


from_name: Erik Zachte

subject: [Wikitech-l] Mapping complement to Wikipedia?

body:
There is a Historical Event Markup and Linking Project

http://heml.mta.ca/heml-cocoon/

They try to address issues mentioned here.
There is demo of an animated map there as well.

They choose SVG as the medium which seems a good choice.
I know there are (were ?) problems with SVG viewing on Mozilla,
but that will be fixed, I'm sure.

Erik Zachte


subject: [Wikipedia-l] Mapping complement to Wikipedia?

body:
Oops, sent my reply to Wikitech first, I hope the discussion does not fork
:)

There is a Historical Event Markup and Linking Project

http://heml.mta.ca/heml-cocoon/

They try to address issues mentioned here.
There is demo of an animated map there as well.

They choose SVG as the medium which seems a good choice.
I know there are (were ?) problems with SVG viewing on Mozilla,
but that will be fixed, I'm sure.

Erik Zachte


subject:
[Wikitech-l] Mapping complement to Wikipedia? (Oops,
	should be on wikipedia-l)

body:
I sent my reply to the wrong list, please don't reply here.
Erik Zachte


from_name: Joshua Holman

body:
On Friday, February 27, 2004, at 12:49  PM, Fred Bauder wrote:

> Someone who has the authority, such as Jimbo, needs to go here and
> fill out
> their form.
>
> http://dmoz.org/cgi-bin/add.cgi?where=Reference/Encyclopedias
>
> Fred

Fred,

The last time I checked, anyone can submit a site to the ODP. I'd think
I can do this. However, coming up with quality keywords is a different
ballgame.

Joshua Holman
AKA Hoshie


from_name: Erik Moeller

subject: [Wikitech-l] Re: Faster parsing

body:
Ivo-
> I think the bottleneck is using a database mangement system (here mysql). So
> my question is: What is the advantage of using it? As I understand the
> toppic dbms is usefull for very structured redundant data.

This is an eternal debate. You may want to look at MoinMoin, which stores
all its pages in plaintext and still manages to be very powerful:

http://moin.sourceforge.net/

Also see my review of several DB and non-DB based wiki engines in
c't 25/03.

Using a database allows us to run a set of highly complex queries to
examine the relationships between articles and the metadata about
articles. In fact we can even examine the relationship between articles
and users (watchlist), or between the metadata of different articles
(redirect status in "What links here").

All that would only be possible using ugly hacks without a database -- you
would effectively have to build your own mini-DB to store this metadata,
and most text-based wikis do this. They get extremely slow when it comes
to very basic stuff such as listing backlinks or doing a fulltext search.
Not on a small wiki, but on one of the size of Wikipedia. I have imported
large datasets into TWiki etc., and many operations became practically
unusable.

The MediaWiki FT search has locking issues. It's very fast for a normal
wiki, but for a huge one like Wikipedia it tends to get in a deadlock
state. That's why we have to disable it on Wikipedia. Some other queries
could also be made faster. Many of our queries have been optimized now and
every single one should eventually return results with a response time of
milliseconds.

It is a fallacy that a database makes things more complicated. It makes
them much easier because you don't have to worry where to store something
before implementing it. How do you want to store your user prefs, the
redirect info, the recent changes table, the page history, always keeping
quick access in mind? Usemod, Twiki etc. all use ugly hacks for that kind
of stuff.

In short, a DB is faster, cleaner, and more convenient. We benefit from
the thousands of man hours that the MySQL developers have invested in
building a scalable, fast, powerful multi-user database instead of having
to reinvent the wheel whenever we want to do something that goes beyond
"show me that file".

Regards,

Erik


subject: [Wikitech-l] Re: Faster parsing

body:
"Erik Moeller" <erik_moeller at gmx.de> schrieb:

> The MediaWiki FT search has locking issues. It's very fast for a normal
> wiki, but for a huge one like Wikipedia it tends to get in a deadlock
> state. That's why we have to disable it on Wikipedia. Some other queries
> could also be made faster. Many of our queries have been optimized now and
> every single one should eventually return results with a response time of
> milliseconds.

Does this mean that we will NOT get full text search back soon? That would be
a shame. If it is indeed the case that with another DB server we will still
have locking problems with searches, we might want another architecture,
with a dedicated search (plus several other functions, such as special pages
and SQL queries, perhaps even Whatlinkshere) machine, which gets its database
updated only once per second/minute/hour/whatever rather than in real time.

Andre Engels


subject: [Wikipedia-l] Wiki-images?

body:
"Constans, Camille (C.C.)" <cconsta4 at ford.com> schrieb:
> I like this idea, but it doesnt exist yet elsewhere ? It's true that
> a wiki system would be nice.

Well, I have not found anything quite like it. As said, the closest thing
would be the GIMP Image Archive (http://gimp-savvy.com/PHOTO-ARCHIVE/),
but that one has only specific sources (NASA, NOAA, USDA and FWS). I would
like to give users the possibility to add images they found elsewhere (as
long as they're PD or Copyleft). It also suffers the disadvantage of not
having downloaded a context with the image, because of which it is often
not clear to the volunteer describing the picture what is actually on it.

A second similarity would be Google's image source, but there one cannot
choose to get only images that are PD or Copyleft, but has to wade through
masses of copyrighted images to see whether there is one that one is
allowed to use.

> But if a picture has nothing to do, how will you choose to keep or
> delete it ? Will we use the same system as wikipedia for pages deletion ?

That's a policy decision that is to be taken, but should not influence
whether and how this is done otherwise. My own opinion would be that 'unused
image' should not be a reason for deletion (on the other hand, unused images
on Wikipedia might well be transwikied), but that one might set up a system
to delete images that do not seem useful for Wikipedia or similar projects -
Here I think in the first place of "yet another image of a..."-cases.

Andre Engels


from_name: Nathan Russell

subject: [WikiEN-l] Print edition

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ray Saintonge wrote:
| Nathan Russell wrote:
|
|> Agreed.  And we should clean up some stuff, for example "list of
|> obscure things" articles before we gather content for any such project.
|
|
| That has nothing to do with the first Print edition.  Lists of obscure
| things are a constructive fact of life on Wikipedia, and they can
| provide an endless source of fascination to readers.  Wallechinsky's
| "Book of Lists" was very popular when it came out, so we shouldn't rule
| out this sort of thing for future editions.  The "clean up" proposal
| sounds ominous.
|
| Nevertheless, I don't think we're ready to handle this sort of thing for
| a first edition with a tight publishing deadline, so it would just not
| be imported.

I *meant* not importing it, NOT deleting it from WP!

Nathan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Netscape6 - http://enigmail.mozdev.org

iD8DBQFAP5dHMUlnNfyqpaMRAm+oAJ0YCYPCDfE0pmBtYfeRyW6E3ruZQgCghinz
lm0XxnDdTc8QGn5lM5Y8VUk=
=0Eui
-----END PGP SIGNATURE-----


from_name: Dan Miller

subject: [WikiEN-l] Re: Uninvited proposal

body:
A little draconian, anyone? This goes_way_too far,
IMO.

1.  Any non-rookie, engaged in an edit war, can simply
freeze out any rookie/anon in an edit war by making 5
quick edits.

2.  We don't know how many of our articles would fall
under "frequently edited".

3.  This is offputting to newbies, and we need_more_of
them, not fewer--without growth, our vitality is gone.

4.  The "reveal your real ID" provision is extremely
onerous.

5.  Facilitates the irritation of ANY unpopular user,
and increases the odds of factionalization and etc.

6.  Is generally unwikilike.

TINC my ass.

Meelar

> === PART ONE ===
>
> ==== Definitions ====
>
> Rookie : A logged in user who has fewer than 10
> editing days.  An "editing day" is a calendar day
> when the user makes one or more edits.
>
> Frequently Edited Article : An article in the main
> encyclopedia namespace that has been edited more
> than 5 times in the last 48 hours.
>
> ==== Policy ====
>
> On the English Wikipedia, neither Rookies nor IP
> users are permitted to edit Frequently Edited
> Articles.
>
> === PART TWO ===
>
> To aid in enforcement of hard bans, Wikipedians may
> list any user on [[Wikipedia:Petitions for users of
> concern]], thus starting a petition.  Criteria for
> listing a user are: controversial edits and a belief
> that the user may have been banned previously.
> These are subjective criteria and Wikipedians are to
> use their best judgment.  When there are eight or
> more Wikipedians in support of the petition
> (regardless of how many may be opposed), the user
> must demonstrate their real-world identity to the
> Wikipedia Bureaucracy within 10 days; if they do not
> do so, their editing privileges are suspended until
> they do.
>
> The Wikipedia Bureaucracy will validate identities
> using sensible but effective methods, such as
> requiring a $1 donation via paypal or personal
> check, or returning a form sent to the user's postal
> address.  The identity check will be used to
> determine whether the user is previously banned, and
> will be used to enforce a future ban if one should
> become necessary.  Otherwise, it will remain
> confidential.
>
> To discourage misuse, we may want to exempt
> Wikipedians who have been editing for, say, more
> than six months from the process.
>
> ---
> UninvitedCompany
>

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


from_name: Timwi

subject: [Wikitech-l] Re: Faster parsing

body:
Tomasz Wegrzanowski wrote:

> Mirroring is the biggest *disadvantage* of MySQL solution.
> UseMod wikis are extremely easy to efficiently mirror via rsync,
> and it was done with Phase I too. It was even easy to mirror it
> in "almost real-time" (like once an hour or so) over very small pipe
> (I did mirror Polish Wikipedia like that on 115kbit/s, and it took
> only small part of my bandwidth).

There is MySQL replication. I don't know much about it though (nor do I
know much about rsync other than what it's used for), so I don't know.

> MySQL can only produce full dumps, and they are huge, take lot of time
> to generate, and lot of time to import at the mirroring site.

I suppose I could argue that you could couple this with CVS, which can
produce patches to the dumps, but that's getting hacky :-)

> As far as queries are concerned, you can see it yourself on the Special Pages -
> most of the queries are turned off for performance reasons, so that's
> not really a good argument.

Ah, but that's not an indication that MySQL, or RDBMS in general, is a
bad idea. I just shows that the current database schema is ill-designed.

> And we need to update the data structures all the time for performance reasons.

I'm not sure I fully understand what you mean by this. Apparently we do
update something like the "recentchanges" table on every edit, because
some people seem to have thought that it would make for better
performance, but I'm pretty much convinced that this assumption is
fallacious. Updating that table on every edit, I believe, is more costly
than the benefit it brings in reading it. I'll gladly let an expert
correct me on this, but this is what my past experience told me.

Timwi


subject: [WikiEN-l] [plautus@shaw.ca: been doing some thinking]

body:
Alpha Eagle, meet me at Aleph Echelon, the bird has landed, I repeat,
the bird has landed.

:-)

----- Forwarded message from Plautus Satire <plautus at shaw.ca> -----

From: Plautus Satire <plautus at shaw.ca>
Date: Fri, 27 Feb 2004 21:17:03 +0000
To: jwales at bomis.com
Subject: been doing some thinking

This is what I've got so far, in no particular order:

o - At least some if not all sysops have an alternate ID. These ID's are
known to the sysop community but not advertised.

o - No attempts are made to proactively involve the community at large in
metadiscussion.

o - All sysops can communicate with each other using a back channel
consisting of an unrelated web page and encrypted, predefined signals.

Can you let me know how I'm doing so far? I'm just curious, if I'm close it
may impress my girlfriend.

----- End forwarded message -----


body:
Jimmy Wales wrote:

>o - At least some if not all sysops have an alternate ID. These ID's are
>known to the sysop community but not advertised.
>
>
To be fair, this one is partially true, as many sysops do have alternate
IDs.  However, the degree to which these are known to the "sysop
community" varies.

(This came up in the discussion of whether arbitrators should have to
disclose alternate IDs, in which it was eventually decided that they had
to disclose them to the other arbitrators, but not to the public).

As for the rest, all I can say is that the chromium plating is adjar on
en:2 Bomis seven, please advise.

-Mark


body:
I'm not sure what Ed's talking about, vis-a-vis the vote, but to be
clear, I kicked Plautus off the list on my own initiative because I'm
sick of his nonsense.

Please know that this guy is sending me many many many emails that I
can only charitably describe as perplexing.

He seems to think that somehow Disney is behind all this, among a
number of other interesting theories about people using pre-arranged
and encrypted signals, etc.

I can't make heads nor tails of it, to tell you the truth.  I just
wanted to stop flooding all the subscribers with it.

--Jimbo

Delirium wrote:

> Poor, Edmund W wrote:
>
> >The vote on moderation was:
> >
> >Support: RickK, Fred Bauder, Brian (Bcorr)
> >
> >Oppose: Eclecticology, Gareth
> >
> >The result was: Plautus was unsubscribed from the mailing list, not just
> >"moderated". He's name is off the subscriber list.
> >
> >Plautus cannot post here. He can only read the public archives on the
> >web.
> >
> >
> Isn't an informal 3-2 vote kind of a slim margin to kick someone off the
> list by?
>
> -Mark
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Gareth Owen

body:
"Poor, Edmund W" <Edmund.W.Poor at abc.com> writes:

> If a consensus develops that P. is flooding the list, and enough people
> insist, I can turn on the moderation flag for any user.

Please don't.

The last thing his persecution complex needs is some actual persecution.

Those people who don't want to read his emails and don't know how to configure
their software so they don't have to can use this as a valuable learning
opportunity.
--
Gareth Owen
"The best lack all conviction and the worst are full of passionate intensity"
                  --  W. B. Yeats forsees the standard of debate on wikipedia-l


from_name: Tim Starling

subject: [Wikipedia-l] Re: Mapping complement to Wikipedia?

body:
Jeff Meyer wrote:
> Hi all -
>
> Has anyone looked into or heard anything about a map-based complement to the
> Wikipedia?
>
> I am looking at putting something together that would be targeted at K-12,
> but might have some nice tie-ins.
>
> The plan is to deliver an easily searchable repository (content & searchable
> clearinghouse) of quality map content to cover the entirety of human
> history. Along with it would be a freely distributable, open source map
> player. People could then link their existing maps, add modifications, build
> new map content, etc.
>
> There are a lot of reasons why a text-based search metaphor doesn't work
> well for map-based data and why a lot of the maps on the web fall short of
> current technologies potential for delivering better map-based experiences.
>
> I am hoping to base this loosely on what the folks at TimeMap and the ECAI
> have already established, but their current tools, setup, and content would
> need to be modified and expanded to be useful for K-12 education.
>
> Naturally, it would be great to provide contextual links to related web
> resources... like the Wikipedia.
>
> Anyway, if anyone has heard of something similar, or has any suggestions,
> please let me know.
>

Yes it's been looked into, see the wikitech-l discussion in September
2003, subjects "software for making maps", "map software", "Colors for
maps" and my own minor contribution "GRASS ( was: map software)".

http://mail.wikipedia.org/pipermail/wikitech-l/2003-September/thread.html

-- Tim Starling


body:
Jeff Meyer wrote:

> Anyway, if anyone has heard of something similar, or has any suggestions,
> please let me know.

Here's a few links I forgot to put in my last post:

http://meta.wikipedia.org/wiki/Maps
http://meta.wikipedia.org/wiki/Map_generator
http://meta.wikipedia.org/wiki/Geographical_data
http://meta.wikipedia.org/wiki/Wikipediatlas

-- Tim Starling


from_name: Tomasz Wegrzanowski

subject: Development Roadmap (was Re: [Wikitech-l] Re: Faster parsing)

body:
On Fri, Feb 27, 2004 at 09:45:50AM -0500, Evan Prodromou wrote:
> So, the words "1.2" have been batted around, but we've got some
> important features on the table for "future" consideration (e.g. the
> schema changes).
>
> I'm wondering if it's time to do a development roadmap and get an idea
> of what we want from 1.2, 1.3, 2.0, dot dot dot.

Have you hired some people to do work on MediaWiki ?
If not, such roadmaps aren't very useful - people will work on whatever they want.


from_name: wiki pedista

subject: [Wikitech-l] Johnny H. = Michael?

body:
Hi,

can somebody with access to the logs check if a user
in the Spanish wikipedia named Johnny H. is in fact
a banned user named Michael? Another user made the
accusation, but offered no proof.

AstroNomo/AstroNomer

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


from_name: Ivo Köthnig

subject: [Wikitech-l] Re: Faster parsing

body:
Am Freitag, 27. Februar 2004 14:42 schrieb Erik Moeller:
> Ivo-
>
> > I think the bottleneck is using a database mangement system (here mysql).
> > So my question is: What is the advantage of using it? As I understand the
> > toppic dbms is usefull for very structured redundant data.
>
> This is an eternal debate. You may want to look at MoinMoin, which stores
> all its pages in plaintext and still manages to be very powerful:

Woudnt it make more sence to store the pages in plaintext and just indexing
them in the db? What is the advantage of storing it in the db?

> Using a database allows us to run a set of highly complex queries to
> examine the relationships between articles and the metadata about
> articles. In fact we can even examine the relationship between articles
> and users (watchlist), or between the metadata of different articles
> (redirect status in "What links here").

This also can be done without a database. Of course in that case you have to
implement the needet datastructure and can not use sql-queries. This takes
more time to develop, but you are free to code whatever datastructure you
might think is the best. The try to emulate it by a db-structure can fail and
even if you it does not fail you are slower since you have all the
overhead-calculations the database produce since it wants to be as generell
as possible.

> All that would only be possible using ugly hacks without a database -- you

You only get ugly hacks if you don't think about your code before implementing
something.

> would effectively have to build your own mini-DB to store this metadata,
> and most text-based wikis do this. They get extremely slow when it comes
> to very basic stuff such as listing backlinks or doing a fulltext search.

Thats just a matter of using the right datastructure, independently from using
a db or not.

> Not on a small wiki, but on one of the size of Wikipedia. I have imported
> large datasets into TWiki etc., and many operations became practically
> unusable.

But the reason ist not that the use no database they just don't have the right
datastructure for the operations.

> The MediaWiki FT search has locking issues. It's very fast for a normal
> wiki, but for a huge one like Wikipedia it tends to get in a deadlock
> state. That's why we have to disable it on Wikipedia. Some other queries
> could also be made faster. Many of our queries have been optimized now and
> every single one should eventually return results with a response time of
> milliseconds.

There I have a question. Do we use SQL for queries or do we use directly the
relational operations (join, semijoin, projection etc [relations algebra])?
Is it possible to use that?

> It is a fallacy that a database makes things more complicated. It makes

I dont say this. It makes coding easier. But easy code is always slow...

> them much easier because you don't have to worry where to store something
> before implementing it. How do you want to store your user prefs, the

That is the only real argument for using a dbms. But than we have to ask
ourself: Do we want something slow and easy or something fast but more
complicated.

> redirect info, the recent changes table, the page history, always keeping
> quick access in mind? Usemod, Twiki etc. all use ugly hacks for that kind
> of stuff.

Jeah, the features are implemented fast and in consequence running slow.

> In short, a DB is faster, cleaner, and more convenient. We benefit from
> the thousands of man hours that the MySQL developers have invested in
> building a scalable, fast, powerful multi-user database instead of having
> to reinvent the wheel whenever we want to do something that goes beyond
> "show me that file".

Reinventing the wheel is a danger that always exists. But blowing up by trying
to be too general is anotherone. I still think we do not really need all the
features of the db. I think we need very few and this could be implemented
directly and thus be much faster... But on the other hand it may is to late
to change that again...

--Ivo K?thnig


from_name: Aluminum.Bavariati at epoptic.org

body:
> He seems to think that somehow Disney is behind all this, among a
> number of other interesting theories about people using pre-arranged
> and encrypted signals, etc.

BLU-97 A/B Arnett unclassified JPL chameleon man HAMASMOIS Exon Shell
MD4 pink noise event security 64 Vauxhall Cross White House government
counter intelligence Adriatic


from_name: Brion Vibber

subject: [Wikitech-l] Johnny H. = Michael?

body:
On Feb 27, 2004, at 16:04, wiki pedista wrote:
> can somebody with access to the logs check if a user
> in the Spanish wikipedia named Johnny H. is in fact
> a banned user named Michael? Another user made the
> accusation, but offered no proof.

The banned user known as Michael is just some jerk on AOL. There is no
clear way to track a single IP address or anything like that.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040227/e61f1ecc/attachment.pgp>


from_name: Nick Pisarro

subject: [Wikitech-l] Re: Code at the head branch seems to be broken

body:
Wikimedia developers <wikitech-l at Wikipedia.org> writes:
>Yes, a check for $wgEnableParserCache got lost in some recent
>refactoring. It wasn't noticed immediately since some of us have that
>table in our test databases. Thanks for the bug report, it might have
>taken a few more days to find and fix the problem without it.

Thanks for fixing this quickly so I could upload my few changes.

I actually keep the installed source on our own source control system,
with release, development, and "production" branches so I can merge
changes around in a controlled fashion.

Nick Pisarro


from_name: KNOTT, T

subject: [WikiEN-l] Re: recipes

body:
Wikibooks are jointly edited. You don't get a book each, thank god.(what
would be the point of that!) The whole point of wikibooks is the style
is different. A wikibook instructs the reader as well as inform them.
This means we have exercises with answers, advice on how to tackle
topics, subjects broken down into individual lessons etc. That's why I
think recipes are better off in the wikibooks cookbook.

Theresa

-----Original Message-----
From: Poor, Edmund W [mailto:Edmund.W.Poor at abc.com]
Sent: 27 February 2004 14:53
To: English Wikipedia
Subject: RE: [WikiEN-l] Re: recipes

There's nothing wrong with having a recipe for filet mignon in the
[[filet mignon]] article, or for [[scramble eggs]], etc.

"How to" articles can be neutral and informative.

It's only if we can't manage recipes due to edit wars that we would have
to resort to WikiBooks. Suppose Anthere wants to use lots of butter in
all her recipes, but Daniel (mav) prefers vegetable oil. To prevent a
fight, we could link to Anthere's Guide to French Cuisine and Daniel's
Healthfood Cookbook at Wikibooks.

I oppose deleting material from the Wikipedia, just because it fits an
identifiable category. The only "fork" I've seen so far that makes sense
to me is the dictionaries. There's a clear distinction between "defining
a word" and "writing about a subject". But there's nothing wrong with
describing the process of stirring eggs so the yolk breaks and mixes the
white -- unless you're a segregationist! ;-)

Ed Poor
_______________________________________________
WikiEN-l mailing list
WikiEN-l at Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Gabriel Wicke

subject: [Wikitech-l] moreri is down

body:
Moreri seems to be down, no ping, ssh, http.
--
Gabriel Wicke


from_name: Ray Saintonge

subject: [WikiEN-l] Re: Print edition

body:
limholt at excite.com wrote:

>--- On Fri 02/27, David Gerard < fun at thingy.apana.org.au > wrote:
>
>>It needs to be a separate branch, taking stuff from the trunk as it
>>sees fit. Tag it "Wikipedia Concise Print" or something.
>>
>----
>Why not make it equivalent to a language Wikipedia? We already have the 'Simple English' Wikipedia. The other language type link on an article could tell you the page had been selected (or moved).
>
That would be fine, although this project would probably need more
restrictive editing rights than the main Wikipedia, if it ever wants to
accomplish anything.

Ec


subject: [Wikitech-l] Re: Faster parsing

body:
Ivo-
> You only get ugly hacks if you don't think about your code before
> implementing something.

True. Go ahead, do a rewrite and show us how much better you can do with
text files. Or if you don't want to do that yet, try loading all of the
English Wikipedia (CUR and OLD) into MoinMoin and then try to mirror
MediaWiki's functionality in MoinMoin.

Really, this is not the place for philosophical discussions. Show us the
code, please.

Regards,

Erik


from_name: limholt at excite.com

subject: [WikiEN-l] Re: Print edition

body:
 --- On Fri 02/27, David Gerard < fun at thingy.apana.org.au > wrote:

>It needs to be a separate branch, taking stuff from the trunk as it
>sees fit. Tag it "Wikipedia Concise Print" or something.

----
Why not make it equivalent to a language Wikipedia? We already have the 'Simple English' Wikipedia. The other language type link on an article could tell you the page had been selected (or moved).

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


from_name: Geoff Burling

body:
On Fri, 27 Feb 2004, Jimmy Wales wrote:

> I'm not sure what Ed's talking about, vis-a-vis the vote, but to be
> clear, I kicked Plautus off the list on my own initiative because I'm
> sick of his nonsense.
>
> Please know that this guy is sending me many many many emails that I
> can only charitably describe as perplexing.
>
> He seems to think that somehow Disney is behind all this, among a
> number of other interesting theories about people using pre-arranged
> and encrypted signals, etc.
>
Great. All this time I thought I was contributing to something that
wouldn't get gobbled up by corporate culture, & now I find I'm just another
stooge for Disney, soon to be a Paul ("I made the Trailblazers a mediocre
NBA Team") Allen possession. I also expect anyday to find on every page
of Wikipedia a "This page best viewed in Internet Explorer 5.0."

(Okay, so the above was not very funny. At least I'm not the upteenth person
to repeat the obvious comment "I always suspected this was a Mickey Mouse
project" to the confusion of the non-USA people. ;)

Geoff


from_name: Robert Michel

subject:
[Wikipedia-l] > 230 request/second - but no Wikipedia news on
	slashdot ; ) what is this?

body:
Salve Daniel,

Am Donnerstag, 26. Februar 2004 19:00 schrieb Daniel Mayer:
> Note that our daily Alexa ranking has dipped into the 500s - our best daily
> showing ever.

*g*

BTW Why does Alexa do not rank wikipedia.org on their ranking of
Encyclopedias???
http://www.alexa.com/browse/general?catid=251&mode=general

rob


from_name: Fred Bauder

body:
Poor people have poor ways.

Fred

> From: Lars Aronsson <lars at aronsson.se>
> Reply-To: Wikimedia developers <wikitech-l at Wikipedia.org>
> Date: Sat, 28 Feb 2004 00:44:03 +0100 (CET)
> To: Wikimedia developers <wikitech-l at Wikipedia.org>
> Subject: Re: [Wikitech-l] Re: User-agent block list & Netscape 3
>
> Hunter Peress wrote:
>> Theres 3 main cases where someone has an old browser:
>> 3)They are in the third world.
>
> The only reason a country is in the third world is because they are
> completely clueless.  Why waste time on that?
>
> Or is there something wrong with this kind of argument? Perhaps it is
> the other way around: The only reason some websites fail to support
> old browsers is because the maintainers are completely clueless.
>
>
> --
> Lars Aronsson (lars at aronsson.se)
> Aronsson Datateknik - http://aronsson.se/
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


from_name: Angela

body:
 --- Robert Michel <news at RobertMichel.de> wrote: >
> BTW Why does Alexa do not rank wikipedia.org on
> their ranking of Encyclopedias???

They do, but it's under "Computers > Open Source  >
Open Content  > Encyclopedias" as opposed to just
"Reference  > Encyclopedias". This is the ODP's
classification, not Alexa's by the way.

http://www.alexa.com/browse/general?catid=502412&mode=general

Angela.

___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html


from_name: Erik Zachte

body:
Jeff, more links for inspiration:

The graphical finesses are not quite my taste,
but the animation is very informative:
History of US http://www.animatedatlas.com/movie.html

I love this site:
History of the 20th Century:
http://users.erols.com/mwhite28/20centry.htm
For instance this animation IMHO is very well done:
http://users.erols.com/mwhite28/samerica.htm

Erik Zachte


from_name: Agon S. Buchholz

body:
Tomasz Wegrzanowski wrote:

>> I'm wondering if it's time to do a development roadmap and get an
>> idea of what we want from 1.2, 1.3, 2.0, dot dot dot.

> Have you hired some people to do work on MediaWiki ? If not, such
> roadmaps aren't very useful - people will work on whatever they want.

Nobody forces anyone to do a fixed amount of work until a deadline ends
or whatever.

I think a roadmap would be a great help for all of us to make
development and prioritoes more transparent to ourselves and all users.
A short notice could point out that given dates of a planned release 2.0
are rough estimates and no "product announcement".

Regards, -asb


subject: [Wikitech-l] Linux 2.6.3

body:
Experimentally we've loaded 2.6.3 kernel packages onto coronelli, one
of the squid caches. If it dies completely, we can swap the IP back to
browne to take over. If coronelli reboots, it should revert to the
2.4.x it had before (hopefully).

If things seem positive and more performant, we'll upgrade the others
in turn.

I'm using the test packages for Red Hat 9 from:
http://people.redhat.com/arjanv/2.5/

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040227/92210458/attachment.pgp>


subject: [Wikitech-l] Re: moreri is down

body:
On Fri, 27 Feb 2004 16:53:06 +0100, Gabriel Wicke wrote:

> Moreri seems to be down, no ping, ssh, http.

Hm, zwinger was rebooted recently which left all Apaches with load
averages > 200. Moreri is up again, the vital services on zwinger as well.
--
Gabriel Wicke


from_name: Anthere

subject: [WikiEN-l] Re: recipes

body:
Poor, Edmund W a ?crit:
> There's nothing wrong with having a recipe for filet mignon in the
> [[filet mignon]] article, or for [[scramble eggs]], etc.
>
> "How to" articles can be neutral and informative.
>
> It's only if we can't manage recipes due to edit wars that we would have
> to resort to WikiBooks. Suppose Anthere wants to use lots of butter in
> all her recipes, but Daniel (mav) prefers vegetable oil. To prevent a
> fight, we could link to Anthere's Guide to French Cuisine and Daniel's
> Healthfood Cookbook at Wikibooks.

It is inaccurate AND pov to oppose French Cuisine (with butter) to
Healthfood Cookbook (with vegetable oil)

French Cuisine also use vegetable oil, animal fat, margarine, creme
fraiche...not only  butter

Besides, french people suffer less heart stroke and obesity than many
other culture, supposingly eating more "healthy" fat.

You made a great mistake in rejecting our charcuterie and foie gras.
Even though we all know it is just commercial war (I pick on your
Boeing, you pick on my GMO, I pick on you car sellers, you pick on my
foie gras, I pick on your Bush, you pick on my Chirac, I pick on your
Mac Donald, you pick on my fries), it was a *bad* move. Foie gras is
healthy food ! :-)

For a recipee

http://fr.wikipedia.org/wiki/Foie_gras

Anthere's Guide to French Healthy and Savory Cuisine


from_name: Daniel Mayer

subject:
[Wikipedia-l] WikiGIS perhaps? (was: Mapping complement to
	Wikipedia?)

body:
Jeff Meyer wrote
>The plan is to deliver an easily searchable repository (content & searchable
>clearinghouse) of quality map content to cover the entirety of human
>history. Along with it would be a freely distributable, open source map
>player. People could then link their existing maps, add modifications, build
>new map content, etc.

I happen to be finishing up my GIS credentials and geography/cartography degree
right now and was thinking about playing around with the free software GRASS
GIS program this summer. See http://grass.baylor.edu/ and the GRASS Wiki
http://grass.itc.it/wiki2/

It would be neat to tie GRASS into MediaWiki for map creation. I'll see if I
can get that to work later this year (at least for creating simple maps).

There is a whole bunch of public domain GIS data out there (mostly in the
U.S....). It would eventually be neat to have a place to do GIS editing on the
Internet to help maintain and extend those data. As it is, the public domain
GIS material created by the U.S. government is made into proprietary products
by GIS firms who clean up, extend, and then sell the data. AFAIK there is no
free content alternative.

WikiGIS perhaps? I better snag that one... Done.  WikiGIS.org and WIkiGIS.com
are reserved for the Wikimedia Foundation if and when the foundation wants
those domains.

Which reminds me, Wikimedia.org is about to expire... I better fix that.

-- Daniel Mayer (aka  mav)

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


subject: [WikiEN-l] Re: Print edition

body:
Delirium wrote:
>I think we need to split out versions somewhere else,
>because we're looking for concise articles, not full
>encyclopedia articles.  Simply marking [[World War II]]
>as "ready for print" doesn't do anything towards
>getting us a good one-to-two-paragraph summary of
>World War II.

Ideal Wikipedia news style would be to have the first section of an article be
a concise article in its own right. Then the process of creating a concise
version would be as simple as extracting the first section of each article
(excluding tables and images).

-- mav

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


from_name: sannse

subject:
[WikiEN-l] Re: Feminist agenda (was Arbitration progress report
	#6)

body:
Anthere a ?crit:

> > Any woman out there want a job?  No pay, lots of hassle, but
> > the potential for an occasional warm fuzzy feeling inside.
> >
> > --sannse
>
> warm fuzzy feeling ? My ... sannse, where did you find that ? :-)
>

I said /potential/

There's potential for me to win the lottery and become a millionaire too...

--sannse


from_name: David Gerard

subject: [WikiEN-l] Re: Print edition

body:
On 02/27/04 00:42, Ray Saintonge wrote:
> Timwi wrote:

>> So, someone wanna start [[Wikipedia:Articles selected for print]] as
>> well as [[Wikipedia:Print candidate articles]] (or [[Wikipedia:Vote
>> for inclusion in print]] or whatever)?

> I think it needs to be more systematic than that.

It needs to be a separate branch, taking stuff from the trunk as it
sees fit. See [[fork (software)]] and think of the process that led
to [[EGCS]] or [[Mozilla Firefox]] applied to Wikipedia: an internal
fork.

Tag it "Wikipedia Concise Print" or something.

- d.


subject: [WikiEN-l] No forks! (was: Re: Print edition)

body:
>Why not make it equivalent to a language Wikipedia?
>We already have the 'Simple English' Wikipedia. The
>other language type link on an article could tell you
>the page had been selected (or moved).

No offense, but this is a horrendously bad idea. We should instead focus on
adding a good category system and on writing articles in news style so that the
first section of each article is a concise article in its own right (I call
this the 'lead section').

I also think that Simple was a bad idea as well since the lead section can and
should be written in language that can be understood by an average person - no
special knowledge of the subject area should be required to understand the lead
section.

In addition, it would be nice to have the ability to mark particular versions
of articles as "ready for print" (via a sifter-like mechanism). Then when the
Concise Wikipedia script parses the database it would create concise articles
out of the lead sections of every article version that was marked 'ready for
print'. That would prevent any vandalism from entering the print edition.

Thus we have no forks and no freezing of Wikipedia articles. We could also
create an updated version of Wikipedia Concise with each database backup. Such
a thing would be great to have in a format that could be used by PDAs and palm
top PCs. Hm. MediaWiki Lite...

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


subject: [Wikitech-l] Re: Faster parsing

body:
On Feb 27, 2004, at 19:30, Lars Aronsson wrote:
> Timwi wrote:
>> This is three operations for something that can be done in one.
>> (Simply
>> insert a row into some generic table, 'articlerevisions' or somesuch.)
>> There is neither a reason for the cur/old split, nor is there a reason
>> for the 'recentchanges' table.
>
> Good thinking, could be worth trying.  However, you should consider
> that the number of edits is far smaller than the number of reads.
> And a read is a simple select from today's cur table.

The primary difficulty is with reads, not writes. We have a fair number
of operations that want to draw on both current and old revisions and
working with two tables split between current and old is very difficult
for that; it leads to uglier, more complicated, harder to maintain,
buggier code. (The writes are also buggier with the split. We had to
track down and fix a number of race conditions which could and did
destroy near-simultaneous edits, and others may remain.)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040227/ae6d08a7/attachment.pgp>


from_name: Caroline Ford

subject: [WikiEN-l] Hardbanned user HJ

body:
Hardbanned user HJ has returned under IP address 66.47.62.78

Has this person been unbanned? Should we be blocking/reverting them?

Caroline/Secretlondon


from_name: Ivo Köthnig

subject: [Wikitech-l] Re: Faster parsing

body:
Am Freitag, 27. Februar 2004 18:00 schrieb Erik Moeller:
> Ivo-
>
> > You only get ugly hacks if you don't think about your code before
> > implementing something.
>
> True. Go ahead, do a rewrite and show us how much better you can do with
> text files. Or if you don't want to do that yet, try loading all of the
> English Wikipedia (CUR and OLD) into MoinMoin and then try to mirror
> MediaWiki's functionality in MoinMoin.
>
My intention was not to start a
>
> Really, this is not the place for philosophical discussions. Show us the
> code, please.

My intention was not to start a philosphical discussion. I just want to know a
good reason to do things that way (using a dbms). Implementing the features
in MoinMoin would not be a good idea. There are just 2 options. Restart from
scratch or slowly transform MediaWiki. I would prefer the last option. Since
I dont have the time for coding I just can give you some thougts how to
handle or improve things. Get rid of the dbms is just one way. Using
relational algebra instead of sql is another (but since I dont know mysql
that good I even dont know if this option really exists).

What is about indexing all articles in the database but storing it in files?
that could help to hold the hole database in memory and thus also speed up
the software.

--Ivo K?thnig


subject: [WikiEN-l] Hardbanned user HJ

body:
Delirium wrote:

> Caroline Ford wrote:
>
>> Hardbanned user HJ has returned under IP address 66.47.62.78
>>
>> Has this person been unbanned? Should we be blocking/reverting them?
>
>
> From [[User:H.J./ban]]:
>
>        (in response to "Has the ban been lifted?")
> Jimmy Wales wikipedia-l at wikipedia.org Sun, 25 May 2003 12:07:20 -0700
> No, Helga is not welcome to edit any wikipedia, she is banned.  If she
> wishes to start again, the same offer stands as always -- she can
> email me and chat about it.
>
> ----
>
> So it would appear she's still banned, unless something has happened
> in the months since May '03.
>
> -Mark
>
I've blocked it for 24 hours. I didn't know whether there would be
uproar or not so I was cautious.

Caroline


from_name: Lars Aronsson

body:
Robert Michel wrote:
> BTW Why does Alexa do not rank wikipedia.org on their ranking of
> Encyclopedias???
> http://www.alexa.com/browse/general?catid=251&mode=general

Because dmoz.org doesn't list Wikipedia under
  Reference -> Encyclopedias,

but under
  Computers -> Open source -> Open content -> Encyclopedias,

and Alexa uses the categorizations of dmoz.org.

There is a symbolic link (@) from
  Reference -> Encyclopedias -> Open Source
to the category where one can find Wikipedia, but Alexa doesn't seem
to follow that link.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se/


body: <<< No Message Collected >>>


from_name: Martin Harper

subject: [WikiEN-l] Re: Proposal for dealing with reincarnations

body:
I support Uninvited's "Part Two" as a good thing. The donation or
returned form would work well. There are plenty of other reasonable
methods of demonstrating one's identity, so I'd expect everyone
could find one that was acceptable.

-Martin