subject: [Wikipedia-l] A quick thought about 1.0

body:
Andre Engels wrote:
> I apologize for this message. I'm getting overreactive again. Leaving
> this group now for personal reasons.

I thought it was fine!  Very well expressed, and not a personal attack
on anyone in any way.

I should say that although I tend toward the "completionist" viewpoint
myself, I think that the "deletionist" viewpoint has considerable
merit, and that there are in fact some very thorny questions of
reliability, respectability, usefulness, etc. on which the deletionist
viewpoint has much merit.

I should add again that I don't intend the terms "deletionist" or
"completionist" to be perjorative in any way.

--Jimbo


list: wikipedia-l

source: pipermail-mbox

from_name: Jimmy Wales

subject: [Wikipedia-l] A quick thought about 1.0

body:
Erik Moeller wrote:
> You may have fueled some of the tendencies Cunc describes by giving a
> rather vague idea of the "how" for Wikipedia 1.0 but giving more specific
> ideas about the "why", "what" and "when". So some people may feel that the
> very idea of 1.0 gives them license to delete more. If that is the case,
> we need a better plan. I for one would love to keep everything that is
> encyclopedia-related part of Wikipedia. I think Wikipedia's standards for
> inclusion are good the way they are, but there are legitimate
> considerations for a print edition.

I agree with all of this, including where you place the blame on me.
:-) This is an eloquent expression of what I set out to say in this
thread, that I think that this issue can in large part be resolved by
some "how".  Right now, the only "how" that people can think of is to
simply delete things that wouldn't belong in print, and this is
causing some friction here and there.

--Jimbo


from_name: audin at okb-1.org

subject: [Wikipedia-l] A quick thought about 1.0

body:
On Wed, Dec 17, 2003 at 12:25:32PM -0800, Jimmy Wales wrote:
> some "how".  Right now, the only "how" that people can think of is to
> simply delete things that wouldn't belong in print, and this is
> causing some friction here and there.

	[[Print: no]]

--
                                            Audin Malmin - audin at okb-1.org

The government, which was designed for the people, has got into the hands of
the bosses and their employers, the special interests. An invisible empire has
been set up above the forms of democracy.  -- Woodrow Wilson


from_name: Delirium

subject: [Wikipedia-l] A quick thought about 1.0

body:
Jimmy Wales wrote:

>I agree with all of this, including where you place the blame on me.
>:-) This is an eloquent expression of what I set out to say in this
>thread, that I think that this issue can in large part be resolved by
>some "how".  Right now, the only "how" that people can think of is to
>simply delete things that wouldn't belong in print, and this is
>causing some friction here and there.
>
>
I suppose I'm skeptical that this is a big part of it.  I personally
tend to suggest deletion of stuff primarily based on a viewpoint that it
doesn't belong in an online encyclopedia, not that it doesn't belong in
print.  Sure, more stuff belongs in an online encyclopedia, but I don't
think *everything* does.  Believe me, if I was basing it on print
considerations, I'd be nominating thousands of pages for VfD. =]

-Mark


from_name: Evan Prodromou

subject: [Wikipedia-l] A quick thought about 1.0

body:
>>>>> "JW" == Jimmy Wales <jwales at bomis.com> writes:

    JW> But I have this counter-thought -- while I do agree that the
    JW> idea of 1.0 has been causing people to do some things that I
    JW> don't really think are best, I think the solution to this is
    JW> to hurry up and actually implement a plan/software/whatever to
    JW> permit those who have deletionist tendencies (no insult meant
    JW> by the term!) to work on that.

I wonder if there's a way to use fields metadata:

  http://meta.wikipedia.org/wiki/Field-value_pairs

...to start tagging articles for 1.0. Say, "[[release=1.0]]" or
something.

~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: Brion Vibber

subject: [Wikipedia-l] Shirt / Wikipedia-Logo

body:
On Dec 17, 2003, at 08:44, Jimmy Wales wrote:
> On a related note, I was thinking of getting myself some new business
> cards and letterhead for the Wikimedia Foundation, using both the
> Wikipedia logo and the Wikimedia Foundation logo.  Where's the highest
> resolution version available?

Wikipedia logo without text, and some of the edges are a little sharp:
http://meta.wikipedia.org/upload/d/d2/Nohat-logo-XI-big.png

Not sure if there's a high-res Wikimedia Foundation logo around, but
it's nice simple shapes and could easily be redrawn in a vector format
if it's not already.

-- 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/wikipedia-l/attachments/20031217/025b0e26/attachment.pgp


from_name: Stan Shebs

subject: [Wikipedia-l] Wikipedia 1.0 or Wikipedia 2004

body:
Chuck Smith wrote:

>>Wikipedia is in the process of becoming a household
>>name.
>>I am confident that in a year's time it will be a
>>name that is as well
>>known as or better than Britannica and Encarta.
>>
>
>I just want to say that I agree completely.  We're in
>the process of branding a name here.  "Wikipedia 1.0"
>seems perfect to me.  It shows that it's stable and
>includes the same name.  "Wikipedia 2004" could also
>be used if we want to publish a new stable version
>every year like traditional encyclopedias.
>
In the Linux world, distributors have a brand name that they glue
on in addition to a version number, so "Red Hat Linux 8.0" is the
actual product you can get, and there's no "Linux 8.0" unless it's
a far-future kernel. :-)

So, ideas:
  "Wikipedia Pro 1.0"
  "Wikipedia Stable 2004"
  "Wikipedia Plus 1.0"
  "Best of Wikipedia 1.0" (BOW, but suggests "bow wow")
  "Wikipedia Select 2004"
  "Wikipedia Snapshot" or "Wikipedia Snap"
  "Bomis Wikipedia 1.0" :-)

For specialized products, longer names are good too:
  "Wikipedia Encyclopedia of Ships and the Sea"
  "Wikipedia's Math-o-Rama"
  "Wikipedia Games Compleat 2004"
  "The Wikipedia Tree of Life: a comprehensive encyclopedia
  of plants, animals, and protista"

Stan


list: wikitech-l

from_name: Toby Bartels

subject: [Wikitech-l] Re: WikiTeX

body:
Peter Danenberg wrote in part:

>See the documentation at http://69.44.153.14/wikitex_doc.htm for
>current blacklists; we'll continue to publish, as appropriate,
>module-specific blacklists.

I hope that you don't regard this list as complete,
even for the current <rend> classes.
For example, try the following input in the test page:

----

This properly is not accepted:

<rend class="math">
\input null
If you see this, then WikiTeX just inputted a file!
</rend>

But this should not be accepted either!:

<rend class="math">
\catcode `\| 0
|input null
If you see this, then WikiTeX just inputted a file!
</rend>

The solution (overkill, but simple):
Add \catcode to the blacklist.

----

(Luckily, the standard TeX file <null.tex> is completely empty,
except for some lines that begin with the comment character.
But for more fun, insert the line "\catcode `\% 12" as well! ^_^)

Besides checking with PlanetMath.org and arXiv.org
to catch anything that we didn't happen to think of,
somebody really should go through the proposed (La)TeX packages
with a fine-toothed comb to ensure that nothing has been missed.

If you're at the point where you're ready to develop
a complete blacklist for any or all <rend> classes,
then I will do this (assuming that you use only
standard packages whose source is available at CTAN).
Just let me know what (La)TeX code you use in the file,
other than the material between the <rend> tags.

(Possible example:)

----

\documentclass {article}
\begin {document}
\begin {equation*}
%s
\end {equation*}
\end {document}

----

(Although you're probably doing something a bit more sophisticated.)

Although if you want me to do that /right now/,
then you'll probably have to wait until 2004,
due to holiday effects on my schedule and Internet access.
^_^

-- Toby


from_name: Chuck Smith

body:
> Wikipedia is in the process of becoming a household
> name.
> I am confident that in a year's time it will be a
> name that is as well
> known as or better than Britannica and Encarta.

I just want to say that I agree completely.  We're in
the process of branding a name here.  "Wikipedia 1.0"
seems perfect to me.  It shows that it's stable and
includes the same name.  "Wikipedia 2004" could also
be used if we want to publish a new stable version
every year like traditional encyclopedias.

Chuck

=====
We are the Esperanto speakers who say "Ni!"
http://www.esperantomobilo.org/

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


from_name: The Cunctator

subject: [Wikipedia-l] A quick thought about 1.0

body:
From: Erik Zachte on Wednesday, December 17, 2003 4:40 PM

> Wikipedia is in the process of becoming a household name.
> I am confident that in a year's time it will be a name that is as well
known as or
> better than Britannica and Encarta.

> I think it would be too bad if we cause confusion by introducing a new
name for a
> printed edition. Imagine Britannica had called their online version
"Amerannica",
> what a waste PR wise.

PR should be a concern, but it should hardly be our first concern.

My opinion on the particular namings of things is somewhat formless.

All /I/ know is that I believe I have identified a trend of people
editing entries with an eye towards the print version, leading to (imho)
astoundingly long and digressive entries which try to fit all the
possibly relevant information on one page, with subtopics being
redirected into the omnibus--and to dislike the necessary and important
process of budding off detail into distinct entries.

Furthermore, I think that the combination of the natural inclination to
use the inclusionary criteria valid for paper encyclopedias (without
fully understanding the reasons for those criteria) and the inclination
among some to edit towards a print version of Wikipedia lead people to
overemphasize deletion as a tool.

It certainly may be the case that the promotion of "Wikipedia 1.0" has
nothing to do with this behavior, but unless I am mistaken there is a
pretty good overlap between those who are excited about and actively
pushing to have the "certification" process and paper version be part of
the Wikipedia project and those who actively delete pages and build
long, hierarchical entries and resist the creation of more specific
topics.

I could certainly be mistaken.

--tc


from_name: Anthere

subject: [Wikipedia-l] Re: NuPied ?

body:
Daniel Mayer a ?crit:

> Suggestions....? I like name 'Nupedia' because;
> 1) it is a brand we already own

true

> 2) we already control the .com and .org

true

> 3) while not as famous as the name 'Wikipedia', it still is known of by many
> people (over 40,000 hits on Google)

true

> 4) it is easy to pronounce

hummm...true

> 5) the 'nu/new' connection relates to the underlying concept (free content
> created by a worldwide community of voluntary authors), not its age (thus it
> will take the 'newness' a few hundred years to wear off - assuming that the
> free content movement really takes hold).

hummm....nupedia has nothing to do with "newness" but with "nakedness".

Let me think...living nake...is a sort of freedom...the freedom of not
following social norms, of being body free, caressed by soft wind,
perhaps free like a dolphin (or an orca ?) to play in the ocean ?

What does that means to me otherwise ?

Yes, the freedom of walking barefoot, without the fear of being cut by a
  broken coca cola can.

> However, what about the other Wikimedia projects? Should we try to buy-up
> other 'nu' domains? At first I thought it would be a great idea to have a
> Wikimedia-owned publishing house called "Numedia"  but alas that fine name is
> taken http://numedia.com/ (the .org is owned by somebody else). But 'Nubooks'
> would work (.org and .com available)... NumediaPublishing.org/com is
> available but that name is too long.

Nakesource
Nakedquote
Naketionary .... hummmm....why not.

....

NuPied !!!!!  Great name for a new project ?

Eclecticology, what do you think ?


body:
> From: Chuck Smith on Wednesday, December 17, 2003 6:20 PM
>
> > Wikipedia is in the process of becoming a household
> > name.
> > I am confident that in a year's time it will be a
> > name that is as well
> > known as or better than Britannica and Encarta.
>
> I just want to say that I agree completely.  We're in
> the process of branding a name here.  "Wikipedia 1.0"
> seems perfect to me.  It shows that it's stable and
> includes the same name.  "Wikipedia 2004" could also
> be used if we want to publish a new stable version
> every year like traditional encyclopedias.

There's a number of naming issues here; the name for the frozen version,
and the name for the project of creating that version.

In terms of naming the frozen version, I prefer Wikipedia 2004 to
Wikipedia 1.0.


body:
> From: Stan Shebs on Wednesday, December 17, 2003 6:44 PM
> So, ideas:
>   "Wikipedia Pro 1.0"
>   "Wikipedia Stable 2004"
>   "Wikipedia Plus 1.0"
>   "Best of Wikipedia 1.0" (BOW, but suggests "bow wow")
>   "Wikipedia Select 2004"
>   "Wikipedia Snapshot" or "Wikipedia Snap"
>   "Bomis Wikipedia 1.0" :-)

Or "Crippled, Frozen Wikipedia Suitable for Dead-Tree Distribution" if
you want to be more honest about it....

Put a frock on a pig, and it's still a pig.

:)


from_name: Andre Engels

subject: [Wikipedia-l] A quick thought about 1.0

body:
On Wed, 17 Dec 2003, Jimmy Wales wrote:

> Cunc has argued, correctly I think, that the idea of 1.0 may be
> causing people to delete things that really need not be deleted.  For
> this reason, he thinks it best to pursue 1.0 under a non-Wikipedia
> brand name, possibly Nupedia.

Any evidence for that, or is this just the so-manieth attack against
deletionism?

> But I have this counter-thought -- while I do agree that the idea of
> 1.0 has been causing people to do some things that I don't really
> think are best, I think the solution to this is to hurry up and
> actually implement a plan/software/whatever to permit those who have
> deletionist tendencies (no insult meant by the term!) to work on that.

In other words, I should just let Wikipedia rot because I want to remove
some things, and instead go to another project where a lot more deletion
is necessary.

> The idea is that Wikipedia can be *more* expansive once we have a 1.0
> "certification" process to keep people happy.  No one can argue "that
> doesn't belong in an encyclopedia" after that, because the simple
> response is "well, it may not belong in 1.0, but it's o.k. for
> wikipedia raw".

Well, I disagree with that. I want Wikipedia to be an encyclopedia. The
encyclopedia that 1.0 could have been had it had more space. I don't
want Wikipedia to be just a dumping place for information that someone
happens to want to write about.

> It's really the confusion between
> Wikipedia-the-always-in-process-website and
> Wikipedia-the-final-product-encyclopedia that causes the tension,
> isn't it?  Well, maybe not completely, but I think that a formalized
> 1.0 process would tend to prevent people from thinking of
> wikipedia-the-website as the sort of place where we need to limit
> ourselves to some finite number of topics.

Get lost!

Andre Engels


subject: [Wikipedia-l] A quick thought about 1.0

body:
I apologize for this message. I'm getting overreactive again. Leaving
this group now for personal reasons.

Andre Engels


from_name: Ramanan Selvaratnam

subject: [Wikipedia-l] A quick thought about 1.0

body:
Hi,

I am trying to get a understanding of this issues covered in this
thread.
But some  poor soul seemingly accepted this is far too much to look into
and unsubscribed. Dont wish this inquiry to end up like that.

I want to use the wiki to define UTF-8 adoption related issues in my
locale where there are already two non standard locales remaining far
too long after their time is up.
UTF-8 adoption it so happens goes hand in hand with free software.

This is the only way for my locale to be represented in a meaningful
way. Otherwise (as you might already know.. an economically deprived
domain brings social problems apart from IT access) the ill thought out
experiments by few in the ruling classes will rule over the the
information flow of future too.

With all due respect for the minds behind FDL and all, before you carry
on about  '1.0'  could i find out how  and what policies apply for i18n
aspects?

I was hoping to create enough info on i18n, very specifically on l10n
issues  and the accessories and issues related to translations as
priority tasks. Then there will be links to content like en:glibc,
en:iconv and external links like freedesktop.org.
Hope is such  a collections of concepts will be persistent like the
FOLDOC.

On Wed, 2003-12-17 at 17:33, Jimmy Wales wrote:

> The idea is that Wikipedia can be *more* expansive once we have a 1.0
> "certification" process to keep people happy.

I like this. This is will be useful for what I have in mind.

>  No one can argue "that
> doesn't belong in an encyclopedia" after that, because the simple
> response is "well, it may not belong in 1.0, but it's o.k. for
> wikipedia raw".

Regards,

Ramanan


from_name: Erik Moeller

subject: [Wikipedia-l] A quick thought about 1.0

body:
Jimmy-
> Cunc has argued, correctly I think, that the idea of 1.0 may be
> causing people to delete things that really need not be deleted.  For
> this reason, he thinks it best to pursue 1.0 under a non-Wikipedia
> brand name, possibly Nupedia.

I think that's a very bad idea, for the reasons I have given here:

http://article.gmane.org/gmane.science.linguistics.wikipedia.english/8910
http://article.gmane.org/gmane.science.linguistics.wikipedia.english/8916

I haven't seen Cunctator's argument and for now I don't buy it.
Individuals don't delete articles on Wikipedia, there has to be community
consensus. The only way that there would be consensus for increased
deletion is if it served some useful purpose, for example, "Let's delete
this because it can never be in a print edition." For filtering purposes,
however, it would be very simple to have a [[Category:Print]] tag (or
[[Edition=Print]] with a more complex scheme).

You may have fueled some of the tendencies Cunc describes by giving a
rather vague idea of the "how" for Wikipedia 1.0 but giving more specific
ideas about the "why", "what" and "when". So some people may feel that the
very idea of 1.0 gives them license to delete more. If that is the case,
we need a better plan. I for one would love to keep everything that is
encyclopedia-related part of Wikipedia. I think Wikipedia's standards for
inclusion are good the way they are, but there are legitimate
considerations for a print edition.

Regards,

Erik


subject: [Wikipedia-l] Re: A quick thought about 1.0

body:
Daniel Mayer a ?crit:
> Andre wrote:
>
>>Jimbo wrote:
>>
>>>...but I think that a formalized 1.0 process would
>>>tend to prevent people from thinking of wikipedia-
>>>the-website as the sort of place where we need to
>>>limit ourselves to some finite number of topics.
>>
>>Get lost!
>
>
> That was uncalled for. Why the hostility?

Have it easy on him Mav. Andr? is not feeling well these days :-(


subject: [Wikipedia-l] Re: NuPied ?

body:
Ray Saintonge a ?crit:
> Anthere wrote:
>
>> Daniel Mayer a rit:
>>
>>> 4) it is easy to pronounce
>>
>>
>> hummm...true
>
>
> Not necessarily.  Is it /noo-/ or /nyoo-/, not to mention /n?-/ which is
> a problem for English speakers.

Ah, but people will pronounced it differently depending on their
language. English perhaps noo ou nyoo, french n?.

Btw, I pronounced wikipedia : vikipedia, not ouikipedia.

Do not ask me why :-) It is totally illogical

>>> 5) the 'nu/new' connection relates to the underlying concept (free
>>> content created by a worldwide community of voluntary authors), not
>>> its age (thus it will take the 'newness' a few hundred years to wear
>>> off - assuming that the free content movement really takes hold).
>>
>>
>> hummm....nupedia has nothing to do with "newness" but with "nakedness".
>
>
> In the present age things don't stay new as long as they used to
> centuries ago.  MS-DOS is for dinosaurs, and it hasn't been around for a
> few hundred years.  The reference to nakedness is a natural French
> reaction that won't be obvious to unilingual English speakers -- it's an
> encyclopedia that brings us the naked truth. :-)
>
> I believe that its origins have more to do with the animal, the gnu, and
> free documentation licenses.

Yes, probably.

But, think of the slogan

Nup?dia, la v?rit? nue !

Marchez vers la v?rit?, avec Nup?dia !

Nup?dia, les all?es de la connaissance

>> Let me think...living nake...is a sort of freedom...the freedom of not
>> following social norms, of being body free, caressed by soft wind,
>> perhaps free like a dolphin (or an orca ?) to play in the ocean ?
>>
>> What does that means to me otherwise ?
>>
>> Yes, the freedom of walking barefoot, without the fear of being cut by
>> a  broken coca cola can.
>
>
> It makes me think of the movie "The Gods Must be Crazy". :-)

Don't know that title

Suspicious tone : is it again a Monty Python movie ?

>>> However, what about the other Wikimedia projects? Should we try to
>>> buy-up other 'nu' domains? At first I thought it would be a great
>>> idea to have a Wikimedia-owned publishing house called "Numedia"  but
>>> alas that fine name is taken http://numedia.com/ (the .org is owned
>>> by somebody else). But 'Nubooks' would work (.org and .com
>>> available)... NumediaPublishing.org/com is available but that name is
>>> too long.
>>
>>
>> Nakesource
>> Nakedquote
>> Naketionary .... hummmm....why not.....
>>
>> NuPied !!!!!  Great name for a new project ?
>>
>> Eclecticology, what do you think ?
>
>
> I must say that I don't have strong opinions on the name.  As an
> inclusionist, I'm more likely to be involved in the old Wikipedia than
> in the new 1.0 project.  There's always wikinu.org and if we want to
> look at other top level domains how about wiki.nu if it weren't already
> taken?
>
> E
> c

I do not have strong objections about the name either, I just wonder how
french people "hear" it, and whether they could find it utterly
ridiculous or not. If that sounds ridiculous, we will not published the
french version under that name I suppose. Or we will have double work to
sound serious. Depends...

Either cases, there are so many holes yet to fill in what interest me,
that I belong to the raw construction more than to the finition team :-)

This said, it is a bit bothering to hear
inclusionist -> wiki work in progress
deletionist -> wiki stable


subject: [Wikitech-l] GPL notification in source code

body:
Do we need to add the traditional GPL notification at the beginning of
source files?

~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: [Wikipedia-l] Re: Nupedia?

body:
Ruimu a ?crit:

>
> Post-Scriptum: In fact, I don't even know if the hardcopy version is to be
> multi language. I apologise if my proposal is off the road.

the first version  will be in english only. But it will be given a name

and since a name is not changed once used...we will keep the name for
the next versions

and the non english will just have to say amen

better to decide this all together before the first version ever


from_name: Ralesk Ne'vennoyx

subject: [Wikipedia-l] Re: NuPied ?

body:
Ray Saintonge wrote:
> Anthere wrote:
>> Daniel Mayer a rit:
>>> 4) it is easy to pronounce
>>
>> hummm...true
>
> Not necessarily.  Is it /noo-/ or /nyoo-/, not to mention /n?-/ which is
> a problem for English speakers.
>
    As for nupedia being something "new", well, I think Newyorkan (and
area) accent pronounces new as /noo/ [SAMPA n u: ]

> I believe that its origins have more to do with the animal, the gnu, and
> free documentation licenses.
>
    And we support some TeX markup, so might it also be a nice ad for
Donald Knuth? [d A n @ l d  k n u: T] :D

--
"Your job is being a professor and researcher: That's one hell of a good
excuse for some of the brain-damages of minix." (Torvalds to Tanenbaum)
--
Ralesk Ne'vennoyx
[ICQ:37046326]


from_name: Neil Harris

subject: [Wikipedia-l] A quick thought about 1.0

body:
Evan Prodromou wrote:

>>>>>>"JW" == Jimmy Wales <jwales at bomis.com> writes:
>>>>>>
>>>>>>
>
>    JW> But I have this counter-thought -- while I do agree that the
>    JW> idea of 1.0 has been causing people to do some things that I
>    JW> don't really think are best, I think the solution to this is
>    JW> to hurry up and actually implement a plan/software/whatever to
>    JW> permit those who have deletionist tendencies (no insult meant
>    JW> by the term!) to work on that.
>
>I wonder if there's a way to use fields metadata:
>
>  http://meta.wikipedia.org/wiki/Field-value_pairs
>
>...to start tagging articles for 1.0. Say, "[[release=1.0]]" or
>something.
>
>~ESP
>
>
>
We could also use this for brilliant-prose tagging and other forms of
article review...

[[prose-quality=0.7]]
[[accuracy=0.8]]
[[NPOV=0.9]]

-- Neil


subject: [Wikipedia-l] A quick thought about 1.0

body:
> From:  Delirium on Wednesday, December 17, 2003 4:17 PM
> Jimmy Wales wrote:
> >I agree with all of this, including where you place the blame on me.
> >:-) This is an eloquent expression of what I set out to say in this
> >thread, that I think that this issue can in large part be resolved by
> >some "how".  Right now, the only "how" that people can think of is to
> >simply delete things that wouldn't belong in print, and this is
> >causing some friction here and there.
> >
> I suppose I'm skeptical that this is a big part of it.  I personally
> tend to suggest deletion of stuff primarily based on a viewpoint that
it
> doesn't belong in an online encyclopedia, not that it doesn't belong
in
> print.  Sure, more stuff belongs in an online encyclopedia, but I
don't
> think *everything* does.  Believe me, if I was basing it on print
> considerations, I'd be nominating thousands of pages for VfD. =]
>
The whole question boils down to how people develop their personal
viewpoint of what belongs in an online encyclopedia.

Everyone to some degree, reasonably, forms that viewpoint based on
analogy to a print encyclopedia.

And I think the reasonable points of lessons to draw from paper
encyclopedias are in the standards of scholarship, tone, and
readability. These are lessons that are independent of media.

They also give a good sense of what was historically considered
important.

But it is not a good idea to draw too many lessons from the depth and
breadth of coverage and the structure of paper encyclopedias. These are
areas which are shaped by the constraints and strengths of the
particular medium of paper.

--tc


from_name: Dave Caroline

subject: [Wikitech-l] Dead and dying servers (en today)

references:
<brl5fc$dov$1@sea.gmane.org> <brcvaq$6lt$1@sea.gmane.org>
	<8zijJLUSpVB@erik_moeller> <brdo3f$b0l$1@sea.gmane.org>
	<20031215203416.GD8576@mitdasein.com>
	<20031215185157.GA3111@tavaiah> <brl5fc$dov$1@sea.gmane.org>

body:
Currently if en is down and en2 is working the casual user cannot easily do
anything useful because any attempt at using a special he will be pointed
to en also en2 get its images from en.

To fix it would seem sensible to mirror images on both or get images from
the new beast (link the file systems) and after being redirected to en or
en2 the defaults on those servers need to point at themselves not www. (fix
local settings?)

This would allow cleaner access for the user and less stress there is no
need to go to www every time (will reduce connects).

There seems to be a regular slow down early evening 6-8pm uk time.

We need a european timezone developer who can restart apache when this occurs.

Dave Caroline aka archivist


from_name: Erik Zachte

subject: [Wikipedia-l] A quick thought about 1.0

body:
Wikipedia is in the process of becoming a household name.
I am confident that in a year's time it will be a name that is as well
known as or better than Britannica and Encarta.

I think it would be too bad if we cause confusion by introducing a new
name for a printed edition.
Image Britannica had called their online version "Amerannica", what a
waste PR wise.

In my view people will be less confused when online and printed
Wikipedia differ in content under the same name.
Online Brittanica is also different from printed edition, because of
regular updates of the online version.

Erik Zachte

.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20031217/c226b0cb/attachment.htm


from_name: Yann Forget

subject: [Wikipedia-l] Re: NuPied ?

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

Hi Anthere and all,

Le Wednesday 17 December 2003 20:47, Anthere a ?crit :
> > It makes me think of the movie "The Gods Must be Crazy". :-)
>
> Don't know that title
>
> Suspicious tone : is it again a Monty Python movie ?

No. In French, the title is "Les dieux sont tomb?s sur la t?te".

Yann

- --
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/4NA3m4KYjQo0y9oRAhIIAJ9xDSak26/g8SzTWGaZOSnHiaab5wCeKboL
b83TbDySIwv7XZaaR4+Ga20=
=skbV
-----END PGP SIGNATURE-----


from_name: Walter Vermeir

subject: [Wikipedia-l] Re: Nupedia? -> No, Encyclopedia Galactica

body:
Ruimu wrote:
> ----- Original Message -----
> From: "The Cunctator" <cunctator at kband.com>
>
>>I think this is absolutely right, and is probably why I subconsciously
>>have been disliking the name "Wikipedia" for a hardcopy version.
>>
>>I personally think Nupedia is a good name for it, but if people can come
>>up with a better idea, then that would be great too.
>
>
>     Nupedia sound and look a little bit weird in French and maybe also in
> German. I would personally prefer a longer impressive latin sounding name (a
> little bit like "Encyclopaediae Universalis") to be on the jacket, and
> Nupedia could be the nickmane used day-to-day. Something like "Open
> Collaborative Hyperlinked Encyclopaedia" but, at best, N and U could be
> acronyms. ("Networked Universal Encyclopaedia" ?) (My two centimes)
>
> Post-Scriptum: In fact, I don't even know if the hardcopy version is to be
> multi language. I apologise if my proposal is off the road.

I like very much the name "Encyclopedia Galactica".

It is like the objectieve of Wikipedia "a collaborative project to
produce a free and complete encyclopedia in every language" , a very
bold name.

Walter


from_name: Peter Jaros

body:
Sorry if this is a doublepost...

In article <024b01c3c4f7$0398af10$74001c12 at reflection>,
  "The Cunctator" <cunctator-+4VDYf+6WHMAvxtiuMwx3w at public.gmane.org>
  wrote:

 > > From: Chuck Smith on Wednesday, December 17, 2003 6:20 PM
 > >
 > > > Wikipedia is in the process of becoming a household
 > > > name.
 > > > I am confident that in a year's time it will be a
 > > > name that is as well
 > > > known as or better than Britannica and Encarta.
 > >
 > > I just want to say that I agree completely.  We're in
 > > the process of branding a name here.  "Wikipedia 1.0"
 > > seems perfect to me.  It shows that it's stable and
 > > includes the same name.  "Wikipedia 2004" could also
 > > be used if we want to publish a new stable version
 > > every year like traditional encyclopedias.
 >
 > There's a number of naming issues here; the name for the frozen
version,
 > and the name for the project of creating that version.
 >
 > In terms of naming the frozen version, I prefer Wikipedia 2004 to
 > Wikipedia 1.0.

I agree.  Wikipedia 1.0 implies that there will be a Wikipedia 1.1,
which I would interpret as professing to be what Wikipedia itself is,
the in-between revisions (yes, it's more than that, but I'm speaking
purely in terms of published versions).  Wikipedia 2004 implies that it
is the 2004 *edition* (rather that release) of the Static Wikipedia
(one hell of an oxymoron, mind you).  The reference is to an edition of
an electronic reference material, rather than to a release of a piece
of software, the development process of which is, I think, not
applicable to this project.  I'm having a bad night for clarity.

Peter


subject: [Wikipedia-l] A quick thought about 1.0

body:
Sorry if this is a doublepost...

In article
<87hdzz47r1.fsf at unicorn.bad-people-of-the-future.san-francisco.ca.us>,
  Evan Prodromou <evan-+DxIcwYt55H9qxiX1TGQuw at public.gmane.org> wrote:

 > >>>>> "JW" == Jimmy Wales
<jwales-KK9S75Hv+MAAvxtiuMwx3w at public.gmane.org>
 > >>>>> writes:
 >
 >     JW> But I have this counter-thought -- while I do agree that the
 >     JW> idea of 1.0 has been causing people to do some things that I
 >     JW> don't really think are best, I think the solution to this is
 >     JW> to hurry up and actually implement a plan/software/whatever to
 >     JW> permit those who have deletionist tendencies (no insult meant
 >     JW> by the term!) to work on that.
 >
 > I wonder if there's a way to use fields metadata:
 >
 >   http://meta.wikipedia.org/wiki/Field-value_pairs
 >
 > ...to start tagging articles for 1.0. Say, "[[release=1.0]]" or
 > something.
 >
 > ~ESP

Cosider this my voice of support.  Or this:

http://meta.wikipedia.org/wiki/Talk:Field-value_pairs

Peter

(P.S. Please consider this a shameless plug for a conversation and not
an even more shameless 'me too' post.)


body:
Sorry if this is a doublepost...

In article <3FE0DA77.1020100 at livejournal.com>,
  Ralesk Ne'vennoyx <ralesk-PI1xv8u4z2E71oyAeX+DCg at public.gmane.org>
  wrote:

 > Walter Vermeir wrote:
 > > I like very much the name "Encyclopedia Galactica".
 > >
 > > It is like the objectieve of Wikipedia "a collaborative project to
 > > produce a free and complete encyclopedia in every language" , a very
 > > bold name.
 > >
 >     Encyclop?dia Galactica would clash with Isaac Asimov's EG ;)  And
 > it's perhaps a bit too bold.  How about something less big, like the
 > Earth instead of the Galaxy...  Encyclop?dia Terra or something like
 > that, I don't speak Latin...  Then again, neither really looks
wiki-ish.

Isn't the Encyclop?dia Galactica Douglas Adams?  Hmm..it is, but it's
also Asimov.  Is that a reference I never got, or a coincidence?

Anyways...

What about Encyclop?dia Nova?  It's got a nice sound (stiff and solid,
like a 'real' encyclopedia :)), it doesn't claim wiki-ness (wikosity?),
it doesn't attempt to revive or redefine Nupedia, and it makes
reference to Nupedia (whether 'new' was actually an inteded meaning of
not).  And Google seems to think the name's free.

Peter


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Re: WikiTeX

body:
On Wed, Dec 17, 2003 at 04:01:04PM -0800, Toby Bartels wrote:
> Besides checking with PlanetMath.org and arXiv.org
> to catch anything that we didn't happen to think of,
> somebody really should go through the proposed (La)TeX packages
> with a fine-toothed comb to ensure that nothing has been missed.

So after all, you do agree that a whitelist is the right solution ?

And if you make such a whitelist for math, I can just add it to texvc.


subject: [Wikipedia-l] Shirt / Wikipedia-Logo

body:
On Wed, 2003-12-17 at 23:14, Brion Vibber wrote:

> Wikipedia logo without text, and some of the edges are a little sharp:
> http://meta.wikipedia.org/upload/d/d2/Nohat-logo-XI-big.png

Where is are rules on fair use of this lovely logo found.

eg: I would like to attract interest from a website elsewhere.
Could I make a button out of this Logo?
Or even use it as it is found in Wikipedia?

Alternatively the missing tile (the one directly above 'omega') if
available can be excellent way to render a character in a language that
is attracting more participants... ie, they click on the single tile and
come to see the globe being built.

Ramanan


from_name: Jay Bowks

body:
From: "Peter Jaros" <rjaros at shaysnet.com>
> What about Encyclop?dia Nova?  It's got a nice sound (stiff and solid,
> like a 'real' encyclopedia :)), it doesn't claim wiki-ness (wikosity?),
> it doesn't attempt to revive or redefine Nupedia, and it makes
> reference to Nupedia (whether 'new' was actually an inteded meaning of
> not).  And Google seems to think the name's free.

Unfortunately the name
sounds like "The Encyclopedia
Doesn't Go" in Spanish...
"La enciclopedia no va".
I remember reading an old
story (maybe a linguistic legend)
that says this is why the American
car named "Nova" didn't do well
in South American car sales
figures... Believe it or Not ;-)

w/ regards,
Jay B.


from_name: Ruimu

subject: [Wikipedia-l] Nupedia?

body:
----- Original Message -----
From: "The Cunctator" <cunctator at kband.com>
> I think this is absolutely right, and is probably why I subconsciously
> have been disliking the name "Wikipedia" for a hardcopy version.
>
> I personally think Nupedia is a good name for it, but if people can come
> up with a better idea, then that would be great too.

    Nupedia sound and look a little bit weird in French and maybe also in
German. I would personally prefer a longer impressive latin sounding name (a
little bit like "Encyclopaediae Universalis") to be on the jacket, and
Nupedia could be the nickmane used day-to-day. Something like "Open
Collaborative Hyperlinked Encyclopaedia" but, at best, N and U could be
acronyms. ("Networked Universal Encyclopaedia" ?) (My two centimes)

Post-Scriptum: In fact, I don't even know if the hardcopy version is to be
multi language. I apologise if my proposal is off the road.


subject: [Wikipedia-l] Re: Nupedia?

body:
Since Wiki is Hawaiian for "fast"...
here are some possible Hawaiian
terms...

Aka = shadow, reflection, etc.
hence: Akapedia

Haka = shelf
hence: Hakapedia (sounds like "Hack"!)

Pepa = paper
hence: Pepapedia

Helu = read
hence: Helupedia

Puke = book
hence: Pukepedia
         (Not very desirable!)

Kuiki (from Kapa kuiki) = quilt
hence: Kuikipedia, Kwikipedia

Well, maybe the Hawaiian connection
isn't such a good idea after all :-)

Since,
Jay B.


from_name: Evan Prodromou

body:
>>>>> "TC" == The Cunctator <cunctator at kband.com> writes:

    TC> Or "Crippled, Frozen Wikipedia Suitable for Dead-Tree
    TC> Distribution" if you want to be more honest about it....

I'd call Wikipedia "crippled" if it was only usable in a particular
medium (say, for example, wiki).

~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: Ray Saintonge

body:
Stan Shebs wrote:

> Chuck Smith wrote:
>
>>> Wikipedia is in the process of becoming a household
>>> name. I am confident that in a year's time it will be a
>>> name that is as well
>>> known as or better than Britannica and Encarta.
>>
>> I just want to say that I agree completely.  We're in
>> the process of branding a name here.  "Wikipedia 1.0"
>> seems perfect to me.  It shows that it's stable and
>> includes the same name.  "Wikipedia 2004" could also
>> be used if we want to publish a new stable version
>> every year like traditional encyclopedias.
>
> So, ideas:
>  "Wikipedia Pro 1.0"
>  "Wikipedia Stable 2004"
>  "Wikipedia Plus 1.0"
>  "Best of Wikipedia 1.0" (BOW, but suggests "bow wow")
>  "Wikipedia Select 2004"
>  "Wikipedia Snapshot" or "Wikipedia Snap"
>  "Bomis Wikipedia 1.0" :-)

I find myself coming around to the idea that "Wikipedia" needs to be
part of the name.  I agree that it would no longer be a wiki and just
having the year in the title itself gives the impression that it is a
snapshot.  Thus any additional words will be reduncancies of some sort.
 Short titles are more attractive to the public..

There's a risk in trying to put too much into the first edition.  I
support the idea of relatively short production runs that can be easily
sold out.  The first edition especially is bound to have a lot of bugs
and errors..  I even have doubts about whether a credible print copy can
be produced in 2004.  Once the first edition is ready, it should be easy
to produce CD versions quarterly.

> For specialized products, longer names are good too:
>  "Wikipedia Encyclopedia of Ships and the Sea"
>  "Wikipedia's Math-o-Rama"
>  "Wikipedia Games Compleat 2004"
>  "The Wikipedia Tree of Life: a comprehensive encyclopedia
>  of plants, animals, and protista"

How about Wikimedia's own stamp catalog, with a numbering system that
can compete with Scotts' overprotected proprietary one.
Ec


from_name: Chuck Smith

subject: [Wikipedia-l] Wikipedia 2004

body:
> In the Linux world, distributors have a brand name
> that they glue
> on in addition to a version number, so "Red Hat
> Linux 8.0" is the
> actual product you can get, and there's no "Linux
> 8.0" unless it's
> a far-future kernel. :-)

Yep, just remember that Wikipedia isn't necessarily a
Linux project.  I mean, the servers run on Linux, but
I'd imagine that most of us editors are on other
operating systems and some of us aren't all that
familiar with the open-source world.  After reading
the dialogue, I'm now in favor of the more
user-friendly title "Wikipedia 2004".

For the working version, why not Nudepedia? :-P or for
us Esperanto speakers: Nudpieda (barefoot).  haha

Chuck

=====
We are the Esperanto speakers who say "Ni!"
http://www.esperantomobilo.org/

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


from_name: Peter Danenberg

subject: [Wikitech-l] Re: WikiTeX

body:
> I hope that you don't regard this list as complete,
> even for the current <rend> classes.

The list is preliminary, and should form the greater part of our
collaboration pre-integration.

> Besides checking with PlanetMath.org and arXiv.org
> to catch anything that we didn't happen to think of,
> somebody really should go through the proposed (La)TeX packages
> with a fine-toothed comb to ensure that nothing has been missed.

I've made both the source for our packages as well as the class
templates available at http://69.44.153.14/wikitex_doc.htm; and will
vigilantly update the lists according to our findings.

Lilypond's main concern was GUILE-access; PPCH-LaTeX continues to be an
unknown; Chess and AMS-LaTeX didn't discover anything upon first
perusal.

Work ahead.

Peter


subject: [Wikipedia-l] A quick thought about 1.0

body:
Cunc-
> All /I/ know is that I believe I have identified a trend of people
> editing entries with an eye towards the print version, leading to (imho)
> astoundingly long and digressive entries which try to fit all the
> possibly relevant information on one page

Now, now. These are completely different phenomena, and correlation, if it
exists, does not equal causation. What you describe is also not
"deletionism", as the only thing that is deleted, if anything, is
structure in the database. It is arguable whether page titles (not page
content) like "Response of the Catholic Church to allegations of child
sexual abuse" should really be kept. Normally they are simply redirected.

I oppose splitting articles up into tiny chunks for a number of reasons
which I have already given to you. Quoting myself:

        -       -       -

     I feel that it is extremely tedious to have to click around many
times and load many pages to get a complete picture of an issue, a person
etc. This is even more applicable for printing, of course, but also a
general problem. I think an article should have as much information
related to its title as possible for that reason, and things should only
be split off if a certain maximum size is reached (I tend towards 30-40K),
or if they are not really related.

    [...]

    I implemented section editing to make it easier to handle long
articles. We will also address the edit conflict issue soon. In terms of
linking, would you be happier with long articles if redirects could point
to anchors? Then History of sports could redirect to Sports#History. I
fail to see which other advantages might be gained from having many small
articles on a subject instead of one reasonably large one.

        -       -       -

Yes, it has something to do with printing also, but not the 1.0 print
edition, but printing articles from Wikipedia, whether they are part of
1.0 or not. This is an important application for any article, and
splitting things up makes it more difficult.

Regards,

Erik


from_name: Jimmy Wales

body:
The Cunctator wrote:
> In terms of naming the frozen version, I prefer Wikipedia 2004 to
> Wikipedia 1.0.

Then I propose that we call it Wikipedia 2005, because I don't know if
it'll be ready in 2004.  :-)

Actually, I'm just joking, but my point is just that calling it by a
year more or less commits us to a schedule, whereas if it takes 4
years to come up with 1.0, that'd be fine.

There are pro's and con's, obviously.

--Jimbo


body:
I have no opinion beyond the very abstract "We should do the
traditional thing, we should do the right thing."

Evan Prodromou wrote:

> Do we need to add the traditional GPL notification at the beginning of
> source files?
>
> ~ESP
>
> --
> Evan Prodromou <evan at wikitravel.org>
> Wikitravel - http://www.wikitravel.org/
> The free, complete, up-to-date and reliable world-wide travel guide
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikipedia-l] A quick thought about 1.0

body:
I agree with this.  It'd take a pretty major revolution for me to get
too excited about any other name.

Erik Zachte wrote:

> Wikipedia is in the process of becoming a household name.
> I am confident that in a year's time it will be a name that is as well
> known as or better than Britannica and Encarta.
>
> I think it would be too bad if we cause confusion by introducing a new
> name for a printed edition.
> Image Britannica had called their online version "Amerannica", what a
> waste PR wise.
>
> In my view people will be less confused when online and printed
> Wikipedia differ in content under the same name.
> Online Brittanica is also different from printed edition, because of
> regular updates of the online version.
>
> Erik Zachte
>
>
>
>
> .

> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


body:
Jimmy Wales wrote:

>The Cunctator wrote:
>
>>In terms of naming the frozen version, I prefer Wikipedia 2004 to
>>Wikipedia 1.0.
>>
>
>Then I propose that we call it Wikipedia 2005, because I don't know if
>it'll be ready in 2004.  :-)
>
If it's ready early there's a precedent with the auto manufacturers who
trot out next year's models in August. :-)

Ec


from_name: magnus,manske

body:
Stan Shebs wrote:

>
> For specialized products, longer names are good too:
>  "Wikipedia Encyclopedia of Ships and the Sea"
>  "Wikipedia's Math-o-Rama"
>  "Wikipedia Games Compleat 2004"
>  "The Wikipedia Tree of Life: a comprehensive encyclopedia
>  of plants, animals, and protista"

"The Wikipedia list of bot-generated U.S. towns" :-)


subject: [Wikipedia-l] A quick thought about 1.0

body:
Jimmy Wales wrote:

>Cunc has argued, correctly I think, that the idea of 1.0 may be
>causing people to delete things that really need not be deleted.  For
>this reason, he thinks it best to pursue 1.0 under a non-Wikipedia
>brand name, possibly Nupedia.
>
>
I'd like to see that ol' name alive and breathing again :-)
My second choice would be "Wikipedia 2004".

>But I have this counter-thought -- while I do agree that the idea of
>1.0 has been causing people to do some things that I don't really
>think are best, I think the solution to this is to hurry up and
>actually implement a plan/software/whatever to permit those who have
>deletionist tendencies (no insult meant by the term!) to work on that.
>
>
OK, let's make this quick:
What we need is a non-editable subset of wikipedia, correct? So, in
order to get articles from wikipedia in there, there are these options:
1. Import (meaning, on the 1.0 project, you browse and hit "import")
2. Export (meaning, on wikipedia, you hit "export")
3. Both
 From a technical POV (!), I'd prefer #1. No need to mess with the
wikipedia "management" and interface itself, just a special mode nedds
to be added. I did that already, but I don't remember where I put it :-(

Magnus


from_name: Daniel Mayer

subject: [Wikipedia-l] A quick thought about 1.0

body:
Erik wrote:
>I feel that it is extremely tedious to have to click around
>many times and load many pages to get a complete
>picture of an issue, a person etc.

There is little difference between clicking on a TOC link in a huge article
than clicking on a link to another article.

>I think an article should have as much information
>related to its title as possible for that reason, and
>things should only be split off if a certain maximum
>size is reached (I tend towards 30-40K), or if they
>are not really related.

I really hate duplication of effort; If article A refers to event B and
article C also refers to event B, it is MUCH better to simply have an article
about B and short summaries in articles A and C. 30-40 KB is unreadably long
for all but the most important topics (such as a major world conflict where
simply providing short summaries of the major points would yield an article
of that length). A max of 15-25 KB minus markup is more readable for most
topics.

It is much better to chop things up into digestible bits. Then summaries of
the spun-off bits should be left with links to full articles on those topics.
That way the reader has a choice to read the summary or to skip right to the
detail.

/That/ is far more useful for the reader and also minimizes duplication of
effort by contributors. I also don't see a problem with this in a print
version since on-topic summaries would always be left in parent articles
(detail would be in daughters).

-- Daniel Mayer (aka mav)


body:
----- Original Message -----
From: "Walter Vermeir" <walter at wikipedia.be>
>
> I like very much the name "Encyclopedia Galactica".
>
> It is like the objectieve of Wikipedia "a collaborative project to
> produce a free and complete encyclopedia in every language" , a very
> bold name.

Yeah, and being bold is exactly what people told me when I came in wp.

"Nupedia" feels a little bit like a name for English-speaking geeks and I
wish the project could gather more and more wikipedians from any other
horizons, not only computer adicted geeks like me, that why  I would prefer
an elegant self explaining name (or subtitle). Wikipedia 0.1 is going
outside in the world for the first time and should not forget its dinner
jacket!


from_name: The Cunctator

body:
> From: Jimmy Wales on Thursday, December 18, 2003 9:18 AM
>
> The Cunctator wrote:
> > In terms of naming the frozen version, I prefer Wikipedia 2004 to
> > Wikipedia 1.0.
>
> Then I propose that we call it Wikipedia 2005, because I don't know if
> it'll be ready in 2004.  :-)
>
> Actually, I'm just joking, but my point is just that calling it by a
> year more or less commits us to a schedule, whereas if it takes 4
> years to come up with 1.0, that'd be fine.
>
> There are pros and cons, obviously.
>
For me there's a basic philosophical issue; version 1.0's represent a
"finished product", completion.

Calling something "Wikipedia 1.0" is, in my mind, an oxymoron.

I don't want to promote the idea of a "complete and finished" version of
Wikipedia--Wikipedia needs to be understood as an ongoing process.

"Wikipedia 0.1" doesn't have those philosophical problems.

The *reality* of the situation is that when all is said and done the
title of the print version is likely to be "Wikipedia: The Free
Encyclopedia".

We can choose whatever name we want for the project to make it. I think
Nupedia, with its history of using a certification process to develop
articles, is an appropriate name for the project. But so would "the
Wikipedia Snapshot Project" or "Skippy".


subject: [Wikipedia-l] Categorization requirements

body:
So, I've started a list of requirements for categorization
implementations, to make sure that whatever we decide to do will
actually do what we need.

         http://meta.wikipedia.org/wiki/Categorization_requirements

People interested in categorization should probably take a peek.

~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: [Wikipedia-l] A quick thought about 1.0

body:
> From: Daniel Mayer on Thursday, December 18, 2003 12:58 PM

> It is much better to chop things up into digestible bits. Then
summaries
> of the spun-off bits should be left with links to full articles on
those
> topics. That way the reader has a choice to read the summary or to
skip
> right to the detail.
>
> /That/ is far more useful for the reader and also minimizes
duplication of
> effort by contributors. I also don't see a problem with this in a
print
> version since on-topic summaries would always be left in parent
articles
> (detail would be in daughters).

Moreover, keeping entries focused on distinctly individual topics makes
successful collaborative editing possible. If it's not clear what the
topic of the entry is (what the standards for inclusion are) then
attempts to collaboratively edit the entry fall down.


from_name: Toby Bartels

subject: [Wikitech-l] Re: WikiTeX

body:
Taw (Tomasz Wegrzanowski) wrote:

>Toby Bartels wrote:

>>Besides checking with PlanetMath.org and arXiv.org
>>to catch anything that we didn't happen to think of,
>>somebody really should go through the proposed (La)TeX packages
>>with a fine-toothed comb to ensure that nothing has been missed.

>So after all, you do agree that a whitelist is the right solution ?

In combing through the packages, it should be possible to create
both a blacklist ''and'' a whitelist, to satisfy both philosophies.
But there are some LaTeX commands that define new commands,
such as \DeclareMathSymbol , that should be safe to allow.
Then a blacklist approach will be more flexible (but not more powerful)
than a whitelist approach, since it allows one define abbreviations.

>And if you make such a whitelist for math, I can just add it to texvc.

Since Peter has posted the templates, I will start on this when I can,
and post the results here, so you and he can both use them as you like.
(But I probably will not be able to do this until the holidays are over!)

-- Toby


subject: [Wikitech-l] WikiTeX

body:
Peter Danenberg wrote:

>Toby Bartels wrote:

>>I hope that you don't regard this list as complete,
>>even for the current <rend> classes.

>The list is preliminary, and should form the greater part of our
>collaboration pre-integration.

Good!

>I've made both the source for our packages as well as the class
>templates available at http://69.44.153.14/wikitex_doc.htm; and will
>vigilantly update the lists according to our findings.

That's just what I need to do my own going through with a fine-toothed comb.
I'll post my findings here when I finish them, but I probably won't be able
to start until 2004 -- and definitely won't be able to start for a week.
So that shouldn't stop somebody else from getting to it faster! ^_^

>Lilypond's main concern was GUILE-access; PPCH-LaTeX continues to be an
>unknown; Chess and AMS-LaTeX didn't discover anything upon first
>perusal.

I'm only familiar with the math packages; but if the others are organised
along similar lines (as seems likely), then I will look at them as well.

-- Toby


from_name: Ramanan Selvaratnam

subject: [Wikipedia-l] Wikipedia 2004

body:
Aw, c'mon.

Although I deleted the threads that started this off and some one seems
to have changed the subject, without reading any more I want to put an
end to the direction taken by the the segment replied to below! :)

Linux is the kernel that is making headwaves everywhere.
They have a naming scheme which is deep but not the best IMO.
See [kernel.org]

What I see being refered to listakenlt below is the system which is
GNU/Linux. Why GNU? please read up
http://www.gnu.org/gnu/linux-and-gnu.html
More on GNU at the end.

Redhat is a distribution of GNU/Linux as much as SuSE or Mandrake is.
They have version numbers too but as they have physical offices and
staff we cannto compare with them.
What is  worth looking at is the totally virtually developed GNU/Linux
system, Debian. Well Debian is more than GNU/Linux distro so please look
it up at [www.debian.org]... there versioning system is time tested,
peer reviewed (heavily) and more...
Wikipedia is not the sameas Debian but there might be something there
for anyone intersted.

Back to GNU. GNU is the currently most active proponent of the concepts
of libratoty thinking in software and their applications ie, free as in
freedom software.
Free as in free information/encyclopedia has everything to do with GNU.

Yes I agree on not caring whether wikipedia runs on GNU/Linux or or some
other less stable system.

All the best,

Ramanan

On Thu, 2003-12-18 at 09:06, Chuck Smith wrote:
> > In the Linux world, distributors have a brand name
> > that they glue
> > on in addition to a version number, so "Red Hat
> > Linux 8.0" is the
> > actual product you can get, and there's no "Linux
> > 8.0" unless it's
> > a far-future kernel. :-)
>
> Yep, just remember that Wikipedia isn't necessarily a
> Linux project.  I mean, the servers run on Linux, but
> I'd imagine that most of us editors are on other
> operating systems and some of us aren't all that
> familiar with the open-source world.  After reading
> the dialogue, I'm now in favor of the more
> user-friendly title "Wikipedia 2004".
>
> For the working version, why not Nudepedia? :-P or for
> us Esperanto speakers: Nudpieda (barefoot).  haha
>
> Chuck
>
> =====
> We are the Esperanto speakers who say "Ni!"
> http://www.esperantomobilo.org/
>
> _________________________________________________________
> Do You Yahoo!?
> Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
> Vis?tanos en http://noticias.espanol.yahoo.com
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] A quick thought about 1.0

body:
On Thursday, December 18, 2003, at 03:51  AM, magnus,manske wrote:

> OK, let's make this quick:
> What we need is a non-editable subset of wikipedia, correct?

Hold up.  Do we?  Is this to be a paper or electronic encyclopedia?  Or
both?  Or am I talking about two different proposals?  It seems a shame
to me to freeze and de-wikify entries if not for the sole purpose of
inscribing it on a medium that can't be edited (ie., paper).  I would
much prefer a tagging system which allows us to mark entries as
complete.  Note that 'complete' is not the same as 'finished'.  No
entry should ever be finished.  But some entries have achieved
completion, where the need only adjustment; think opposite of stub.
Furthermore, these entries rarely devolve from their complete status,
though if they did for some reason the tag could be quickly removed
(or, preferably, the entry re-completed :) ).

Let me back up my opinion with personal experience: I'm a dormant h2g2
Researcher (old Researchers never die, they just let their forum
backlog pile up...).  On h2g2, only one researcher has write-access to
an article in the Unedited Guide (the collection of articles which have
not gone thought the editing process).  Once an article is edited, no
one (except the Italics, the staff editors) has write-access.  Each
entry has a forum where corrections and updates may be posted, but the
entry itself is *never* updated.  Not so much by policy, but out of
inconvenience.

I realize that entries in an electronic frozen Wikipedia would probably
be updated periodically from the wiki counterpart, avoiding this folly,
but why bother?  Why would we edit a complete (as defined above) entry
so as to make it no longer qualify for the frozen counterpart?  It
seems silly to bother with the frozen version at all.  Once an entry is
complete, it ought to remain so, even as a wiki entry.  Or have we lost
faith in the wiki?  And if so, why?

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show


subject: [Wikipedia-l] A quick thought about 1.0

body:
> From: Peter Jaros on Thursday, December 18, 2003 5:17 PM
> On Thursday, December 18, 2003, at 03:51  AM, magnus,manske wrote:
>
> > OK, let's make this quick:
> > What we need is a non-editable subset of wikipedia, correct?
>
> Hold up.  Do we?  Is this to be a paper or electronic encyclopedia?
Or
> both?  Or am I talking about two different proposals?  It seems a
shame
> to me to freeze and de-wikify entries if not for the sole purpose of
> inscribing it on a medium that can't be edited (ie., paper).  I would
> much prefer a tagging system which allows us to mark entries as
> complete.  Note that 'complete' is not the same as 'finished'.  No
> entry should ever be finished.  But some entries have achieved
> completion, where the need only adjustment; think opposite of stub.
> Furthermore, these entries rarely devolve from their complete status,
> though if they did for some reason the tag could be quickly removed
> (or, preferably, the entry re-completed :) ).

What is your definition of "completion" that you can assert that some
entries have achieved it?

Completion is a final state (thus "achieved"); any changes to something
which is complete ("having all necessary or normal parts; absolute,
total") will make it worse.

I think perhaps the word you're looking for is "sufficient".


subject: [Wikipedia-l] A quick thought about 1.0

body:
> From: Erik Moeller on Thursday, December 18, 2003 4:57 PM
> Daniel-
> >> I feel that it is extremely tedious to have to click around
> >> many times and load many pages to get a complete
> >> picture of an issue, a person etc.
>
> > There is little difference between clicking on a TOC link in a huge
> article
> > than clicking on a link to another article.
>
> When I read an article about a well defined subject, and I want to get
all
> the information about it, I don't click around at all. I just read the
> article from top to bottom. I might skip a certain section, but I
don't
> need to click anywhere. And when I do use the TOC, it is substantially
> faster in terms of latency than browsing of separate articles. Not
only do
> I not need to wait for the page to load, I can also easily get context
--
> information about where I am within the structure of a topic -- simply
by
> scrolling, rather than using back->click->back->click..

Well, that's nice, but it's not fair or appropriate for you to assume
that what you like should be mandated for all. Assuming that all readers
would be happiest if they had the version you like the best--when there
is evidence to the contrary--is not appropriate.

I, for one, when I read a sentence like

The [[asthetic appeal of sport]] is what sports art, including sport in
film, attempts to capture.

..will follow the link if I don't feel as if I understand what the
"asthetic appeal of sport" is; but if I feel that I do understand it, I
am glad that the author didn't force me to waste time skimming through
information I didn't need.

> If I have an article like [[sports]], after Cunctator split it up into
> lots of tiny fragments, this possibility is no longer there. To some
> extent I agree with the split ups, but I find it questionable whether
> [[professional sports]], [[aesthetic appeal of sport]], [[nationalism
and
> sport]], [[female sport]] etc. should really be separate entries. Even
> worse is that the article has a long list of "See also"s -- these are
one
> of the worst ways to structure information.

Erm--I didn't break out [[female sport]]. Don't bame me for that one.

I *drastically shortened* the list of "See also"s. Again, don't blame me
for that one.

The one complaint that is reasonable and honest is that my
summarizations of the subtopics in [[sport]] were too drastic.

But if we take the case of [[professional sports]], the [[sport]]
article discusses how professional sports rises from sport's appeal as
passive entertainment, how professional sports have given rise to
several related industries, and how professional sports comes into
conflict with the concept of amateur sportsmanship.

And that is, in my opinion, a reasonable summary of the most important
issues relevant to our basic understanding of sport that can be gleaned
from professional sports.

I don't know if all my edits were exactly right, but the entry needed
some drastic editing. By separating out some of the more digressive
sections it's much more clear what information is needed and what is
not.

> In my experience, separating articles so much also leads to
> inconsistencies in style and neglect of articles about fringe
subjects.
> For example, I predict that the newly created [[regulation of sport]]
will
> be neglected, while I believe it would not have been if it had been
kept
> as a section within the article. The reason is simply reduced
exposure.

Who knows? The longer the entry, the more difficult it becomes to
properly edit its subsections--or to entirely reorganize it if
necessary.

> > 30-40 KB is
> > unreadably long for all but the most important topics
> > ... A max of 15-25 KB minus markup is more
> > readable for most topics.
>
> Well, these are mere statements of opinion. And of course the amount
of
> information that people can stomach in one sitting varies greatly. I
do
> notice, however, that these are not so far apart. If you take my
minimum
> and your maximum and take the average, you arrive at 27.5K, which
seems
> reasonable to me. The sports article is currently a mere 5K, which is
IMHO
> a clear sign that it is far too fragmented. It also has no real
summaries
> of the sub-articles it links to. Overall it gives a very
unprofessional
> impression to me.

The version beforehand felt very unprofessional to me. I expect that it
will achieve a happy medium at some point.

But I get the feeling that what feels "professional" to you is "what
would look best on paper".

> I would also probably be very pissed if Cunc had done this, without
prior
> discussion as in this case, to one of "my" articles. One key reason is
> that the history gets completely lost in the process. Sure, you can
still
> fish it out, but people will assume that Cunc wrote the individual
pieces.
> I have invested many days of research in some articles I worked on,
and
> getting fair credit in the page history is very little to ask for in
> return. Having a carefully planned out article structure messed up in
this
> way would also make me quite angry. Be bold, but also be respectful
toward
> other people's work.

I'm sorry, but I don't think that it's appropriate to take editing
changes like this personally. It's counterproductive to collaboration
and egocentric. Taking edits for structure personally doesn't help
anyone.

It's a lot better for everyone to get your high from the act of selfless
contribution or the knowledge that you've insinuated your knowledge and
perspective invisibly into the stream.

Once you contribute to Wikipedia, it's *not your work* any more. The
original contribution is, but that's it. *You are explicitly agreeing to
a merciless editing process*.

It's reasonable and right to say "I think your changes have hurt the
coverage of this issue in these ways". It's unreasonable to say "I'm
angry because you changed my entries, whether or not it's for the
better."

If you're so worried about credit, then write code to allow people to
rename sections to new pages so that the version history is remembered.

> > /That/ is far more useful for the reader ..
>
> I'm glad that you are so confident that you are correct. For me the
issue
> is still quite foggy. While I agree with you that summaries of
subsections
> are useful, I feel they should not be created needlessly. That is, if
> we're below a certain size -- maybe the 27.5K from above -- we don't
need
> to split the article up unless there is a clear logical separation.
For
> example, in the [[Mother Teresa]] article we split away everything
that is
> about the [[Missionaries of Charity]] (Teresa's order), which is fine
with
> me because there's a clear distinction here. But stuff like "History
of
> .." should really only be split off if we're approaching the size
limit,
> in my opinion. Otherwise the disadvantages of splitting appear to
outweigh
> the advantages.

Again, your idea of a reasonable size for an entry differs from mine,
and from other people.

I think "History of X" entries are very different from "X" entries. The
entry "X" should tell the person what X is--not what it was.

--tc


subject: [Wikipedia-l] A quick thought about 1.0

body:
By the way, I apologize in advance if my tone in the last was too
argumentative. I disagree with Erik, but I know his goals are to make
Wikipedia as good as possible.


from_name: tarquin

subject: [Wikipedia-l] Nupedia?

body:
Daniel Mayer wrote:

>But I really don't think 'wiki' should be in the title of any Wikimedia
>content that is published in non-editable form (that would include any static
>website it is hosted on and any hardcopy such as books or a '1.0' version of
>Wikipedia).
>
>If you can't edit it, it ain't wiki!
>
>
Agreed.
It's less snappy that "nupedia" but I'd suggest something like "The Open
Content Encyclopedia" or "The Wikimedia Foundation Encyclopedia".
It's fine to use the Wikimedia name even if it's non-editable, since
it's made by the foundation. That neatly soves the problem of name
dilution too.


from_name: Erik Moeller

subject: [Wikipedia-l] A quick thought about 1.0

body:
Daniel-
>> I feel that it is extremely tedious to have to click around
>> many times and load many pages to get a complete
>> picture of an issue, a person etc.

> There is little difference between clicking on a TOC link in a huge article
> than clicking on a link to another article.

When I read an article about a well defined subject, and I want to get all
the information about it, I don't click around at all. I just read the
article from top to bottom. I might skip a certain section, but I don't
need to click anywhere. And when I do use the TOC, it is substantially
faster in terms of latency than browsing of separate articles. Not only do
I not need to wait for the page to load, I can also easily get context --
information about where I am within the structure of a topic -- simply by
scrolling, rather than using back->click->back->click..

If I have an article like [[sports]], after Cunctator split it up into
lots of tiny fragments, this possibility is no longer there. To some
extent I agree with the split ups, but I find it questionable whether
[[professional sports]], [[aesthetic appeal of sport]], [[nationalism and
sport]], [[female sport]] etc. should really be separate entries. Even
worse is that the article has a long list of "See also"s -- these are one
of the worst ways to structure information.

In my experience, separating articles so much also leads to
inconsistencies in style and neglect of articles about fringe subjects.
For example, I predict that the newly created [[regulation of sport]] will
be neglected, while I believe it would not have been if it had been kept
as a section within the article. The reason is simply reduced exposure.

> I really hate duplication of effort; If article A refers to event B and
> article C also refers to event B, it is MUCH better to simply have an
> article about B and short summaries in articles A and C.

I don't accept this as a general rule. It depends on the importance of the
reference within each article. If the reference in article C is minor, it
may well be completely acceptable to link to a larger article where event
B is discussed. But there are of course many cases where for reasons of
redundancy reduction this principle applies.

> 30-40 KB is
> unreadably long for all but the most important topics
> ... A max of 15-25 KB minus markup is more
> readable for most topics.

Well, these are mere statements of opinion. And of course the amount of
information that people can stomach in one sitting varies greatly. I do
notice, however, that these are not so far apart. If you take my minimum
and your maximum and take the average, you arrive at 27.5K, which seems
reasonable to me. The sports article is currently a mere 5K, which is IMHO
a clear sign that it is far too fragmented. It also has no real summaries
of the sub-articles it links to. Overall it gives a very unprofessional
impression to me.

I would also probably be very pissed if Cunc had done this, without prior
discussion as in this case, to one of "my" articles. One key reason is
that the history gets completely lost in the process. Sure, you can still
fish it out, but people will assume that Cunc wrote the individual pieces.
I have invested many days of research in some articles I worked on, and
getting fair credit in the page history is very little to ask for in
return. Having a carefully planned out article structure messed up in this
way would also make me quite angry. Be bold, but also be respectful toward
other people's work.

> /That/ is far more useful for the reader ..

I'm glad that you are so confident that you are correct. For me the issue
is still quite foggy. While I agree with you that summaries of subsections
are useful, I feel they should not be created needlessly. That is, if
we're below a certain size -- maybe the 27.5K from above -- we don't need
to split the article up unless there is a clear logical separation. For
example, in the [[Mother Teresa]] article we split away everything that is
about the [[Missionaries of Charity]] (Teresa's order), which is fine with
me because there's a clear distinction here. But stuff like "History of
.." should really only be split off if we're approaching the size limit,
in my opinion. Otherwise the disadvantages of splitting appear to outweigh
the advantages.

Regards,

Erik


subject: [Wikipedia-l] A quick thought about 1.0

body:
On Thursday, December 18, 2003, at 07:14  PM, The Cunctator wrote:

>> From: Peter Jaros on Thursday, December 18, 2003 5:17 PM
>> On Thursday, December 18, 2003, at 03:51  AM, magnus,manske wrote:
>>
>> I would
>> much prefer a tagging system which allows us to mark entries as
>> complete.  Note that 'complete' is not the same as 'finished'.  No
>> entry should ever be finished.  But some entries have achieved
>> completion, where the need only adjustment; think opposite of stub.
>> Furthermore, these entries rarely devolve from their complete status,
>> though if they did for some reason the tag could be quickly removed
>> (or, preferably, the entry re-completed :) ).
>
> What is your definition of "completion" that you can assert that some
> entries have achieved it?
>
> Completion is a final state (thus "achieved"); any changes to something
> which is complete ("having all necessary or normal parts; absolute,
> total") will make it worse.
>
> I think perhaps the word you're looking for is "sufficient".

Yes.  It is.  Thank you. :)

Actually, I think I considered the word 'sufficient' and didn't like
the negative connotation.  But it you ignore that, 'sufficient' is,
well, sufficient.

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show


from_name: Brion Vibber

subject: [Wikitech-l] en/en2 quick fixes

body:
I've altered the rewrite rules for the en/en2 split so that user agents
that don't identify themselves as some variant of "Mozilla" are kept
solely on en.wikipedia.org.

The vast majority of web browsers identify as "Mozilla/XX (something)
blah blah" for historical compatibility reasons. The vast majority of
web search engine indexing spiders, on the other hand, do not. This
should help clean up search indexes so a search limited to
'en.wikipedia.org' can turn up all articles, and internal linking will
be properly taken into account.

This will push a little extra load onto larousse, but not I think too
much.

Just a note: on an overall basis, the traffic for the English wikipedia
is about the same as all the others combined. If we could get the
processor upgrade for larousse actually in place, well that would be
great. Since that doesn't seem to be forthcoming, alternatively, we
could move some of the languages to larousse and put English on pliny
only.

This should help balance things a little more cleanly without yet the
need for IP virtualization. But, that'll require updating DNS for
wikipedia.org, which I don't have access to. Any thoughts on this plan
before we go trying to organize it?

-- 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/20031218/05ce4bdb/attachment.pgp>


from_name: Bjorn Lindqvist

subject: [Wikipedia-l] Re: Wikipedia-l Digest, Vol 5, Issue 39

body:
Erik Moeller wrote:

>      I feel that it is extremely tedious to have to click around many
> times and load many pages to get a complete picture of an issue, a person
> etc. This is even more applicable for printing, of course, but also a
> general problem. I think an article should have as much information
> related to its title as possible for that reason, and things should only
> be split off if a certain maximum size is reached (I tend towards 30-40K),
> or if they are not really related.
>     [...]
>
>     I implemented section editing to make it easier to handle long
> articles. We will also address the edit conflict issue soon. In terms of
> linking, would you be happier with long articles if redirects could point
> to anchors? Then History of sports could redirect to Sports#History. I
> fail to see which other advantages might be gained from having many small
> articles on a subject instead of one reasonably large one.

This is a huge drawback and a very strong reason for creating
concentrated articles. For example, if I, with your system, is editing
an article about say Internet Security and wants to make a reference
to ARP Spoofing I wouldn't be able to do that. Since I don't think it
would be necessary to describe exactly how the hack is done in the
article, I would want to link to another article. But which one? Would
it be: [[ARP Spoofing]], [[Address Resolution Protocol]] or [[The TCP/IP
Protocl Suite]] (likely a gigantic article)? What would the readers of
my article think would be best?

Anchors would partially solve that issue. But you would still have the
problem that the paragraph's in [[The TCP/IP Protocol Suite]] probably
would discuss ARP Spoofing in a whole different context than the one
my readers just left. It would be much better to have it in a separate
article which would make it context neutral. However, that easily
creates the "man page problem" - information written completely out of
context and therefore totally useless to the reader. The only easiy
solution to that problem is to repeat and make articles overlap. In
that way both views could be satisfied. And there's no shame in
redundancy.

Then there is the problems that many writers (like me) have with large
articles. The longer the article is, the harder it is to edit. For me
the time it takes to edit an article (that I wasn't the orignator of)
roughly doubles for each paragraph in the article. I'm not sure why,
but with longer articles you not only has to take into consideration
the actual text but also the authors flow of language, context, style
and so on. For example, check the article History of post-communist
Russia and the other articles 172 has written on Russian history. They
are great, well worth the read, well written and in general extremely
Brilliant Prose. But they aren't edited much. Every part of
Russia's/Soviet's 20th century history is surrounded by controversies
and political issues. Partisans from all over the world should
continually be involved in meaningless revert wars on those articles!
But they aren't. Why?

I draw the conclusion that others also feel that long articles are
hard to edit.


subject: [Wikitech-l] Linux security updates

body:
I topped off the rpm-based security updates on pliny and larousse, I
*think* I got the updates installed on geoffrin via yast2, and I gave
them more current kernels which shouldn't have the recently publicized
kernel vulnerability (the latest Red Hat-provided one for larousse, and
a compiled 2.4.23 for pliny; I assume the SuSE updates should also be
current).

They'll need to be rebooted for the kernel upgrades to take. L & P are
theoretically both set to boot to the new kernels on the next boot
only; so if they won't come up, a second reboot should bring back the
old kernel.

Since this involves conservatively some 30 minutes of downtime
(possibly rather more if there are problems) I'd rather not do it in
the middle of the day. Note also that geoffrin cannot be remotely
rebooted yet if it can't be logged into.

-- 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/20031219/c4542238/attachment.pgp>


from_name: Kurt Jansson

subject: [Wikipedia-l] Shirt / Wikipedia-Logo

body:
Jakob schrieb:

> Christmas is coming soon and a Wikipedia shirt would be a nice gift for a
> wikipedian. Any suggestions yet? The most important part is the logo *which I
> still have'nt found in a printable resolution*.

Erik opened an account at cafepress.com a while ago:
http://www.cafeshops.com/wikipedia

Maybe he can update it to the new logo without much work.

Would it be okay for the foundation to get some money through cafepress?
If the answer is yes this would also be true for the Amazon partnership
program, right?

Kurt


subject: [Wikipedia-l] A quick thought about 1.0

body:
Cunc-
> Well, that's nice, but it's not fair or appropriate for you to assume
> that what you like should be mandated for all.

That argument can be applied in both directions. So unless you come up
with a very good scheme thad does not substantially affect performance, is
easy to use and allows different "views" of an article, we'll have to go
with what the majority prefers (and make some concessions to the
minority). Given the experience of the recent poll on the Rick Santorum
article, I find it likely that your view is a minority position.

> I, for one, when I read a sentence like
> The [[asthetic appeal of sport]]

That should be "aestehtic", btw.

> But if we take the case of [[professional sports]], the [[sport]]
> article discusses how professional sports rises from sport's appeal as
> passive entertainment, how professional sports have given rise to
> several related industries, and how professional sports comes into
> conflict with the concept of amateur sportsmanship.

The level of detail of this "discussion" is as high as the level of detail
of the above paragraph. In other words, there is almost no information in
it that goes beyond what virtually everyone knows. That is the kind of
paragraph that makes articles look unprofessional unless you are fully
aware when reading it that there is much more detail available. Print it
and it looks really silly. "Participants are paid *by the audience* in
professional sports? Wow, I didn't know that! Wikipedia is so
informative!"

> Who knows? The longer the entry, the more difficult it becomes to
> properly edit its subsections--or to entirely reorganize it if
> necessary.

Um, reorganizing won't exactly become easier with 20 or so separate
articles where in many cases nobody will know where any specific piece of
information is.

> But I get the feeling that what feels "professional" to you is "what
> would look best on paper".

Not really, it's just that for me, the differences between what is good on
paper and what is good on a computer screen are not that big. There's a
certain hypertext myth that says that a "real" hypertext page needs to be
small and full of links to other hypertext pages. In terms of usability
studies, this has been found to be highly confusing and ineffective.
Having links is good, but they should lead to reasonably sized chunks of
information. The more fragmented an article is, the higher the likelihood
that people will be frustrated by lots of tiny stubs.

> I'm sorry, but I don't think that it's appropriate to take editing
> changes like this personally. It's counterproductive to collaboration
> and egocentric. Taking edits for structure personally doesn't help
> anyone.

It is not an irrational feeling. If you disagree with what someone has
done to your article, then your own investments of time and energy into it
are called into question, the other person in effect tries to *condition*
you to behave in a certain way. It is therefore really a minimum
requirement for collaboration to ask before making major changes, and to
try to achieve consenus.

You know very well that your changes to [[sports]] probably would not have
found consensus if you had announced them beforehand. And I believe that
is the reason you did not do so. Please try to follow the defined
Wikipedia decision making process. In case of minor changes, make them
immediately. In case of medium changes, make them and then comment (in the
edit summary or on the talk page). In case of major changes, announce them
first and wait for objections before making them. In case of objections,
seek consensus. In case of lack of consensus, you are free to start a
vote.

> It's a lot better for everyone to get your high from the act of selfless
> contribution or the knowledge that you've insinuated your knowledge and
> perspective invisibly into the stream. Once you contribute to Wikipedia,
> it's *not your work* any more. The original contribution is, but that's
> it. *You are explicitly agreeing to a merciless editing process*.

That is all well under the assumption that you agree with what the other
person has done. If you feel it makes the article worse, then this kind of
rhetoric falls apart.

> It's reasonable and right to say "I think your changes have hurt the
> coverage of this issue in these ways". It's unreasonable to say "I'm
> angry because you changed my entries, whether or not it's for the
> better."

Of course. I never said it would be reasonable to be angry about changes
that are for the better. It is questionable whether we agree when this is
the case, though.

> If you're so worried about credit, then write code to allow people to
> rename sections to new pages so that the version history is remembered.

That's not possible. You *can* split up the edit history (with *very* much
coding effort), but it will no longer make sense. Edit comments lose their
meaning, the linear structure of the history is broken up as edits which
were made to other sections between two edits of the same one are no
longer part of the new history, etc. Aside from that, cut&pasting is
typically not limited to clearly separable sections.

So losing proper credit is very much a given when cut&pasting out parts of
an article. This is probably also in material breach of the FDL. That's
one other major reason that it should not be done without consensus.

I feel that if you continue to split up articles in major ways without
announcing this on the talk page first and giving authors a chance to
react to your proposal, you are in serious violation of Wikiquette, and
possibly other policies.

Regards,

Erik


subject: [Wikipedia-l] A quick thought about 1.0

body:
On Fri, 2003-12-19 at 06:30, Arvind Narayanan wrote:
> On Thu, Dec 18, 2003 at 09:58:13AM -0800, Daniel Mayer wrote:
> > Erik wrote:
> > >I feel that it is extremely tedious to have to click around
> > >many times and load many pages to get a complete
> > >picture of an issue, a person etc.
> >
> > There is little difference between clicking on a TOC link in a huge article
> > than clicking on a link to another article.
> >
> For me there's a huge difference. My latency on wikipedia
> is usually between 5 and 10 seconds. OTOH I have high bandwidth.

This is an important point.
There are people  with 28kbps flaky bandwidth in the world. Lots of
them.

I of course have a whopping 2 mbps download speed line but that is due
to unfair global economics. Further my neighbours do not seem to need
wikipedia as much as the places where there are no internet even.

> So I would greatly prefer to download a huge article at once.
This helps to be saved on a floppy and be searched effectively (Ctrl+F
for most browsers)
Printing becomes more meaningful.

> > >I think an article should have as much information
> > >related to its title as possible for that reason, and
> > >things should only be split off if a certain maximum
> > >size is reached (I tend towards 30-40K), or if they
> > >are not really related.
again the search utility becomes helpful.
Anything very big will easily attract attention and then reorganisation
can be thought about.
I use tabbed browsing (a great recent  trick to keep the number of open
windows low) and find myself sometimes getting entangled in anything
upto 50 tabs on a decent night.

Monolithic pages should not become a bad thing. Clear strucutre and
named anchors can help monolithic pages be very useful.

To me 'standards' that seem to specify file size as a 'usability' issue
based on average screen size a misled corporate PR feature.

But eventually I must admit, technology that interchange the data
between monolithic and individual nodes an author wishes for will be a
useful thing.

Ramanan


subject: [Wikipedia-l] A quick thought about 1.0

body:
Erik-
> That should be "aestehtic", btw.

Ugh, "aesthetic" of course. There's got to be some natural law that when
pointing out spelling errors in other people's messages, you will
inevitably make at least one yourself.

Regards,

Erik


subject: [Wikipedia-l] A quick thought about 1.0

body:
> From: Erik Moeller on Friday, December 19, 2003 5:01 AM
> To: wikipedia-l at Wikimedia.org
> Subject: Re: [Wikipedia-l] A quick thought about 1.0
>
> Erik-
> > That should be "aestehtic", btw.
>
> Ugh, "aesthetic" of course. There's got to be some natural law that
when
> pointing out spelling errors in other people's messages, you will
> inevitably make at least one yourself.
>
It is a recognized phenomenon...not sure if it's been given a name.


subject: [Wikitech-l] en/en2 quick fixes

body:
Is there some way to balance the load without having the URLs explicitly
direct to en2.wikipedia.org?

It would be much better if all users were consistently directed to
"en.wikipedia.org" (even though I'll reiterate my basic opposition to
the redirect from www in the first place) instead of randomly between
"en.wikipedia.org" or "en2.wikipedia.org".


subject: [Wikipedia-l] Monolithic articles vs parents and daughters

body:
I just want to clarify my statement that it is best to divide topics into
digestible bits. I think this should only be considered for most articles
once they reach the 20 KB (minus markup) size and the resulting daughter
articles are not stubs. Although some articles demand a larger size just to
summarize all the main points and clearly link to daughters that have move
detail on each of those points.

An example article that I really like in this regard is [[Germany]]
(especially its history secton and the [[History of Germany]] daughter
article):
http://en2.wikipedia.org/wiki/Germany

There the parent article, [[Germany]], has several paragraphs giving a very
broad summary of German history. A prominent link is given to [[History of
Germany]]. The daughter article [[History of Germany]] summarizes each of the
major periods of German history. Each section has a prominent "Main article"
link to grandchildren articles about those specific periods of German
history. And of course any distinct subjects like people, places or things
have inline links to articles on those things.

This is the type of organization I like. However preemptively making stubs to
follow this structure is a really bad thing to do; let each article grow
until it starts to reach a size where readability and editability would be
improved by summarizing certain areas and moving the detail to daughter
articles.

I absolutely /hate/ it when people just cut an entire section out of an
article like ==History== and only leave a [[History of X]] link in that
section. In those cases, it is /far/ better to leave in the detailed history
even if it pushes the article's size way above 32 KB. A summary of the
history must accompany any "main article" link like that, IMO.

-- Daniel Mayer (aka mav)


from_name: Arvind Narayanan

subject: [Wikipedia-l] A quick thought about 1.0

body:
On Thu, Dec 18, 2003 at 09:58:13AM -0800, Daniel Mayer wrote:
> Erik wrote:
> >I feel that it is extremely tedious to have to click around
> >many times and load many pages to get a complete
> >picture of an issue, a person etc.
>
> There is little difference between clicking on a TOC link in a huge article
> than clicking on a link to another article.
>
For me there's a huge difference. My latency on wikipedia
is usually between 5 and 10 seconds. OTOH I have high bandwidth.
So I would greatly prefer to download a huge article at once.
> >I think an article should have as much information
> >related to its title as possible for that reason, and
> >things should only be split off if a certain maximum
> >size is reached (I tend towards 30-40K), or if they
> >are not really related.
>
> I really hate duplication of effort; If article A refers to event B and
Why is this duplication of effort? We can simply copy-paste from one
article to the other.
> article C also refers to event B, it is MUCH better to simply have an article
> about B and short summaries in articles A and C. 30-40 KB is unreadably long
> for all but the most important topics (such as a major world conflict where
> simply providing short summaries of the major points would yield an article
> of that length). A max of 15-25 KB minus markup is more readable for most
> topics.
>
> It is much better to chop things up into digestible bits. Then summaries of
I would characterize it as an information dump which forces the reader
to make an effort to extract a coherent picture out of it. Further, it is
often not possible to deduce what is the topic of the article in an
outgoing link (the link text is usually a single word), so I click
something and find its not what I wanted and get annoyed.

Arvind
--
Its all GNU to me


from_name: Peter Jaros

subject: [Wikipedia-l] A quick thought about 1.0

body:
On Friday, December 19, 2003, at 01:30  AM, Arvind Narayanan wrote:

> On Thu, Dec 18, 2003 at 09:58:13AM -0800, Daniel Mayer wrote:
>> Erik wrote:
>>> I feel that it is extremely tedious to have to click around
>>> many times and load many pages to get a complete
>>> picture of an issue, a person etc.
>>
>> There is little difference between clicking on a TOC link in a huge
>> article
>> than clicking on a link to another article.
>>
> For me there's a huge difference. My latency on wikipedia
> is usually between 5 and 10 seconds. OTOH I have high bandwidth.
> So I would greatly prefer to download a huge article at once.

Same here.  At least.  But for bigger articles, it's longer.  I'd much
rather read a short article and load expanded information in the
background.  I object to TOC entries, though, because the links have no
context.  The beauty of wiki links (and html in general) does not lie
in TOCs or see-also's.  It lies in the ability to connect information
logically through context.  If a single 'logical' entry is big enough
to bring up the issue of using smaller 'physical' entries---that is,
use a TOC entry with the equivalent of subpages containing sections
thereof---I think the size of the entry needs to be addressed.  I don't
want to read that much in a single entry, and I certainly don't want to
edit it.  And editing *across* multiple pages?  Forget it, it's not
worth it, "Can't someone else do it?".  That feeling hurts the wiki.  A
lot.

If an entry gets to that size and detail, great, let's use the
information, but let's spread it out across a few entries, not just by
breaking it into pieces, but by separating it into multiple topics.
And if that means duplicating a little information, so be it.  As you
say, Arvind,

>> I really hate duplication of effort; If article A refers to event B
>> and
> Why is this duplication of effort? We can simply copy-paste from one
> article to the other.

Very true.

Also, when I look something up, I don't want a long article to read to
find what I want to know.  Remember, Wikipedia Is Not Paper.  That
means that rather than have to put all the information on one topic
*and requisite info* in one place and the shorten it because there's
not enough room, we can include just enough to understand the topic
with a little requisite info---short enough to read quickly---and then
link terms to further elaboration of each background concept.  That way
readers read only what they need to read.  Having more and shorter
articles also encourages them to grow longer, which means more
information on the site---and eventually these can become multiple
articles themselves.  It's a wonderful circle of electronic life.  Ok,
the coffee can kick in now.

My apologies for rambling and twisting myself around.  I'm running on
very little sleep.

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show