body:
replace "tasted" with "tasked" my second para.

Also note that Nupedia would /not/ be an open wiki and
the /only/ editing on Nupedia would be to boil down
content for the paper version.

Nupedia would simply be a read-only mirror of just the
best of Wikipedia. Wikipedia would be where everything
is all the time and where the content creation
happens.

--mav

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


list: wikipedia-l

source: pipermail-mbox

from_name: Jake Nelson

subject:
Telling the whole story RE: [Wikipedia-l] Re: Press release :
	Logoputsch ontheFrenchWikipedia !

body:
I'd like to chime in in support of what Cunctator's saying. I've yet to see
an example of those given that isn't a clear case of what should NOT happen.
I would like to know about the Statue of Liberty in France, the Dutch
parliament's position on Iraq, and all of that, but I'm only good with
English.
Even if I thought that assuming anything based on someone's language was
other than a terrible idea, I'd say that the suggestions are opposite to
what we should be doing. If we assume that those who speak Dutch are in the
Netherlands, the people who'd read the Dutch Wikipedia already know quite a
bit about the Dutch parliament and its stance on Iraq, and moreover, know a
lot of the background. An English-language-only American might be interested
in why the Netherlands is doing whatever it is that it's doing, go to the
en:wikipedia, and not find anything about it, because it wasn't felt to be
of interest for en-ers.
Which is what this is, and I didn't see until I wrote that last line-
censorship. What's being suggested in the argument that the different
languages of Wikipedia should have different content is that some people,
because they don't think speakers of my language would be interested in a
topic, block our access to information on it. Sure, it's mild, and without
malice, but one thing I cannot abide is other people choosing for me what
information I should and should not be able to receive. Correspondingly, it
is a good act for someone to make information available to those who would
not otherwise have it- if I didn't believe that, I wouldn't be contributing.
(My biggest complaint against Wikipedia is WWIN.)
As such, I think that it is one of the most important contributions a user
can make to bring content across the languages wherever they're able to do
so. (I'm still a novice with any other language, or I'd do it myself. It
might go faster if I were ever trying to learn less than 5 at a time, heh.)

Not that I have any strong opinions about this or anything... ;)

-- Jake


from_name: Andre Engels

subject:
[Intlwiki-l] Differences in the language versions, was
	RE:[Wikipedia-l] Re: Press release : Logo putsch onthe FrenchWikipedia
	!

body:
On Fri, 12 Dec 2003, The Cunctator wrote:

> > Your ultimate goal is not mine. Farewell.
>
> I won't even get into that. The idea that slightly different ideas about
> what the perfect Wikipedia would be in the far future is enough to make
> you leave is, frankly, bizarre.

Perhaps. Of course we can have different goals, and that should not be
much of a problem as in the great majority of the cases the goals are
nevertheless in the same direction. But if it's going to be talked about
as "the goal of the project" rather than "my goal" - then I'm not so
sure any more whether I belong here.

> By the way, what I (and I suspect Ruimi) specifically mean by having
> universalism as a goal for Wikipedia is that my goal is for Wikipedia to
> be applicable or common to all purposes, conditions, or situations.

Very well, I can live with that. Or at least, I can live with the way it
has till now been implemented on Wikipedia.

Andre Engels


from_name: Green Mountain

subject:
[Wikipedia-l] Re: Press release : Logo putsch on the FrenchWi
	kipedia !

body:
Anthere wrote:

>
>
> Constans, Camille (C.C.) a ?crit:
>
>>> And this is not even mentionning that the proper way to write is the
>>> one suggested by the French Academy or the French Typographic Code.
>>> Perhaps Canada has a chance as well here, but I doubt a decree in
>>> Algeria about how to use french would be given much consideration :-)
>>
>>
>>
>> Difficult question too, i would like to know it works between
>> American People and british people ?
>
>
> More or less ok, I think. That is, if an article was written in
> british english, american people are supposed not to entirely rewrite
> it in american english. Same reversely.
>
>
>>> It is just another step. Dominancy over content, over style, logo :-)))
>>
>>
>>
>> Do you think we're really pov ? We're working to prevent that, I hope...
>
>
> We are working hard. But please read CK page.
> http://fr.wikipedia.org/wiki/Discussion_Utilisateur%3AC%E9r%E9ales_Killer
>
> CK is suggesting that it is perfectly ok to add to wikipedia that some
> words should preferably be used instead of others.
> We can laugh upon the aubette, but there are about a dozen other words.
>
> He says it is ok that wikipedia article contains that
> *"people should preferably use the word "batonnet ouat?" rather than
> "cotton tige""
>
> Okay. So ...
> 1) very few people use batonnet ouat?, the vast majority say coton tige.
> 2) it is a pov to say one word is better (preferable) than another. It
> is not wikipedia role to promote the usage of one word over the other
> 3) instead, we should attribute the opinion to someone, perhaps the
> Acad?mie Fran?aise, perhaps a Quebecois Office, but not wikipedia.
> Wikipedia should not say to people which words they should use,
> Wikipedia should reports the fact that people use one word more than
> another, and that French Decree xxx suggested that we should change
> our habit
> 4) Tarquin will add on top of that, that Wikipedia is not a
> dictionary, we are not discussing over words, but over concepts, hence
> it is not a good idea to have two articles, one for cotton tige, the
> other for batonnet ouat?, we all clean our ears just the same way, so
> one article is enough.
>
> That sounds simple ?
>
> Well, to me yes (though I still have not understood very well who
> supported the batonnet ouat? usage). Some people would undertand that.
> And others would not. Ok, so let's talk about it. And find to who we
> can attribute this opinion.
>
> Now, look at that discussion  page. What is happening ? Quiet
> conversation between Alvaro, FvdP and I. Ending by asking CK his opinion.
>
> What is his opinion ?
> 1) cotton tige is incorrect, batonnet aouat? is correct. That is final.
> 2) I am a very very nastly woman and because of me, he will quit
> Wikipedia
>
> Ok, what do happen then ?
> 1) People sooth him
> 2) I explain it is not a personal attack, but just a discussion over
> how we could better respect npov, so what does he think of above
> propositions, and who is the one saying "batonnet aoute" is better
> than "cotton tige" ?
>
>
> What is CK suggestion ?
>
> that instead we write that "in written language, usage of batonet
> ouat? is preferable to coton tige"
>
> Which changes nothing
>
> So we do discuss again. Meanwhile, there are a couple of very
> interesting exchanges on typographic rules
>
> Then what is CK answer, in an open letter to Tarquin and I
>
> 1) That I know only to be nice with PP
> 2) that he is a long-lasting professional (28 years old expertise on
> typography)
> 3) that the word comes from Belgium anyway
> 4) that the Acad?mie Fran?aise does not respect NPOV itself
> 5) that he will quit wikipedia because of me
>
> All arguments not being in the least a reason to go on writing that we
> should use the word batonnet ouate? rather than cotton tige.
>
> How reasonable is it to spent hours on such a trivial matter ? :-))))
>
>
>>> As a matter of interest, I would be curious to know how those
>>> internationals, that are split between wikipedias assume that. I
>>> find extremely disconcerting to see two parts of a "common" project
>>> being so different. It is a bit like that psychological disorder :-)
>>
>>
>>
>> Do you think we're really different ? I'm sure there's some probleme
>> as ours on en, de, nl, oc,   oups not oc, there's no yet enough
>> people :)
>
>
> Yes it is different Shai. Of course, there are problems on every
> wikipedia. But, I was trying to think about it, and on every single
> rule or usage I could think of, fr: and en: are different.
> We don't use the same rules to delete, or to undelete
> We don't use the same rules to name people sysops
> We don't put the interlanguage links in the same order or the same
> place I think
> We don't use page protection in edit wars the same way
> We accept or do not accept the same way foreign languages in articles
> The etiquette is different
>
>
>>> I hope this issue be solved Tarquin, because fr needs you badly.
>>
>>
>>
>> As I said, leaving is not a solution. Tarquin choose to leave, it's
>> his choice.
>> Athymik does it some weeks ago.
>
>
> And Elsios as well
> And where is Alvaro ?
> And how tired am I ?
>
> Indeed our choice.
> Leaving is not a solution for Wikipedia, but it might be a solution to
> us.
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>
>
If the article is about an American subject, it is ok to rewrite the
article in American English though.


list: wikien-l

from_name: Sheldon Rampton

subject: [WikiEN-l] Re: Neutrality and the "majority" view

body:
Geoff Burlin wrote:

>Frankly, I feel that the argument that corporations or businesses buy
>experts to support their POV all of the time has gotten worn to being
>threadbare. No inteligent professional is going to sell her/his credibility
>for a paycheck; what they are going to do is find an employer whose POV
>most matches their own. Much in the fashion no one who has doubts about the
>infallibility of the Pope will become a Jesuit. To ignore this is to
>promote an _ad hominem_ attack in disguise.

It's true that funding doesn't usually _create_ bias, as Geoff says.
Mostly what it does is _select_ and _amplify_ bias. However, that's
bad enough. A good example is the case of fen-phen, the diet drug
that was taken off the market after it was linked to heart valve
damage and other serious health problems in people who took it.
Wyeth-Ayerst marketed fen-phen through a company called Excerpta
Medica, which got paid $20,000 for each "scientific paper" that it
placed in medical journals promoting the drug. Excerpta then hired
ghostwriters to write the papers, and after they were written paid
respected university professors $1,000 to "edit" the articles prior
to publication. When the articles appeared in medical journals, the
name-brand professors were the ones listed as the authors of the
studies, and the ghostwriters' names didn't appear. After
Wyeth-Ayerst got sued by people whose health had been destroyed by
the drug, some of the name-brand professors got called as witnesses,
and in court they said that they didn't even know Wyeth-Ayerst was
paying for the studies; they thought they were simply being hired to
do some light editing on the side for Excerpta. They didn't see
themselves as "selling their credibility for a paycheck," but they
obviously didn't give much scrutiny to the articles either, yet they
didn't mind having their names appear as lead authors.

For even more egregious examples where "intelligent professionals"
clearly _did_ sell their credibility for a paycheck, look at the
tobacco industry's activities, which are extensive and notorious. In
one of my books, I wrote about the case of Gary Huber, who "built a
career for himself as one of the contrarian scientists who regularly
disputed the growing body of scientific evidence about tobacco's
deadly effects. Over the years, he received more than $7 million in
tobacco industry research funding, and although his reputation as a
'tobacco whore' cost him the nrespect of friends and colleagues, in
industry circles he was something of a star, hobnobbing with top
executives, fishing with senior attorneys and participating in legal
strategy sessions."

After my co-author and I submitted that passage to our editor, he
objected that we shouldn't be calling the guy a "tobacco whore" and
advised us to find a more polite phrase. We responded by sending him
documents in which Huber himself talks about his work for the
industry. A few years ago he had a change of heart and now testifies
as an expert witness _against_ the industry in tobacco liability
lawsuits. When asked the reasons for his change of heart, he pointed
to two events: the death of his own father from tobacco-related
cancer, and the advice of his daughter to dissociate himself from the
tobacco industry. Her exact words were, "Dad, you've got to be
careful. These guys are pimping you."

We pointed out to our editor that if the guy's own daughter thought
he was being "pimped" by the tobacco industry, we were certainly
justified in saying he had a reputation as a tobacco "whore." The
editor agreed, and the passage was published as we originally wrote
it.

I think the point Geoff is trying to make is that someone's source of
research funding isn't in and of itself proof that their research is
invalid. If that's his point, I agree with it. However, there is
plenty of evidence showing that research funding correlates
positively with bias, and for that reason funding should always be
publicly disclosed.
--
--------------------------------
|  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
--------------------------------


from_name: Peter Gervai

subject: [Wikipedia-l] Proposal: Introduce Editor Responsibilities?

body:
On Wed, Dec 10, 2003 at 03:46:39PM +0100, Andre Engels wrote:

> I'm not so sure about those 'checks and balances' of the wiki model. I
> know one article where I strongly feel that it is not NPOV because it
> presents the ideas of one historian as if they are established fact. But
> I don't dare get into a discussion or edit war about it, because it also
> seems clear that the person who put it there is more knowledgeable
> about the subject than me - and probably more knowledgeable than any
> other Wikipedian.

Maybe we do it differently. If I would meet such a problem I would do as I
usually do: creating a new section titled "other theories" or anything like
that, and there I would describe other, alternative or opposing theories. It
doesn't hurt the "official" theory but give possibly useful information. The
"knowledgeable" person have to (and should, anyway) accept is.

> I do intend
> it to say that the wiki model also is no panacea.

I am sure we all are aware of that. It's just that we think the wiki model
is probably as good as others, or even better. Nothing's said about its
absolute correctness I believe. (Btw even "official" "scientific" sources
contain bullshit sometimes. Even books. :) I just love [[Erzsebet Bathory]] (or
like that) article which is most probably completely based on work of fiction
providing it as facts. It has been covered by many books. Still, books
doesn't create facts. Or at least OTHER sources think so.)

> I guess I would like to see something like editors for an article,
> but in a more Wiki-like manner - that is, make it easier to become
> an editor, and also editors do not approve or disapprove edits, but
> only judge their value and/or that of the resulting article. This
> judgement could then be shown somewhere, either on the article page
> itself or on its edit page. Pages with high scores could be shown
> on some kind of "showcase" page, and would be more likely to get
> into version 1 than would be the case based on the importance of
> the subject alone, pages with low scores could be candidates for a
> full rewrite instead of the normal piecewise editing.

I don't really like this vision.

Maybe I can imagine a system where people can specify their background (they
can, user: pages) and vote on correctness of the article (oh, you say they
can, using talk:).

Oh, so it's already possible without castrating the wikiwiki concept? Great.
It's a communication issue then.

grin

ps: I hereby state myself as the greatest living authority on milk of
Betelgeusean Spot Cowlettes. So I can reject your additions on that article.
You may write an appeal to devnull at wikibuerocrazy.com. :-)


from_name: Erik Moeller

subject: [WikiEN-l] Brilliant prose rename brainstorm

body:
Ed-
> I think we ought to revive the concept of certification.

I proposed a few months ago that we should develop BP into our
certification system by ensuring that all links from BP point to specific
revisions of the articles they link to and that BP itself is protected.
That would make BP a "safe zone" where all links lead to trusted content
(granted, you could probably still get to goatse.cx within 3 clicks or
so).

But before we move further into that direction I'd like to streamline the
BP process, improve organization and build a culture of certification.
Picking a proper name for the BP page is an important part of that.

The idea that articles can have different degrees (or different
categories) of certification also has a certain appeal. But I prefer to
make small steps to a full-fledged certification system, so that we can
always turn around if something goes wrong.

Regards,

Erik


from_name: Ray Saintonge

subject: [Wikipedia-l] Happy Birthday Wiktionary

body:
For those who may not have noticed, Wiktionary has now been operating
for a whole year and has built up 30,269 entries during that time
Happy Birthday!!
Ec


from_name: GreenMountain

subject: [Wikipedia-l] Load balancing

body:
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20031212/f3c51b53/attachment.htm


list: wikitech-l

from_name: Brion Vibber

subject: [Wikitech-l] download.wikipedia.org

body:
On Dec 12, 2003, at 09:04, Alfio Puglisi wrote:
> Hello,
> download.wikipedia.org has been down since this morning. Maybe Apache
> wasn't restarted after the DB crash?

Back up.

-- 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/20031212/840a7638/attachment.pgp>


subject: [Wikipedia-l] wikinotes

body:
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20031212/077a54a0/attachment.htm


subject:
[Wikitech-l] Re: [MediaWiki-CVS] phase3/includes Skin.php, 1.52,
	1.53 SkinCologneBlue.php, 1.7, 1.8

body:
On Dec 12, 2003, at 14:05, evanprodromou at users.sourceforge.net wrote:
> Update of /cvsroot/wikipedia/phase3/includes
> In directory sc8-pr-cvs1:/tmp/cvs-serv22026/includes
>
> Modified Files:
> 	Skin.php SkinCologneBlue.php
> Log Message:
> Added default text for when uploading is disabled. Since this is the
> default for new installations, it's important to have this text handy.
>
> In addition, hid the "Upload file" link if uploads are disabled.

The problem with this is that we use $wgDisableUploads on en2, but we
want to show the Upload link (which redirects to en).

-- 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/20031212/86ae9f66/attachment.pgp>


from_name: Delirium

subject:
[Wikipedia-l] Permalink? was RE: [WikiEN-l] Brilliant prose rename
	brainstorm

body:
The Cunctator wrote:

>That reminds me...can we add a little <permanent URL for this version>
>at the bottom of the article pages?
>
>We can find the link to the archived copy of previous versions, but
>there's presently no way to make a hard link to the presently displayed
>version.
>
>That would be a very simple step in making Wikipedia usable as an
>"authoritative" resource, for one thing.
>
>It's also helpful for internal discussions if you want to have a
>discussion comparing different versions of the same entry.
>
>
Yes, this would be very helpful!  I've actually before gone in and made
zero-edits (rearrange whitespace or something) so that the "current"
version gets bumped into the history and I can refer to it specifically
in a talk-page discussion (as in "at least in the current version [1],
there is odd wording in the 3rd paragraph").  Would be much more direct
if the current version also was referenceable by a revision-number.

-Mark


from_name: Sascha Noyes

subject: [Wikipedia-l] Re: Load balancing

body:
On Friday 12 December 2003 10:33, GreenMountain wrote:
> I didn't realize that web access to my account was sending in
> html.  I'm sorry about that (i usually use something like pine
> to access the account form pop but im not at my box.  I don't
> know if it will send this in HTML now.  Is this text only?

Yip. The one sent at 10:26 is still HTML though.

Best,
Sascha Noyes
--
Please encrypt all email. Public key available from
www.pantropy.net/snoyes.asc


subject:
[Wikitech-l] Permalink? was RE: [WikiEN-l] Brilliant prose rename
	brainstorm

body:
On Dec 12, 2003, at 14:57, The Cunctator wrote:
> That reminds me...can we add a little <permanent URL for this version>
> at the bottom of the article pages?

Not yet; the tables have to be restructured for a proper revisions
table and the key number kept consistent across saves, renames,
deletions and undeletions.

-- 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/20031212/f01c380e/attachment.pgp>


subject: [Wikipedia-l] Re: wikinotes

body:
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20031212/3194aff5/attachment.htm


subject: [Wikipedia-l] Re: Load balancing

body:
I didn't realize that web access to my account was sending in
html.  I'm sorry about that (i usually use something like pine
to access the account form pop but im not at my box.  I don't
know if it will send this in HTML now.  Is this text only?

Sascha Noyes writes:
> Please don't post in HTML.
>
> Best,
> Sascha Noyes
>
> On Friday 12 December 2003 09:39, GreenMountain wrote:
>>
>> Is the load balancing on en the cause of the
>> slowdown? It seems that a lot of times, en2 might be down,
>> but en one will redirect me to en. The French wikipedia
>> never has the problems that en exhibits, so I don't see why
>> there couldn't be load balancing between all languages, with a
>> removal of en2.
>>
>>
Greenmountainboy
>>
----------------------------------------------------------------------
>>----------
Get your free 15 Mb POP3 email @alexandria.cc
>>
Click here ->
>> target="_blank">http://www.alexandria.cc/
>
> --
> Please encrypt all email. Public key available from
> www.pantropy.net/snoyes.asc
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
--------------------------------------------------------------------------------
Get your free 15 Mb POP3 email @alexandria.cc
Click here -> http://www.alexandria.cc/


from_name: The Cunctator

subject: [Wikipedia-l] Differences between languages

body:
> From: Toby Bartels
> The Cunctator wrote:
>
> >Much better said than I could.
>
> Thanks!
>
> >The only thing I'd say different is the
> >text of a single language can't be a perfect encyclopedia--only the
work
> >that exists in all languages is the perfect encyclopedia.
>
> Ah, but both of these are goals that we will always approach but never
> achieve.
> I strive to make Wikipedia (as a whole) the best encyclopedia
possible,
> and I strive to make [[en:]] the best Anglophone encyclopedia
possible.
> Neither will ever happen, but ''both'' are our goals!
>
> (Also the goal for [[fr:]] to be the best Francophone encyclopedia,
etc.
> But personally, I write almost exclusively on [[en:]].
> That is the ''individual'' Wikipedian's parochial interests.)

I've always been and will continue to be a strong advocate for
considering Wikipedia to be the multilanguage project.

I think it's perfectly fine for individual Wikipedians to have parochial
interests. But I think it is wrong for them to expect Wikipedia as a
community to promote parochial interests.

I know I'm on the losing side of this issue, but while ethnic groups
have given us lots of interesting cuisine, they've also justified a few
too many deaths for my taste.

And when we as a community promote the differentiation of the language
versions--as entire projects--based on assumptions of distinctly
different backgrounds and interests of the readership--we're
differentiating our community by ethnic groups.

You should take all of the above with the caveat that if I thought that
any differentiation by language was evil, I'd only work on the Esperanto
Wikipedia.

What I'm saying is that our goals as a community should be higher, more
neutral, less parochial, than our goals as individuals. Celebrate our
differences as individuals and celebrate our commonalities as a
community.


subject: [Wikipedia-l] wikinotes

body:
GreenMountain-

> the newer sparknotes. These are study guides for
> books.  (Especially usefull for old literature where the
> plot is confusing.  I would like to volunteer to start
> a "wikinotes," which summarizes the the contents of classic
> literature that users are likely to read in school.  I
> think this would not be a part of wikibooks though, as it is
> entirely different.

Why should such summaries not be included with the relevant Wikipedia
article? We have many articles about individual books or movies which go
into quite a lot of detail. Presently I see no need for a spin-off.

Regards,

Erik


from_name: Tim Starling

subject: [Wikitech-l] Re: slow downs

body:
Green Mountain wrote:
> Wikipedia usually runs very smoothly ans quickly, but there are some
> times (such as now), where wikipedia doesn not respond at all.  Why is
> this?
>
> Greenmountainboy

We're not sure why it happens. Sometimes apache freezes and we have to
manually restart it.

BTW please adjust your clock/timezone, you're posting from 5 hours in
the future.

-- Tim Starling


from_name: Ian Gilfillan

subject: [Wikitech-l] Afrikaans wikipedia localisation complete

body:
Hi

Just letting everyone know the Afrikaans wikipedia localisation has been
completed (http://meta.wikipedia.org/wiki/LanguageAf.php). I know we'll have
to wait, but it's ready to move onto the new software. I'm planning some big
publicity for it, and other SA languages after that, but for now we'll wait
until it's running smoothly on the new software.

thanks,
ian gilfillan


from_name: Magnus Manske

subject: [Wikipedia-l] wikinotes

body:
GreenMountain wrote:

> I am sure that most of you have have heard of cliffnotes or the newer
> sparknotes. These are study guides for books.  (Especially usefull for
> old literature where the plot is confusing.  I would like to volunteer
> to start a "wikinotes," which summarizes the the contents of classic
> literature that users are likely to read in school.  I think this
> would not be a part of wikibooks though, as it is entirely different.

I like it, but how is that so different from wikibooks? Start a page
"Wikinotes:Hamlet" there. Or "Wikinotes:Shakespeare", if they're really
brief summaries :-)

Magnus


from_name: Jakob

subject: [Wikitech-l] Re: Categories simplified

body:
Hi,

Perhaps i expect to much of categories but I still do not see the difference
between categories and other articles.

Evan Prodromou wrote:
> From a graphical level, part-whole implies a tree structure

This is only true for one type of part-whole-relationship. There is
Part-of-Time, Part-of-Space, Part-of-Belonging etc. With all this
posibilities you end up in a multiple hierarchy.

> OK. I took "dividing an article into subtopics" as "dividing an
> article into parts". I think there's ways that "subtopics" could be
> parts, and ways that "subtopics" could be members of a category.

No way. The difference between Part-whole-relationship and
instance-of-relationship is too slightly to bee recognized by a large community
in
the same way. In a short article about Northern Ireland there could be a chapter
about National parks of Northern Ireland (part-of). Somebody moves it into an
article of it's own. In short time there will be more than one parent of this
article (Irleand, National Parks, Conservation in the United Kingdom...).

Erik wrote:
> Category pages are not articles. Like talk pages and meta pages, they
> should be logically separated from articles, which has numerous benefits
> (easier searching/filtering, counting etc.)

If you mean articles containing *only* a list of other articles that are
categorized under the same topic you are right. But there are a lot of real
articles that *also* contain lists of subtopics. A quick example:

In [[en:Statistics]] there is a the following part "Some sciences use applied
statistics so extensively that they have specialized terminology. These
disciplines include:" and a list containing "Biostatistics, Business statistics,
Economic statistics, Engineering statistics, Population statistics,
Psychological statistics, Social statistics, Process analysis, Chemometrics".

I think most people would categorize these articles in [[category=Statistics]]
or [[category=Applied statistics]]. With your approach we?ll have

1.) an automatically generated page [[category:Statistics]] and
2.) the manually generated list in the article [[Statistics]]

That does not seem very smart. By the way an article can be categorized
in multiple topics so there may be multiple manually generated lists in
different articles that are only connected via normal links and some
category-pages.

If category-pages should get a different namespace like the Talk-pages there
will be a automatically generated category-page for each article. In most cases
It will be empty or small. There should be a way to include it's content in the
article for instance with something like {{MySubtopics}}

Greetings
  Jakob


from_name: Ruimu

subject:
[Wikipedia-l] Re: Differences in the language versions,
	was RE: Re: Press release : Logo putsch   onthe FrenchWikipedia !

body:
----- Original Message -----
From: "Anthere" <anthere8 at yahoo.com>
> > I have to say that on principle and as a matter of policy I strongly
> > disagree with Ray and Anthere. The overall goal *does* need to be that
> > each wp entry should be the perfect translation of the same entry in any
> > language.
> >
> > Each language version should *not* have its own special taste.
> >
> > As a matter of course the fact that languages are intertwined with
> > ethnicity, nationality, and modes of expression means that the same
> > content will be discussed differently in different languages.
>
>
> I must admit I see not how you reconcile the idea that an entry "should
> be a perfect translation" and the idea the content of an entry "will be
> discussed differently in different languages".

Different ways to reach the same top of the same mountain.

Even if fr: edit war customs are not the same as en: one (i.e. if and when
to freeze pages), the "theoretically perfect npov expression to be reached a
the end of times", or simply the npov "pivot" (if any, but we all need to
believe in its existence) is the same in both contexts, the same in any
context.

Sameness in rules and goals and differences in customs and ways is a matter
that goes far futher, I feel, but a simple small metaphor on how to reach
npov could be something like the LCM reduction, don't you think? I mean that
if something on a topic could not be understood or accepted by a given
"gentleman" from any other ethnic/linguistic/political/etc. context, it
should be removed. (Here "gentleman" stands simply for someone smart enough
and fair...)

Ruim'


subject: [Wikitech-l] Re: WikiTeX (for Chem formulas!)

references:
<brcvaq$6lt$1@sea.gmane.org> <8zijJLUSpVB@erik_moeller>
	<brdo3f$b0l$1@sea.gmane.org>

body:
On Dec 12, 2003, at 16:56, Timwi wrote:
> I dislike <nowiki> for the same reasons.

FWIW, we inherited <nowiki> from UseModWiki.

However <math> is our own invention and we shall pay for it in the next
WikiLife. ;) For extra confusion, <math> is the root element in MathML,
but our <math> is TeX-based. I think we ended up using it because no
one could agree on an obscure symbol to use or the exact semantics
thereof.

-- 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/20031212/e742efeb/attachment.pgp>


subject:
[Wikipedia-l] Re: Press release : Logo putsch onthe
	FrenchWikipedia !

body:
On Fri, 12 Dec 2003, The Cunctator wrote:

> > I see what you're getting at, but I'm not so sure that it's right.
> >
> > Consider an article on the [[Statue of Liberty]], which was a gift
> > from France to the United States.  Both articles will state that fact,
> > and give some details, but the French language article might quite
> > naturally and properly say more about some of the particularly French
> > aspects of the story.
>
> > Readers in different languages will have somewhat different
> > backgrounds and interests.  Different backgrounds mean that we must
> > take into account different assumptions on what the reader will
> > already be familiar with.  Different interests mean that we must take
> > into account different emphasis on what the reader will expect to
> > learn from an article.
>
> I'm not convinced that we should have as a goal that the articles
> reflect the biases of the readership. I would expect both entries on the
> Statue of Liberty to tell the complete story. I have trouble seeing this
> as anything other than a defense of provincialism.

I don't agree. "The full story" is always much too long to tell. Instead,
we give a summary of it. And that might well be different for different
languages. The Dutch page on [[Stabilisation Force Iraq]] has a separate
section on the Dutch presence in it, and the opinion of the Dutch political
parties on that subject. I'd expect the English language version to mention
that there are Dutch in SFIR, but not that it takes half of the first
paragraph, or the discussion in the Dutch parliament.

Likewise, in the above Statue of Liberty example, I'd expect that the French
version might more about the French reasons to give it, and the political
opinions about it, while the English version might tell more about the
reaction that the gift got in the U.S.

We cannot tell the whole story, telling the whole story is cumbersome,
unreadable and laughable. Instead, we have to summarize it. Give a good
deal of relevant information, so that at the end people actually get
informed. Information is more important than facts. And when deciding
at what level we are going to summarize, what would be better than to
watch at what our readership would _want_ to read?

Andre Engels


from_name: Timwi

body:
Hi there.

I'll just allow myself to jump into this discussion randomly.

Erik Moeller wrote:
>
> I would prefer to have the tags called
> <math>,
> <music>,
> <chess>,
> <chem>,
> <greek>

Can someone remind me why exactly we want pseudo-HTML tags? Personally,
I think it would make things more confusing because people who don't
know HTML well will start thinking this is real HTML.

How about something much more wiki-like:

	[math  x + y = z]
	[music  blah blah]
	etc.

Also faster to type because you don't need to duplicate the tag name in
the end tag.

Timwi


body:
> From: Erik Moeller
>
> It's not so much an Internet/paper distinction but a primary/secondary
> sources distinction. Errors being promulgated from one book to the
next
> happens on paper just as it happens online. A personal webpage may
well be
> a much better source for vital data than a biography written by a
third
> party, and that in turn may be a better source than a book that
briefly
> mentions the person in context.

That reminds me...can we add a little <permanent URL for this version>
at the bottom of the article pages?

We can find the link to the archived copy of previous versions, but
there's presently no way to make a hard link to the presently displayed
version.

That would be a very simple step in making Wikipedia usable as an
"authoritative" resource, for one thing.

It's also helpful for internal discussions if you want to have a
discussion comparing different versions of the same entry.

--tc


from_name: Alfio Puglisi

subject: [Wikitech-l] download.wikipedia.org

body:
Hello,
download.wikipedia.org has been down since this morning. Maybe Apache
wasn't restarted after the DB crash?

Alfio


from_name: Stan Shebs

subject: [Wikipedia-l] Re: Press release : Logo putsch

body:
Lars Aronsson wrote:

>The Cunctator wrote:
>
>
>Note that the rather famous city of Bristol only has 381,000
>inhabitants, while the city of Szczecin has 419,000, but how many
>English speakers know where Szczecin is?
>
You mean Stettin? (ducks)

:-)

Stan


subject: [Wikipedia-l] wikinotes

body:
Magnus Manske wrote:

> GreenMountain wrote:
>
>> I am sure that most of you have have heard of cliffnotes or the newer
>> sparknotes. These are study guides for books.  (Especially usefull
>> for old literature where the plot is confusing.  I would like to
>> volunteer to start a "wikinotes," which summarizes the the contents
>> of classic literature that users are likely to read in school.  I
>> think this would not be a part of wikibooks though, as it is entirely
>> different.
>
> I like it, but how is that so different from wikibooks? Start a page
> "Wikinotes:Hamlet" there. Or "Wikinotes:Shakespeare", if they're
> really brief summaries

Wikibooks is still very young.  We should make sure that we fully grasp
its potential before spinning off another project.  In some of these
cases a simple Wikipedia article may be adequate.

Ec


from_name: Brad Johnson

subject: [WikiEN-l] Nupedia?

body:
> From: Erik Moeller on Friday, December 12, 2003 4:45 PM
> Daniel-
> > Why not call it [[Wikipedia:Candidates for inclusion
> > in Nupedia]]?
>
> Please don't. Nupedia is dead as far as I am concerned, and the only
thing
> it lacks is a proper burial. Maybe we should create a page for it as
soon
> as the Wiki memorial site is up.
>
> Doing the certification within Wikipedia is the Right Thing:
<snip>

The basic difference of philosophy is whether one believes that the
certification process is entirely compatible with the goals of
constructing Wikipedia.

I don't believe that it is; I'm really not convinced that the goals of
constructing a dead-tree encyclopedia are entirely compatible with the
goals of constructing Wikipedia. In fact, I'm rather skeptical, and
believe that I've seen signs of how having people thinking about that
goal has led to deleterious effects on Wikipedia. That's why I think
that it should be a distinct project, with a distinct name. I think
"Nupedia" is a great name, but I'm not averse to a name with Wikipedia
in it. "Wikipedia 1.0", however, has implications that I dislike. A core
value of Wikipedia is its constant state of incompletion and lack of
hierarchical, rigid control; certififying versions goes against that
value.

You believe that it (the certification process) is compatible and
beneficial to the larger goals of Wikipedia. If that is the case, then
keeping it separate would not be the right choice.

Neither of us really knows, and there are plausible cases to be made on
either side. The only way to find out is to run the experiment.

*However*, when running concurrent experiments, it's good practice to
keep them apart.  Integration is usually more complex than keeping
things separate, not the other way around.

That said, I *do* think that we should do a better job of providing a
common meeting space for everything that already exists under the
Wikipedia umbrella.

For example, I think that you should only have to sign in once to the
system to be able to contribute to any of the separate parts. I think
that people should be able to integrate Recent Changes pages if they
wish. I think people should be able to integrate watchlists if they
wish.

Yes, we're talking a lot of coding that I'm not exactly jumping up to
offer to do, so I know how much my advice is worth. And I know we are
basically living in a codocracy (rule by those who write the software)
so if you go forward there's little I can do but carp. My advice is
meant in good faith.

Yours,
tc


from_name: Evan Prodromou

subject: [Wikitech-l] Re: Categories simplified

in_reply_to:
<1071244732.3fd9e5bccc47c@mail.tu-chemnitz.de>
	(jakob.voss@s1999.tu-chemnitz.de's
	message of "Fri, 12 Dec 2003 16:58:52 +0100")

body:
>>>>> "J" == Jakob  <jakob.voss at s1999.tu-chemnitz.de> writes:

    J> No way. The difference between Part-whole-relationship and
    J> instance-of-relationship is too slightly to bee recognized by a
    J> large community in the same way.

Hurgh.

OK, so, I realized what the difference between part-whole and
category-instance is. (Please see [[meta:Series of articles]] for what
I'm talking about, here.)

Part-whole, as I'm talking about it, is a relationship between
*articles*. category-instance is about *subjects of articles*.

There's not much utility in saying that a muffler is part-of a car for
us. We're not trying to do some kind of generalized
ontology. Wikipedia is not Cyc. We're trying to write human-readable
texts, and augmenting that with technology when possible.

But [[WikiBooks:French Lesson 1]] is
[[part-of=WikiBooks:French]]. It's a piece of the whole, and readers
(and downstream publishers) could benefit from having a definition of
that relationship.

Will anyone recognize it? Surely. If we use enhanced navigation (next,
prev, top, or the list idea as in [[meta:series of articles]]), people
will definitely be able to tell the difference between the part-whole
relationship of articles, and the category-instance relationship of
subjects.

~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: Oliver Brown

subject: [Wikipedia-l] curiosity

body:
What exactly is discussed on the mailing list that can't or shouldn't or
isn't discussed on wikipedia-proper?
-oliver


from_name: Erik Moeller

body:
Timwi-

> Can someone remind me why exactly we want pseudo-HTML tags? Personally,
> I think it would make things more confusing because people who don't
> know HTML well will start thinking this is real HTML.

If people want to learn HTML, they can go to [[HTML]]. XML-like constructs
in our syntax do not preclude them from doing so.

> How about something much more wiki-like:

> 	[math  x + y = z]
> 	[music  blah blah]
> 	etc.

I don't see how this is more wiki-like. Most wiki tags are only valid in a
paragraph or line context - that's why they don't need a clear ending
demarcation. When dealing with content that may span several pages, it's
nice to have a clear ending marker, and the added redundancy is not just
machine- but also human friendly. We also have <pre>, <nowiki> etc.

It also saves us lots of escaping should the not too uncommon character
"]" ever occur inside one of these constructs.

Regards,

Erik


subject: [Wikipedia-l] Re: Database server trouble

body:
Erik Moeller wrote:
> Brion-
>
>>Database server is down; it really, _really_ didn't like being asked
>>how many rows are in the old revisions table for the English Wikipedia.
>
>
> Who did that? And if it was a sysop query, why the hell are we still/again
> allowing those? That's like putting a big red "DoS me" sign on our server.

It came out of an IRC conversation. Roughly reconstructed:

Pakaran: Why are SQL queries disabled
Tim: Erik turned it off because someone ran "select count(*) from old"

*time passes*

Brion: Hey, that query really is slow

Reports of Wikipedia being down, not responding by SSH etc. then followed.

-- Tim Starling


subject: [WikiEN-l] Nupedia?

body:
> From: Erik Moeller on Friday, December 12, 2003 6:41 PM
> TC-
> > I don't believe that it is; I'm really not convinced that the goals
of
> > constructing a dead-tree encyclopedia are entirely compatible with
the
> > goals of constructing Wikipedia. In fact, I'm rather skeptical, and
> > believe that I've seen signs of how having people thinking about
that
> > goal has led to deleterious effects on Wikipedia.
>
See [[User:The Cunctator/Agglomeration]] and [[User:The
Cunctator/Deletionism]] for two trends that are beneficial to the goal
of creating a dead-tree encyclopedia but are harmful (imho) to
Wikipedia.


subject:
True neutrality is achievable? RE: [Wikipedia-l] Re: Press release :
	Logoputschonthe FrenchWikipedia !

body:
> From: Jimmy Wales
> The Cunctator wrote:
> > Do you believe that an article can be truly neutral?
>
> Yes, very much so.  Neutrality is an ideal, but it is an achievable
> ideal.
>
Please, show me the money.

Consider this point: the entire enterprise of science is designed to
allow/force people to produce truly neutral articles, and obviously it's
imperfect at best.

Creating a truly neutral article is equivalent to creating a truly
neutral map. It's just not possible.

Within the constraints of an accepted framework one can do a reasonably
good job (e.g. "If we accept this limited model of the world as being
true...") but we can't ever work within a truly neutral frameork.

--tc


body:
----- Original Message -----
From: "Anthere" <anthere8 at yahoo.com>
To: <wikipedia-l at wikipedia.org>
Sent: Friday, December 12, 2003 9:01 AM
Subject: [Wikipedia-l] Re: Differences in the language versions, was RE: Re:
Press release : Logo putsch onthe FrenchWikipedia !
>
> I must admit I see not how you reconcile the idea that an entry "should
> be a perfect translation" and the idea the content of an entry "will be
> discussed differently in different languages".

Different ways to reach the same top of the same mountain.

Even if fr: edit war customs are not the same as en: one (i.e. if and when
to freeze pages), the "theoretically perfect npov expression to be reached a
the end of times", or simply the npov "pivot" (if any, but we all need to
believe in its existence before editing) is the same in both contexts, the
same in any context.

Sameness in rules and goals and differences in customs and ways is a matter
that goes far futher, I feel, but a simple small metaphor on how to reach
npov could be something like the LCM reduction, don't you think? I mean that
if something on a topic could not be understood or accepted by a given
"gentleman" from any other ethnic/linguistic/political/etc. context, it
should be removed. (Here "gentleman" stands simply for someone smart enough
and fair...)

As I'm new here, I may have misunderstood some of the wk's goals but, again,
npov means to me that any specific context (dividing human beings in
categories) should be avoided as much as possible and, therefore,
universalism* is the main goal. If I'm allowed to spend a little bit more of
your time, I would say that an encyclopedia should divide only the "topics"
into parts, not the "audience". (That's theory. In practice, sure,
"audience" is always divided into languages and so on...)

Ruim'

* to answer also to Andre Engels, I don't think that "universalism" is
"telling everything about everything", but maybe only something like
"telling everything commonly accepted by "gentlemens" (LCM) about everything
that supports common acceptance" (my 2 fens)


from_name: Matt M.

subject: [Wikipedia-l] McLauchlin's Law

body:
> > > Do you believe that an article can be truly neutral?
> >
> > Yes, very much so.  Neutrality is an ideal, but it is an achievable
> > ideal.
> >
> Please, show me the money.

McLauchlin's Law: As a thread on Wiki-L increases in length, the chances
that it will turn into a debate over the possibility of NPOV approach 1.

Matt M.
(Montrealais)


subject:
[Wikipedia-l] Re: [Wikitech-l] Permalink? was RE: [WikiEN-l]
	Brilliant prose rename brainstorm

in_reply_to:
<8zmjTZ7xpVB@erik_moeller> (Erik Moeller's message of "13 Dec
	2003 00:17:00 +0100")

body:
>>>>> "EM" == Erik Moeller <erik_moeller at gmx.de> writes:

    EM> One thing that I also think might be useful for the
    EM> certification process is to have some kind of flag that can be
    EM> assigned to certain revisions to mark them as stable, only by
    EM> sysops (...)

How about [[status=stable]]?

~ESP

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


subject: [Wikitech-l] Illegal page title

body:
Hello,
on the just-converted it: wikipedia we found an article that we would like
to delete, but that we are unable to access by the usual web interface.
The title is "''A. Alba'' Miller", and the four quotes are probably
screwing up any SQL statement. With a SELECT i found that its cur_id is
5430.

We don't have direct write access to the database. Can a developer please
delete that article?

Thanks,
Alfio


from_name: Brion Vibber

subject: [Wikitech-l] Re: Proposed table restructuring

body:
On Dec 12, 2003, at 20:22, Lars Aronsson wrote:
> You can still store a copy of each text (cur) in the database, and use
> that for searching.

We do this anyway, since InnoDB tables don't support fulltext search,
and the search text has to be pre-processed to strip markup and fix up
encoding. Further decoupling would not really change the search system.

As far as atomic operations; if we were to use the filesystem to store
page text, the safest, simplest thing would be to name the files based
on the unique revision identifiers (which we don't have yet due to the
way the cur/old split works). The textual content of a given revision
should never change (save perhaps being compressed), and the metadata
(title, user name, comment) can still be easily worked with in the
database. Rename and deletion operations would not actually have to
touch the files.

The trick would be making sure that the numbers really stay unique; you
need to add a row to the table to get its ID number back, and then
ensure that the data actually gets written to the filesystem before
anyone asks for it.

Relying on both a database and a filesystem for persistent storages
means you need to maintain two ways to connect if you're going to have
multiple web servers, of course. Also, this leaves us with a couple
million relatively small files, which the filesystem ought to be tuned
for (small block size).

> The vast amount of I/O over the database
> client-server socket is when every page view has to read the blob from
> the database to the (PHP) application, through the socket where the
> bandwidth might be limited.

The majority of page views should be cache hits which pull the output
HTML data from the local filesystem, checking the DB just enough for
cache validation. (I don't have exact figures at the moment, but we
should probably check.) We could make better use of filesystem or
memory-based caching than we do and decrease the DB load further.

-- 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/20031212/c2fd8cec/attachment.pgp>


from_name: Green Mountain

subject: [Wikipedia-l] Logos

body:
Is including an image of a logo a breach of copyright?  I saw
http://en.wikipedia.org/wiki/PalmOne and wondered about this.  I would
like to include the logo for Handspring Inc. . Will this be possible?

Greenmountainboy


from_name: Daniel Mayer

subject: [Wikipedia-l] wikinotes

body:
Ec wrote:
>Wikibooks is still very young.  We should make sure that
>we fully grasp its potential before spinning off another
>project.  In some of these cases a simple Wikipedia article
>may be adequate.

Yep. While Wikinotes is a neat name the goal of that proposed project is
already covered by the Wikibooks/Wikiversity mandate (which is pretty much
all non-fiction useable in the classroom except, of course, encyclopedias,
dictionaries and source texts - although we do plan to annotate source text
to act as study guide material).

Please start any "Cliff-Notes" type booklet on Wikibooks.

http://wikibooks.org/

-- Daniel Mayer (aka mav)


body:
Delirium-
> This is going to need more verification than just saying "yeah, this is
> a good article" though.  To be able to trust the content of any
> Wikipedia article, someone with knowledge of the field has to check up
> on the facts in reliable primary or secondary sources.  The vast
> majority of Wikipedia articles, as far as I can tell, currently draw
> their facts from the internet, which is filled with incorrect facts
> propagated from website to website.  Even things like birth dates are
> suspect, with it not being uncommon for a typo on a single website to
> propagate to others and eventually into Wikipedia.  So, to get something
> reliable, we need to find people who are willing to verify facts in
> libraries, not just in google.

It's not so much an Internet/paper distinction but a primary/secondary
sources distinction. Errors being promulgated from one book to the next
happens on paper just as it happens online. A personal webpage may well be
a much better source for vital data than a biography written by a third
party, and that in turn may be a better source than a book that briefly
mentions the person in context.

Also, of course, the Net has no barriers to publishing and the motivation
for doing so is often much different than on paper. So when dealing with
Internet sources we also need to consider the motivation and the nature of
the source more closely, and the more suspect they are, the more important
it is that they do their homework in terms of sources etc.

But we should not be snobbish towards any source. There is a trend in the
mainstream media to portray the Internet as a gigantic rumor mill with
little redeemable qualities - it's the competition, after all. The reality
is that its very openness has allowed vectors of research that were almost
non-existent before. What the Net lacks are universal mechanisms of
rating, public feedback and trust, largely because all attempts of
building them (Alexa, epinions etc.) were centralized dot-com schemes and
most open source people don't understand usability.

As for certification, in the long run we will want to certify an article
on several levels -- factual accuracy, quality of writing,
comprehensibility etc. But as I said, let's move slowly towards the
perfect scheme.

Regards,

Erik


subject: [WikiEN-l] Nupedia?

body:
Daniel-
> Why not call it [[Wikipedia:Candidates for inclusion
> in Nupedia]]?

Please don't. Nupedia is dead as far as I am concerned, and the only thing
it lacks is a proper burial. Maybe we should create a page for it as soon
as the Wiki memorial site is up.

Doing the certification within Wikipedia is the Right Thing:
- We want everyone who knows something to contribute immediately if at all
possible. An external website is an additional barrier to entry for doing
so. It's the bold "Edit this page" link that gets people into the wiki
process in the first place.
-> Even if some links are duplicated on the "stable" version, you would
effectively need a different user interface. When reading stable articles
on Wikipedia itself, on the other hand, people transparently learn to use
the UI, and can turn from reader to editor in seconds.
- It is terrible marketing to promote one brand at the expense of another.
By moving stable content to "that other site", we weaken the trust people
have in Wikipedia, which will always be much larger and more
comprehensive.
- In any case, it complicates all marketing operations significantly. It's
difficult enough to explain what a wiki is. The probable result would be
that we wouldn't even bother anymore to explain it and just point people
to the stable version. That in turn would reduce the influx of
contributors.
- By building a separate site with separate rules, we risk to alienate
Wikipedians who feel they do not belong to that project. A certification
process, in order to work properly, needs to be accepted and internalized
by the community.
- Community building is essential to the success of our project. The last
thing we need are more mailing lists, more points of entry, more
discussion pages. The worst case scenario is that separate communities
grow without talking much to one another.

The key argument, however, is that it doesn't give us a single advantage
we don't get with an integrated process. Things should never be made more
complex unless they have to.

Regards,

Erik


from_name: Ramanan Selvaratnam

subject: [Wikipedia-l] Logos

body:
On Sat, 2003-12-13 at 02:33, Green Mountain wrote:
> Is including an image of a logo a breach of copyright?

Not the best person to answer this but trademark is probably an
important consideration too.

Ramanan


subject: [Wikitech-l] Cache stats

body:
I've snuck some quick statistics calls into Article.php to count the
relative frequency of cache hits in page views.

In a few minutes on en:

** en **
Page views: 5420
Cache hits: 3322 (61%)
Cache misses: 98 (1%)
Client-side: 522 (9%)
Uncacheable: 1478 (27%)

Not half bad. Cache hits here are where it's able to pull a complete
pre-rendered page from the file cache and send it out. Cache misses are
where it can do caching, but has to (re)render the page this time.
Client-side caching is where the wiki is able to send a '304 Not
modified' response and the client uses a copy it's previously cached
locally. Uncacheable hits are old revision views, diffs, redirects, and
views by logged-in users that aren't client-side cached.

These figures won't include anything but page views (special pages,
editing, logins, etc).

I'll let it run and see if the ratios hold up during the day and with
the various languages.

-- 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/20031212/d3efa608/attachment.pgp>


subject: [Wikitech-l] Re: Categories simplified

body:
>>>>> "ASB" == Agon S Buchholz <asb at kefk.net> writes:

    ASB> If we do this consequently and editors accept it, this will
    ASB> have a nice side effect: we can add a function to print a
    ASB> {{catecory}}, or automatically generate a PDF file via PDFlib
    ASB> from a series of articles, containing everything Wikipedia
    ASB> knows about [[Biology]] (or whatever).

Heh heh! Well, that's my secret agenda: I want just this functionality
for Wikitravel. If you print (or download) the guide for [[Venice]],
it'd be nice to get a suggestion to download the [[Italy]] and
[[Italian phrasebook]] articles, too.

~ESP

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


in_reply_to:
<brdrtt$g17$1@sea.gmane.org> (timwi@gmx.net's message of "Sat,
	13 Dec 2003 02:01:30 +0000")

body:
>>>>> "T" == Timwi  <timwi at gmx.net> writes:

    T> Convinced yet? ;-)

I am! Great explanation.

~ESP

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


subject: [WikiEN-l] Nupedia?

body:
Erik wrote:
>...
>- In any case, it complicates all marketing operations significantly.
>It's difficult enough to explain what a wiki is. The probable result
>would be that we wouldn't even bother anymore to explain it and
>just point people to the stable version. That in turn would reduce
>the influx of contributors.

I've been basing this on the success of the distribution/project distinction
in the free software world where the end users benefit by a two mode process
(free software coders work on their own projects and the distributors put
that all together in a nice, easy to use and polished product, while making
sure that any improvements are incorporated into the free software projects).

However I do see the point that our end users are much more likely to become
contributors than are end users to free software due to inherent learning
curve issues in the coding world. But still, our stats indicate that there
are 30 views to each edit and I expect that ratio to increase as we become
more popular and more topics are filled-in and filled-out.

There will also always be a great many people who will not trust anything on a
wiki. So all this begs the question; are we here to make an encyclopedia for
the sake of making an encyclopedia, or are we here to make an encyclopedia
whose content will be used by and be most useful to, the greatest number of
people?

Having both stable and development versions of our content will make it most
useful to the greatest number of people. The best way to market that is to
make the distinction between the development and stable versions very clear.
IMO the best way to accomplish this feat is to host the stable content on
another domain with an interface that is optimized for content viewing.
Wikipedia, however, is optimized for content adding and editing - as it
should be.

Hosting the stable versions at Nupedia will slow down direct recruitment a
bit, but it will also greatly increase the number and quality of readers of
our content. A certain percentage of them will be interested in the
development end of our content and will enter the ruff and wild world of
Wikipedia to lend a hand. But most will just want of have reliable info. So
having a buffer between pure readers and editors should increase the average
quality of newbie editors.

Do we still need to be so oriented toward editing when we already have well
over 4,000 edits a day and nearly 200,000 articles? A slow-down in editing
and increased emphasis on getting things in stable form should become more of
a priority. IMO, the best way to market that - both internally and externally
- is by using nupedia.org to host the stable content.

Most people just want the reference material they use to fullfill their needs.
They can use Nupedia which would be optimized for them and their needs. Other
people are concerned about fullfilling the needs of the reference material.
They can use Wikipedia since it is optimized for them.
*Both will be joined at the hip yet have different specialties.
*Both will make it very clear their association with the other.
*Both will interoperate and encourage cross pollination.
*Both will be one click away from each other.
*Both win.

Is adding one single click to edit an article going to be that harmful weighed
against the marketing advantages of using Nupedia.org?

--Daniel Mayer (aka mav)


subject: [Wikipedia-l] Logos

in_reply_to:
<3FDA7A80.9080406@alexandria.cc> (Green Mountain's message of
	"Fri, 12 Dec 2003 21:33:36 -0500")

body:
>>>>> "GM" == Green Mountain <greenmountain at alexandria.cc> writes:

    GM> Is including an image of a logo a breach of copyright?

Logos are almost always copyrighted. Uploading them to Wikipedia is a
breach of copyright law which may be defensible under the fair use
doctrine, which see:

      http://fairuse.stanford.edu/Copyright_and_Fair_Use_Overview/chapter9/9-a.html

Whether fair use images are appropriate for Wikipedia is a question
for the ages.

    GM> I would like to include the logo for Handspring Inc. . Will
    GM> this be possible?

Better ask: will it be necessary? Is it worth violating the idea of
Free Content to have a curvy X with a circle at the bottom on some
page? If you really think the article needs an illustration, why not
draw a picture of a Visor yourself? Or take a photograph of someone
using one? Use some image you own the copyright to.

If you're insistent that only the corporate logo will do, you can
always ask PalmOne corporation if it's OK to license their logo under
the GFDL, of course:

     http://www.wikipedia.org/wiki/Wikipedia:Boilerplate_request_for_permission

~ESP

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


body:
Cunc-
> That reminds me...can we add a little <permanent URL for this version>
> at the bottom of the article pages?

Yeah, I wanted to add this but it's a bit tricky with the current CUR/OLD
setup so I might hold off until Brion reorganizes the DB, if he does. One
thing that I also think might be useful for the certification process is
to have some kind of flag that can be assigned to certain revisions to
mark them as stable, only by sysops (I probably shouldn't say this when
responding to Cunc ;).

Then you could have a special syntax that would always refer to the
flagged revision, like this: [[Caesar+]], pointing to the flagged revision
of [[Caesar]], or the top one if there is none. These would be assigned
after the certification process in community consensus, of course.

Advantage: Makes refreshing articles in BP much easier and allows pointing
to stable versions in any other context.

Regards,

Erik


body:
The Cunctator wrote:

>That reminds me...can we add a little <permanent URL for this version>
>at the bottom of the article pages?
>
>We can find the link to the archived copy of previous versions, but
>there's presently no way to make a hard link to the presently displayed
>version.
>
>That would be a very simple step in making Wikipedia usable as an
>"authoritative" resource, for one thing.
>
>It's also helpful for internal discussions if you want to have a
>discussion comparing different versions of the same entry.

Yes - this is a very good idea and should be enough while we argue in circles
about just how to set-up "stable" versions of Wikipedia content.

--mav


subject: [Wikipedia-l] Happy Birthday Wiktionary

body:
Ec wrote:
>For those who may not have noticed, Wiktionary has now
>been operating for a whole year and has built up 30,269
>entries during that time
>Happy Birthday!!

Wow - you guys have been busy. Good job!

--mav


subject: [WikiEN-l] Nupedia?

body:
Brad-
> I don't believe that it is; I'm really not convinced that the goals of
> constructing a dead-tree encyclopedia are entirely compatible with the
> goals of constructing Wikipedia. In fact, I'm rather skeptical, and
> believe that I've seen signs of how having people thinking about that
> goal has led to deleterious effects on Wikipedia.

Can you elaborate a bit on that?

Regards,

Erik


body:
Erik Moeller wrote:

>>How about something much more wiki-like:
>
>>	[math  x + y = z]
>>	[music  blah blah]
>>	etc.
>
> I don't see how this is more wiki-like.

Wiki means quick, doesn't it? :-) It's more wiki-like in the same sense
as ''this'' is more wiki-like than that.

> Most wiki tags are only valid in a
> paragraph or line context - that's why they don't need a clear ending
> demarcation. When dealing with content that may span several pages, it's
> nice to have a clear ending marker, and the added redundancy is not just
> machine- but also human friendly. We also have
, <nowiki> etc.

I dislike <nowiki> for the same reasons. (
, however, is actual
HTML, and there exists a wiki-syntax for it (beginning a line with a
space), so it's not actually needed in wiki-articles.)

> It also saves us lots of escaping should the not too uncommon character
> "]" ever occur inside one of these constructs.

You know, just after I submitted this I instantly regretted not having
included more options or added some clarification, because comments like
that were to be expected.

Firstly, the character "]" is rather unlikely to occur without a
matching "[".

Secondly, I was only giving an example. There is no reason why it would
have to be single square brackets. There are numerous ways to come up
with a better syntax than <math>...</math>. To alleviate the "clear end
marker" problem, you could use triple square brackets:
	[[[math  x + \left[\frac{y}{2}\right] = z ]]]
which is still way easier than <math>...</math>.

Furthermore, to even alleviate the problem of having to type "math" and
the added problem that that is anglocentric anyway, one could use
[[[...]]] for math, [{{...}}] for chem, [!!...!!] for music, etc.etc.

Greetings,
Timwi


body:
----- Original Message -----
From: "Jimmy Wales" <jwales at bomis.com>
To: <wikipedia-l at Wikimedia.org>
Sent: Saturday, December 13, 2003 12:14 AM
Subject: Re: [Wikipedia-l] Re: Press release : Logo putschonthe
FrenchWikipedia !

> > If NPOV is the same, then we shouldn't have as a goal articles which
> > reflect different biases.
>
> Yes, I do agree with this, but I think that there can be differences
> between article versions, even where both are NPOV.

Your split between backgrounds and interests is maybe helpful to
differentiate two kinds of adaptations that can be done to a given audience.
Take the example of [[Confucius]]. In the en: article, there are explanation
on some key words/concepts (Li, Ren, ...) that will not make so much sense
if purely translated into Chinese, I guess. Here the background differences
change the expression of the topic. So I'm not sure that both article
(en:Confucius and zh:Kongzi) could be expressed the same way, but, imo, they
should dive both to the same depth (I'm not arguing that it's always
possible to do so), because en: reader and zh: reader should be supposed to
have the same amount of interest in the topic. (Again, I may be wrong on WP
underlying goals, but I feel that "encyclopedic" POV is not only neutral,
but "universal", I mean here that any topic is interesting in this POV)


from_name: Agon S. Buchholz

subject: [Wikitech-l] Re: Categories simplified

body:
Evan Prodromou wrote:

> Will anyone recognize it? Surely. If we use enhanced navigation
> (next, prev, top, or the list idea as in [[meta:series of
> articles]]), people will definitely be able to tell the difference
> between the part-whole relationship of articles, and the
> category-instance relationship of subjects.

If we do this consequently and editors accept it, this will have a nice
side effect: we can add a function to print a {{catecory}}, or
automatically generate a PDF file via PDFlib from a series of articles,
containing everything Wikipedia knows about [[Biology]] (or whatever).

Process:

                         |
             Function 'Print {{category}}'
                         |
    (page listing all available articles in {{category}}
    with checkboxes to select/unselect certain articles)
                         |
                      Choose:
                        / \
      'Download PDF file'    'Print'
      (generates PDF file,  (generates one long,
      containing printable  well formatted HTML page for
      "booklet")            saving as file or printing)

This would also be the first step for a strcutured and printed
Wikipedia, as Jimbo suggested.

Nice ;)

Regards, -asb


subject:
[Wikitech-l] Mechanics for content templates and additional
	navigation hints

body:
Hi,

following the discussion about categories, I'm thinking about how to
make it easier to use for editors. Please remember, the Greatness of
Wiki is it's simplicity, and that's the reason for it's success.
Currently almost everybody is able to edit articles, but if we introduce
a complex taxonomy, or an ontology, or the edit box is filled with
near-semantic markup tags, this might change. Please, KISS! ;)

For a start: How about some mechanism, e.g. a pulldown menu, offering a
content template for a certain category? This could include an article
structure, some {{category}} related markup and maybe even some editing
help (comments, hints, etc.) which will be automatically removd when the
page is saved for the first time.

At the moment, several types of templates are mostly used as text
snippets in a certain context (e.g. template for biographical article,
template for a location, etc.); the appropriate templates have to be
located and applied to the article via cut/copy/paste - and the editor
has to know about the existence of a template for his article. Offering
a simple and easy-to-use mechanism might help the acceptance of
categories, especially when they are becoming more complex. E.g. in
Wikitravel, where some kind of article structure has been established
from the beginning; such a pulldown or other mechanics would help a
great deal, I think.

Also, if we start working not only with (more or less) one article (=
one page), but more with a series of pages in a {{category}}, we need
tools to better keep track of our movements in the 'pedia. I'd suggest
Breadcrumb Navigation (sometimes also called "Trail") for this; this
would indicate, which page we've vistited recently, and allow for quick
navigation. Several other Wikis have this implemented, so this mechanism
most probably will be understood well; it could be an optional element,
switched on or off via preferences.

Greetings, -asb


body:
Richards,Michael wrote:

> Surely most of the current queries done on the database are on cur:
> logged in and non-logged in users viewing and editing the most recent
> version of pages. Relatively few queries access old:

Every edit is a write-access to old *and* a write-access to cur.

Timwi


body:
Lars Aronsson wrote:

> Blob-like data can be stored on file
> instead, with only a filename in the database.

For reasons I don't understand, many people keep coming up with this
idea, but it's a really bad idea.

First of all, there is no reason to believe that reading from one file
out of thousands is any faster than reading one record in the DB out of
thousands. Secondly, it makes atomic transactions impossible. It makes
backing up a consistent state of the database/file-system mix virtually
impossible. It is too difficult to move data around without violating
the consistency of the construct. And lastly, it makes creating a
full-text search index quite a bit harder.

Convinced yet? ;-)

Timwi


from_name: Tomasz Wegrzanowski

body:
On Sat, Dec 13, 2003 at 12:56:12AM +0000, Timwi wrote:
> I dislike <nowiki> for the same reasons. (<pre>, however, is actual
> HTML, and there exists a wiki-syntax for it (beginning a line with a
> space), so it's not actually needed in wiki-articles.)

Wiki <pre> != HTML <pre>

<wiki-pre> = <html-pre><nowiki>


from_name: Lars Aronsson

body:
The Cunctator wrote:
> A few points: that's not what we do on Wikipedia. We write [[Macintosh
> OS X]] with the goal of writing it from an omniscient perspective for an
> unknown audience.

Sorry, this is plain nonsense, since the audience is not unknown.  We
know that the readers of the English Wikipedia understand English, and
this implies that they have already heard of Shakespeare (an English
playwright) and Bristol (a town in England).

To achieve neutrality, you would have to stop people on the English
Wikipedia from describing any details about cities or counties in
Pennsylvania and Ohio, because those details can be as irrelevant to a
Russian reader as are details about Russian places of the same size to
an English-speaking audience.  Since Russia and the U.S. are about the
same size (population anyway), you can only describe as many U.S.
cities as Russian ones, whether that is ten or a thousand.

Still, the existing (and natural) bias towards readers of the target
language can be an interesting observation.  One could make a list of
all cities of the world with a population of more than half a million,
only to make readers realize they easily recognize cities where their
language is spoken, while they've never heard of the other ones.

Note that the rather famous city of Bristol only has 381,000
inhabitants, while the city of Szczecin has 419,000, but how many
English speakers know where Szczecin is?

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


from_name: JFrost8401 at aol.com

subject: [WikiEN-l] Nupedia

body:
I completely agree with Mav. The emphasis now should be on improving the
quality, not the quantity, despite the views of some that every thing is valuable.

I would also discourage stubs, which are lazy, and expect others to do the
hard work

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20031213/9a45cf9b/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 4522 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20031213/9a45cf9b/attachment.jpeg


subject: [Wikipedia-l] curiosity

body:
On Sat, 2003-12-13 at 02:45, Oliver Brown wrote:
> What exactly is discussed on the mailing list that can't or shouldn't or
> isn't discussed on wikipedia-proper?

Definitely questions that new modules and langugaes face.

I never understood why most of the issues that relates to real world
(and which seemed like hell of a lot of noise to me) is not captured on
the wiki?

With new languages the issues of untested fonts, encodings, web browser
rendering etc limit our ability to use the wiki as effectively as in the
established ones in the begginning stages.

Maybe I am in the wrong list...

Ramanan


body:
Timwi wrote:
> First of all, there is no reason to believe that reading from one file
> out of thousands is any faster than reading one record in the DB out of

I agree that this is how it should be, but I have seen some real
systems where file I/O bandwidth was considerably higher than database
I/O bandwidth, even after tuning all buffer sizes and kernel
parameters.  I don't know if that is the case with Wikipedia's system
using PHP + MySQL in 2003, but it was the case with one system using
ASP/VB + MS SQL Server in 1999 and with another system using Java +
Oracle 9i in 2002.  In these years I made my entire living from
telling people they should avoid blobs, and everybody was happy with
the results.  The fact is that Wikipedia, using blob I/O extensively,
has been slow at times.  This could of course be a coincidence.

Now, much of the suspicion in these cases was drawn to the
implementation of the ODBC/JDBC/equivalent drivers for the database
communication, which are not open source in the case of Oracle and
Microsoft, so there is reason to believe that MySQL + PHP would do
better than the others.

> Secondly, it makes atomic transactions impossible. It makes
> backing up a consistent state of the database/file-system mix virtually
> impossible. It is too difficult to move data around without
> violating the consistency of the construct.

Correct, although not entirely relevant.  Atomic transactions is
nothing you rely on with MySQL anyway, data seldom moves, and for some
uses you can move the filename and let the file stay where it is.
I agree that these are drawbacks, but they are not necessarily worse
than the I/O bandwidth limitation.

"Database backup" is in general more complex than "file backup", and
the smaller the database, the easier it goes.

> And lastly, it makes creating a full-text search index quite a bit
> harder.

You can still store a copy of each text (cur) in the database, and use
that for searching.  The vast amount of I/O over the database
client-server socket is when every page view has to read the blob from
the database to the (PHP) application, through the socket where the
bandwidth might be limited.

> Convinced yet? ;-)

No, sorry, only a real test would convince me.  Right now Wikipedia is
fast, so nobody is going to test this.

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


subject: [WikiEN-l] Nupedia?

body:
Daniel-
> I've been basing this on the success of the distribution/project distinction
> in the free software world where the end users benefit by a two mode process
> (free software coders work on their own projects and the distributors put
> that all together in a nice, easy to use and polished product, while making
> sure that any improvements are incorporated into the free software
> projects).

That does not seem like a valid analogy to me. Wikipedia is neither user-
hostile nor is it, like a free software application, an isolated piece of
code that someone else needs to put together with other pieces of code.
Wikipedia *is* a distribution of articles, it *has* a structure, it is
easy to use. I've never heard anyone complain that they don't know how to
read Wikipedia. It's not the Linux kernel.

And where Wikipedia has usability deficits - it does - we should work to
correct them instead of trying to attract people to a more user-friendly
read-only version.

> There will also always be a great many people who will not trust anything on
> a wiki.

And we should confirm this irrational fear by pointing them to a separate
website? This would be very unfair. We should give people an opportunity
to learn. Wikipedia's success is based on overcoming these kinds of fears.

One way to do that is to create a safe vector of entry on the regular
Wikipedia, and to promote it prominently as such. What is now just an
inconspicuous link on the Main Page -- Brilliant Prose -- could eventually
be developed into its own navigational structure within Wikipedia, a
structure which allows people to easily absorb the wiki experience while
alleviating their initial fears.

Look at what you're saying: "Many people .. will not trust anything on a
wiki". A *wiki*? Most people have no clue what a wiki is in the first
place, and the few who do have an idea got it in the last couple of years.
We can *define* what a wiki is. We can *make* people trust us.

> So all this begs the question; are we here to make an encyclopedia
> for the sake of making an encyclopedia, or are we here to make an
> encyclopedia whose content will be used by and be most useful to, the
> greatest number of people?

On the Wikipedia Main Page, there are two big rectangles, a light blue one
and a light yellow one. The blue one has the title "encyclopedia", the
yellow one has the title "community".

The Wikipedia project is both, and that is a good thing. We are a learning
resource, and we should work to find ways to make that learning resource
more reliable and trustworthy -- hence this discussion. We are also a
knowledge community where people go to share their wisdom and ideas with
others, to philosophize, to argue and to ask questions. Pages like
[[Wikipedia:Reference desk]] come to mind, which is open for questions
from everyone, like a library help desk. But also the countless debates on
talk pages, which invite everyone to participate in intellectual
discourse.

If we try to grow in one area at the expense of the other, we will lose.
We need to nurture the mutually beneficial relationship between
encyclopedia and community, not undermine it. With a separate "stable"
website, there will be questions like: What are we going to promote --
contributing or reading? What are we going to do about negative
perceptions of Wikipedia -- correct them, or ignore them to promote
Nupedia? This is a path of self-destruction.

> Do we still need to be so oriented toward editing when we already have well
> over 4,000 edits a day and nearly 200,000 articles? A slow-down in editing
> and increased emphasis on getting things in stable form should become more
> of a priority.

There should be no artificial limits of our growth. That doesn't mean we
cannot work to make each aricle better, little by little.. There is
nothing wrong with always having a 10%/90% relationship between high
quality pages and works in progress.

There is also no fundamental difference between creating and improving
content. Growing our community benefits both. And any systematic effort to
focus on improvement over growth is not hindered by constantly recruiting
new editors.

> Most people just want the reference material they use to fullfill their
> needs.

"We are the info-elite, the ones who create and improve. The unwashed
masses can only consume. We must engineer a website that is useful for
these troglodytes to avoid confusing them with possibilities that their
feeble little brains will never understand!"

;-)

Let's be careful with assumptions about what people want or do not want.
Of course we should provide an easy interface for reading our articles,
and of course we should do everything we can to improve the quality and
reliability of Wikipedia. We should not pander to irrational fears,
however, at the expense of growing both our community and our
encyclopedia.

Wikipedia works because it's made of people. Separating the people from
the content they create is not a good idea.

Regards,

Erik


from_name: Fred Bauder

subject: [Wikipedia-l] curiosity

body:
Nothing, but operationally you reach the group who reads the lists, but
might not be following a particular discussion on Wikipedia.

Fred

> From: "Oliver Brown" <oliver at kingturtle.com>
> Reply-To: wikipedia-l at Wikimedia.org
> Date: Fri, 12 Dec 2003 18:45:24 -0800
> To: <wikipedia-l at Wikimedia.org>
> Subject: [Wikipedia-l] curiosity
>
> What exactly is discussed on the mailing list that can't or shouldn't or
> isn't discussed on wikipedia-proper?
> -oliver
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] curiosity

body:
Here's a URL to all the lists:

http://mail.wikipedia.org/mailman/listinfo

It strikes me that this list might be useful to you:

http://mail.wikipedia.org/mailman/listinfo/intlwiki-l

Which deals with "Wikipedia multilingual issues"

Fred

> From: Ramanan Selvaratnam <rama at ukfsn.org>
> Reply-To: rama at ukfsn.org, wikipedia-l at Wikimedia.org
> Date: Sat, 13 Dec 2003 16:26:17 +0000
> To: wikipedia-l at Wikimedia.org
> Subject: Re: [Wikipedia-l] curiosity
>
> On Sat, 2003-12-13 at 16:09, Fred Bauder wrote:
>> Nothing, but operationally you reach the group who reads the lists,
>
> lists in plural?
>
> Are there other lists I should scan for what I need to find out and/or
> keep up with.
>
> Again, my interest is to understand Wikipedia better to structure a
> newly started language module. There are few unanswered questions AFAIK.
>
> Ramanan
>
>>> From: "Oliver Brown" <oliver at kingturtle.com>
>>> Reply-To: wikipedia-l at Wikimedia.org
>>> Date: Fri, 12 Dec 2003 18:45:24 -0800
>>> To: <wikipedia-l at Wikimedia.org>
>>> Subject: [Wikipedia-l] curiosity
>>>
>>> What exactly is discussed on the mailing list that can't or shouldn't or
>>> isn't discussed on wikipedia-proper?
>>> -oliver
>>>
>>> _______________________________________________
>>> Wikipedia-l mailing list
>>> Wikipedia-l at Wikimedia.org
>>> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>>
>> _______________________________________________
>> Wikipedia-l mailing list
>> Wikipedia-l at Wikimedia.org
>> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


from_name: Sascha Noyes

subject: [WikiEN-l] Nupedia

body:
On Saturday 13 December 2003 02:32, JFrost8401 at aol.com wrote:
> I completely agree with Mav. The emphasis now should be on improving the
> quality, not the quantity, despite the views of some that every thing is
> valuable.

This is a common fallacy that people have about free software (or in this case
free content) development: One can't tell developers what to work on, unless
one pays them. Sure, one can try and encourage them to work on things, but in
the end they decide what to work on.

I'm not decided between mav and erik's approaches, but how exactly is having
"1.0" (or "nupedia", whatever) further removed from wikipedia (ie. on a
different domain) going to help in improving the quality of the content?

Best,
Sascha Noyes
--
Please encrypt all email. Public key available from
www.pantropy.net/snoyes.asc


from_name: Anthere

subject:
[Wikipedia-l] Re: Telling the whole story RE: Re: Press release :
 Logoputsch ontheFrenchWikipedia !

body:
Jake Nelson a ?crit:

> Which is what this is, and I didn't see until I wrote that last line-
> censorship. What's being suggested in the argument that the different
> languages of Wikipedia should have different content is that some people,
> because they don't think speakers of my language would be interested in a
> topic, block our access to information on it. Sure, it's mild, and without
> malice, but one thing I cannot abide is other people choosing for me what
> information I should and should not be able to receive. Correspondingly, it
> is a good act for someone to make information available to those who would
> not otherwise have it- if I didn't believe that, I wouldn't be contributing.
> (My biggest complaint against Wikipedia is WWIN.)
> As such, I think that it is one of the most important contributions a user
> can make to bring content across the languages wherever they're able to do
> so. (I'm still a novice with any other language, or I'd do it myself. It
> might go faster if I were ever trying to learn less than 5 at a time, heh.)

One action I thought very good is the following one.
An article about a rather little known french artist was posted on fr:
and en: some time ago. It was posted along with a handfull of articles
related to him.
For french people, he is rather obscure, for english people, he just
does not exist.
The article was listed on votes for deletion. But before deleting it,
the opinion of french people about the fame of the guy was asked.
Apparently, even though "nobody" for english people, people were ready
to keep the article if we "decided" to keep it as well (which we did not).

I thought that was a very positive move. The consideration the guy was
important to be included in english relied on his fame somewhere else,
for other people. Otherwise, Jack, you would only have a french version
to read. This would not be censorship, but definitly limiting access to
information.

Second point is that if google hits constitute a "certain" indicator of
  inclusiveness, they may not constitute the same indicator in other
languages less represented on internet.


from_name: Charles Matthews

subject: [WikiEN-l] Nupedia

body:
 JFrost8401 at aol.com wrote

<snip>

>I would also discourage stubs, which are lazy, and expect others to do the
hard work

Short articles in general, and some stubs in particular, are suitable ways
to develop some parts of WP; clearly depends on the topic area.

Charles

http://www.speakingasaparent.com/


from_name: Ulrich Fuchs

subject: [Wikipedia-l] Special:Allpages

body:
The Special:Allpages feature is disabled on the German Wikipedia (here called
Spezial:Allpages). There is no "saved copy" as indicated. Can we please
re-enable it (or at least make the saved copy work) , I use that feature
quite often and its' very prominentely linked from the german main page

Uli


subject:
[Wikipedia-l] Re: Differences in the language versions,
 was RE: Re: Press release : Logo putsch   onthe FrenchWikipedia !

body:
Ruimu a ?crit:
> ----- Original Message -----
> From: "Anthere" <anthere8 at yahoo.com>

> Different ways to reach the same top of the same mountain.
>
> Even if fr: edit war customs are not the same as en: one (i.e. if and when
> to freeze pages), the "theoretically perfect npov expression to be reached a
> the end of times", or simply the npov "pivot" (if any, but we all need to
> believe in its existence) is the same in both contexts, the same in any
> context.
>
> Sameness in rules and goals and differences in customs and ways is a matter
> that goes far futher, I feel, but a simple small metaphor on how to reach
> npov could be something like the LCM reduction, don't you think? I mean that
> if something on a topic could not be understood or accepted by a given
> "gentleman" from any other ethnic/linguistic/political/etc. context, it
> should be removed. (Here "gentleman" stands simply for someone smart enough
> and fair...)
>
> Ruim'

Sorry Ruim, but I do not know what is LCM reduction, so I can't think
anything about your comment.  Could you explain ?

Aside from this, I will perhaps mention that even though I understand
what you mean by "gentleman" in this context, I would LOVE that you
choose another expression to discuss the NPOV topic (to be fair ;-))

This said, my whole point *originally* was not to question either the
fact we are different, nor to question the fact you should approach
things differently or in the same way depending on which wikipedia we
work, but barely to state that the differences of approaches could be
very disconcerting to those working in two different places, and rather
mind splitting. Since no one than Tarquin reacted in saying he just had
the same problem, may I assume it is only the difference in approach
between fr: and en: which is problematic ? I dunno. But to me, that is a
big problem definitly.


from_name: Alfio Puglisi

subject: [Wikitech-l] Cache stats

body:
On Fri, 12 Dec 2003, Brion Vibber wrote:

>Uncacheable: 1478 (27%)
>
>locally. Uncacheable hits are old revision views, diffs, redirects, and
>views by logged-in users that aren't client-side cached.

Since this seems to be a significant fraction of the load, is there any
reason why old revision views and diffs aren't cached? They are not going
to change more or less forever, unless rolled back or something.

Ciao,
Alfio


body:
Lars Aronsson lars-at-aronsson.se |wikipedia| wrote:

> You can still store a copy of each text (cur) in the database, and use
> that for searching. The vast amount of I/O over the database
> client-server socket is when every page view has to read the blob from
> the database to the (PHP) application, through the socket where the
> bandwidth might be limited.
>
Can you elaborate on how performance problems caused by slow sockets may
manifest themselves? I executed the following query, which extract 17 MB of
blobs in 1.5 seconds (on a slow computer). Are you perhaps referring to
the general
slowness added by retrieving data over network connections instead of
using local files?

$ time echo "SELECT cur_text FROM cur"|mysql wikidb >/dev/null
real    0m1.449s
user    0m0.990s
sys     0m0.130s

//E23


from_name: Peter Gervai

subject:
SUBJECT LINE IS WHAT IT SAYS,
	was: Re: [Wikipedia-l] Re: Differences in the language versions,
	was RE: Re: Press release : Logo putsch   onthe FrenchWikipedia !

body:
Nice people,

Would you please change the subject when you change the topic? I usually
thread-delete all the "my NPOV is better than your NPOV" debates, and it's
not nice when someone changes a new, worthy topic inside somewhere
unnoticed.

Thanks!

ps: to start a new thread would be even better, but maybe that's too much to
ask. traffic is gettin too high, slowly reaching my unsubscribe threshold.


subject: [Wikipedia-l] wikinotes

body:
Daniel Mayer wrote:

>Ec wrote:
>
>
>>Wikibooks is still very young.  We should make sure that
>>we fully grasp its potential before spinning off another
>>project.  In some of these cases a simple Wikipedia article
>>may be adequate.
>>
>>
>
>Yep. While Wikinotes is a neat name the goal of that proposed project is
>already covered by the Wikibooks/Wikiversity mandate (which is pretty much
>all non-fiction useable in the classroom except, of course, encyclopedias,
>dictionaries and source texts - although we do plan to annotate source text
>to act as study guide material).
>
>Please start any "Cliff-Notes" type booklet on Wikibooks.
>
>http://wikibooks.org/
>
>-- Daniel Mayer (aka mav)
>
>_______________________________________________
>Wikipedia-l mailing list
>Wikipedia-l at Wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>
>
>
>
Cool!  Sounds good to me.

Greenmountainboy