subject: [WikiEN-l] Verifiability

body:
The following was already sent in response privately to Steven who had
initially sent this privately by accident. - Ec

steven l. rubenstein wrote:

> Ray Saintonge wrote,
>
>> David Gerard wrote:
>>
>> >Steve Bennett wrote:
>> >
>> >>There really should be different sourcing guidelines for different
>> >>fields in Wikipedia - popular culture is just "different" to history,
>> >>science or geography.
>> >>
>> >Some sort of referencing should be possible. For TV or movie synopses,
>> >the text itself as an implicit reference is obvious and sufficient, for
>> >example.
>> >
>> To some extent we can make use of "standard" references.  The Internet
>> Movie Data Base is a good example for movies, but that won't work for
>> everything.  Many subjects, however, are more controversial and the
>> standards there need to be more stringent .
>
>
> I agree that in certain areas we can make good use of "standard"
> references.  However, this leads me to an issue that has concerned me
> for some time: the use of dictionaries and encyclopedias as sources.
>
> I believe that dictionaries are authorities on the spelling and
> pronunciation of words.  I also think they can be drawn on to account
> for how a word is "commonly" or "popularly" understood.  But I am very
> strongly opposed to relying on them actually to define a term in
> Wikipedia -- at least, in areas of scholarly and professional
> concern.  For example, OED may or may not have a good definition of
> "evolution."  Regardless, I think the definition of "Evolution" in the
> "evolution" article should reflect the  mainstream understanding of
> evolutionary scientists (I do NOT want to go into SPOV vs. NPOV; if it
> makes things easier, I have no problem with (1) specifying that this
> is how evolutionary scientists define it, and (2) mention that
> non-evolutionary scientists have other definitions).  OED may or may
> not have a good definition of "imperialism."  Regardless, I think the
> definition of "imperialism" in the "imperialism" article should
> reflect the  mainstream understanding of political scientists and
> historians (and perhaps even politicians (again, I have no problem
> with (1) specifying that this is how scholars and professionals define
> it, and (2) mention that non-scholars scientists have other
> definitions).  According to our "Wikipedia is not a dictionary"
> policy, we state that it is good to start articles with a definition.
> I think relying on dictionary definitions is (a) lazy (we are letting
> whoever wrote researched the dictionary do our research for us.  This
> is not a problem when it comes to relying on books by scholars in
> writing an article, but dictionary definitions are the ultimate
> product of abstracting from various sources.  This is precisely what
> our job should be), (b) redundant (anyone who has access to Wikipedia
> has access to OED online or Answers.com and can get a definition that
> way, and (c) may very well conflict with the body of the article, if
> we are drawing on sources written by scholars and professionals.  I
> believe that the "Wikipedia is not a dictionary" and the "Cite
> Sources" pages should be revised to address this.
>
> Other encyclopedias are great ways to begin research, since they give
> us an idea of what an article on a topic could cover, and sometimes
> provides references we can turn to.  I also think it is a useful
> exercise to compare our articles to those in other encyclopedias, just
> to get a sense as to whether we have missed something important.  But
> I object to using articles from other encyclopedias as sources for our
> articles.  It seems so patently absurd to me, it is hard to explain
> why -- except I know others do this regularly, so I have to.  So okay,
> it comes down to similar reasons for my rejecting dictionaries as
> sources (at least, in areas of scholarly and professional concern).
> First, encyclopedia articles are the ultimate product of abstracting
> from various sources.  This is precisely what our job should be.  To
> rely on the research of others to me seems to devalue our own role as
> researchers.  Second, since Wikipedia is an encyclopedia, it seems
> terribly derivative to base our articles on the articles of other
> encyclopedias.  Moreover, Wikipedia is an experiment in a new way of
> producing an encyclopedia; to rely on conventional encyclopedias seems
> to undermine our own integrity, what defines us as unique and
> special.  I grant that there may be occasions in which other
> encyclopedias can (like the IMDB Ec mentions) be useful resources, but
> I think these cases should be the exceptions, not the rule.  And I
> think we need to revise our policies to make this clear.

The key to being a good researcher is having the sense of judgement to
decide what is applicable and relevant.  Other encyclopedias can be a
first source of information, not a last source.  We are probably at a
point where the information still available from easily accessible
encyclopedias is close to being exhausted.  It doesn't bother me if the
first attempt at an article is based on one of these, as long as proper
credit is given.  I just randomly opened my 1903 "Encyclopedia
Americana" and found a one paragraph biography on Frederick J. Crowest,
an English writer and editor who was active at the time.  We don't have
an article on him, and, if I were so inclined to write one, I would not
feel wrong to use that as a first source. I would nevertheless be
curious to find out more.  For one thing he was born in 1856.  That made
him 47 years old in 1903.  How much longer did he live?  The questions
are more important than the answers.
I thought that your statement above "I know others do this regularly, so
I have to." was a little strange.  At the risk of seeming a little like
a scold I would respond that teaching a class of freshmen is not an
excuse for acting like one.  For the freshman who just came out of a
high school system where he was never exposed to the idea of research or
for the wikipedia editors who are now in high school it is an important
first step forward.  The rest of us need to be guides to higher
standards.  If a newbie comes along and writes a plausible article
completely without references it's time to begin a dialogue, not the
time to threaten punishment for what he doesn't understand.  We also
need to balance this Scylla with the Charybdis of "No Original Research"

In scientific philosophy  terms a definition is not a falsifiable
statement..  Many words have multiple meanings, and too many people feel
that the sense of a word that they use should have pre-eminence.  In
political topics the result of that exercise can be outrageous.
Specifying a definition at the beginning of an article is a good thing,
because it sets boundaries around subsequent uses of the term in the
article.  When it comes to dictionary issues  I tend to speak as one
whose major activities are on Wiktionary.  In many ways "evolution" has
been hijacked by Darwinism; the word still has a lot of useful meaning
outside of biology.  I see a dictionary as primarily descriptive,
including in matters of spelling and pronunciation.  Which of those
definitions you use is a matter of choice.  If there is nothing suitable
some people invent their own words; Rummel's use of the word "democide"
is absolutely correct simply because that's the way he coined it.

Ec


list: wikitech-l

source: pipermail-mbox

from_name: Guillaume Blanchard

subject: [Wikitech-l] Yet another reason to have a "stable article" system

body:
I'm totally confusing between "validation", "review" and "stable"
concepts and who want what!? On a dynamic site like Wikipedia the
"stable" concept seem very odd for me. Does that imply any restrictions
to modify the article further? Are we all ok to say an article is never
really finished?

Actually, the only problem I see is we can't give any kind of guaranties
about the exactness of a given article's revision. The featured article
label is problematic (at least on French Wikipedia) because we give it
to an article (instead of a revision) and with the open system used by
Wikipedia we can't assure the future revisions will not contain any
errors. In an other hand, any kind of restriction of editing a validated
article is contrary to the open spirit of the Wikipedia project.
Finally, I think we must clearly separate the review and the validation
process. The first is a nice optional feature that tells what the
community thinks about an article and/or revision quality, while the
second is a really important feature that just tells "(we really think)
there is no error in this revision" (this mean an article can be
incomplete but "valid").

("Review" and "validation" are the right words to describe the above?)

My proposal [1] only relate to "validation". The main idea is to allow
marking any revision of an article as "valid" (by community consensus,
validators or an other process to be determined) and use this flag to
change some navigation behaviors and give some visual feedback.

2 navigation behaviors:
- Validate: When consulting an article with a validated revision
existing in history, this validated version is show (otherwise the more
recent non-validated revision is shown). When viewing a validated
revision and a more recent non-validated exist, a link to this revision
is add in navigation panel ("last development"). [default for anonymous]
- Development: As now but when a validated revision exist in article
history a link to this revision is add in navigation panel ("last
validate"). [default for logged users]

Visual feedback:
- A validated article revision has a different class (CSS) to allow
customize its style (different background color, specific information
box, etc.).
- History highlights (via style) the validated revisions.

Any comments are welcome here or on the proposal talk page.

Aoineko / Guillaume Blanchard

[1] http://meta.wikimedia.org/wiki/User:Aoineko/Validation/en


list: wikien-l

from_name: sydney poore

subject:
[WikiEN-l] Original research vs.
	Fact-checking	(Wikipedia:Biographies of living persons)

body:
MacGyverMagic/Mgm wrote:

> I agree with you Sydey, that biographies should be accurate, but
>
>taking information straight from the subject constitutes original
>research and since we can't see their identification papers it's not
>verifiable.
>
>How do you suppose we verify the correctness of a given birthdate if
>there's no newspapers or books stating the date the subject says is
>correct.
>
>(And don't forget you need to verify you're actually talking to the
>subject to begin with)
>Mgm
>
        We need to use the same methods that other organizations use.

        It is illegal to impersonate someone. Pointing this out will
        stop most people from falsifying records.

        Requesting 3 forms of ID with a signed form (If done on line
        electronic signatures are common.)

        Example of the Strictest method
        Proof of Identification
        http://www.bdm.nsw.gov.au/births/proofOfIdent.htm

        I doubt most news organizations require anything this strict.

        Sydney Poore


from_name: Anthere

subject: [WikiEN-l] Re: Biographies of living persons - new draft guideline

body:
David Gerard wrote:
> Anthere wrote:
>
>>David Gerard wrote:
>
>
>>>I've done a rewrite of the proposed guideline at
>>>http://en.wikipedia.org/wiki/Wikipedia:Biographies_of_living_persons/temp
>>> It's rewritten very much in the style of a quickly usable
>>>guideline - you should be able to get the whole idea from the
>>>intro, the rest is details.
>
>
>>I left some comments on the initial version. One thing I would found
>>useful is that a dual document is produced. One to be adressed to the
>>editor (the guidelines) and one to be adressed to the one editing his
>>biography. Sarah initial version was confusing both public, while
>>David's one is now totally oriented toward regular editors.
>
>
>
> The one for the public is [[Wikipedia:Autobiography]].

Ah cool...

And don't you think there are some stuff missing in this page ? Or stuff
maybe that should not be there now ?

I think beginning this page with a citation from Jimbo, to avoid doing
something which he largely does himself, in particular after this has
been mentionned in several places in the press... may actually not be
best. In any cases, this could be used as an argument by the complainer
in the future *against* this page and its recommandations ;-)

There is no clear explanation about how the system works at the top of
the page.

There is nowhere mention of who they should contact in case they object
*strongly* to the content.

And nowhere is gently mentionned that maybe (MAYBE) they could be right
in complaining. It mostly insist in all what would be *wrong* in them
editing the article, and not in what *we* could be wrong about and the
people in their right to complain.

I understand you take the stance of the "editors" trying to fight vanity
pages... and this is definitly important to do. Let me just take the
other stance, the one of the visitor.

 From a visitor perspective, finding *false* information on his
biography, and being perplex, this page, indicating that it is basically
bad for him to correct false information, is a bit troubling.

Please, do not answer me [[sofixit]]. I do not have the ability to do
this in about 150 languages. And I already give a huge amount of time to
  the project. This is just *my* feeling to try to explain why we might
get so many complaints on OTRS. I was asked to give my opinion, I do
give it. I just can't myself try to fix all pending issues which might
get us (me, not you) being sued :-(

>>Now, one thing that is imho, strongly missing in David version is
>>somehow the description of HOW a person might feel when she discovers
>> very questionable statements about her all over the web... and has
>>very little idea how Wikipedia works. She must really feel like a
>>stranger falling in a strange land.
>>I think that I can give this perspective, due to the number of times
>>I had to answer one of these editors with a biography on OTRS. Some
>>pretty cool, some totally abashed, some absolutely furious.
>>While it is important to explain editors which guidelines to follow,
>>it is also important to explain to them the dismay of those with
>>biographies they perceive wrong (and which are sometimes wrong
>>
>>>actually).
>
>
> Check the history - my first version at /temp included the paragraphs on
> this from SlimVirgin's version; Morven changed them to instructions for
> those who don't like their biography.

I do not really care about who wrote what. I just look at the result and
comment it :-)

>>There are always too sides in a dispute and in this, I believe very
>>very much in Sarah empathic approach. And again, I say this from the
>>perspective of one who has precisely to deal with some enraged people
>>on OTRS, mishandled by an editor.
>>It is important to remember these guys are most of the time acting in
>> all good faith.
>
>
>
> Indeed. However, SlimVirgin's first version (and its title) leant too
> much towards sympathetic point of view IMO. Which is not NPOV, not at all.

I agree you were correct to change the title.

>>Aside from this, I believe the paragraph about legal threats is
>>problematic. I wish that it is reworked. As a reminder, the
>
>
>
> I just cut'n'pasted that from Slim's version; please kill it if we
> shouldn't have it, or rework it as is appropriate.

Yup.

I suggest raising the issue on juriwiki-l at wikimedia.org

I'll put them a link to the page for their consideration.
They will know what the legal implications of the phrasing are, much
much better than I could myself :-)

>>Thanks a lot in any cases for all those working on these guidelines.
>>Legal issues over biographies, most of you know this, are currently a
>> huge issue for the board, we really appreciate your help here to
>>deal with this. The Foundation will suffer of any legal action,
>>whether if right or wrong.
>
>
>
> - d.

A comment, just aside... as a person having her biography on WP. It is
just a stub, and unlikely to ever grow, so I have not to complain
because no one will ever pretend I am a pornograph, or have been
prostituting myself in the past.

Still...

I hardly dared changing my age when I noticed the year of birth was
erroneous on one project.
I will not change the number of my kids and I did not update my
professional situation, though it has changed and could cause me
prejudice in the future, for not reflecting the reality of my life.

Why not ? Because they are no primary sources which could be trusted on
the internet to assert my claims. According to your guidelines, I must
not do this "Facts, retellings of events, and clarifications which you
may wish to have added to an article about yourself must be cited from
an external source."

Eheh, I find that a bit ridiculous... but to follow guidelines, I let
untrue information on my page ;-) I can't prove they are untrue. It does
not matter. But the day it writes I am currently prostituting myself to
make a living... guidelines or no guidelines for me not to edit my
article, unless there is a valid source, I will edit my article and
remove the information. If reverted and blocked myself, I will know
where to go, unlike a "victim" who is only offered this template...

We should take care of writers, but also of readers. Imho.


body:
Matt Brown wrote:
> On 12/20/05, David Gerard <fun at thingy.apana.org.au> wrote:
>
>>Check the history - my first version at /temp included the paragraphs on
>>this from SlimVirgin's version; Morven changed them to instructions for
>>those who don't like their biography.
>
>
> Do you think that paragraph should be rewritten to be wholly from the
> perspective of how current editors should behave?  If so, we should
> create a new document from the perspective of 'So, you find someone's
> written about you on Wikipedia ...'
>
> And [[Wikipedia:Autobiography]] is not it, at least not in its current form.
>
> -Matt

Matt is correct.

Ant


from_name: Blackcap

subject: [WikiEN-l] {{fact}}

body:
On 12/20/05, Blackcap <snoutwood at gmail.com> wrote:
>
>
>
> On 12/20/05, David Gerard <fun at thingy.apana.org.au> wrote:
>
> > I think it has every right to be annoying. It also makes it clear to the
> > reader "ah, that's not verified. Oh yes, this is a work in progress,
> > isn't it."
> >
>
> I like it too... still, the lack of square brackets drives me nuts. Ah
> well, maybe I'll fix it when I have a minute.
>
> --
> [[User:Blackcap]]

Done!

--
[[User:Blackcap]]


from_name: Ray Saintonge

subject: [WikiEN-l] Verifiability

body:
David Gerard wrote:

>Ray Saintonge wrote:
>
>
>>David Gerard wrote:
>>
>>
>>>We can write guidelines and guidelines and guidelines, and no-one will
>>>care except the writers or someone looking for a stick to beat their
>>>opponent on the wiki with - because you can't Taylorise clue.
>>>(When was the last time you read the Manual of Style through? Me
>>>neither.)
>>>
>>>
>>One could begin with Taylorizing the Taylorizations.
>>
>>
>Heh. I have started in a slow way tightening up some of our ridiculously
>bloated, opaquely-written and special-case-riddled guideline and policy
>pages; I look forward to the time to really go the hack on the MoS. I
>think it could be one-third the length without losing a single useful
>detail. Heck, someone might even want to read it for reasons other than
>querulousness.
>
I have tried similar things at Wiktionary, where I often trace a wide
circle of "What links here" that ends up where I started.  The problem
is not just with the people writing imaginative new policies, but also
with individuals who come along with a great plan to reorganize
everything.  They start with a lot of enthusiasm, but half way through
their project they fall off the edge of the earth never to be seen
again.  Then at least two others develop contradictory policies on the
same thing on two different pages; this entitles newbies to use
whichever one they found first to justify whatever action they want to
take.  One never knows when one will be deleting someone's pet policy>

Being bureaucrat and the most senior active editor in the project buys
me a certain amount of sin points, but I would prefer to limit that kind
of boldness to situations which really matter.  Dear Abby, what would
you do? :-)

Ec


from_name: Steve Bennett

subject:
[WikiEN-l] Defamatory Biographies - another problem
	loomingforWikipedia?

body:
> Until reducing multiple stubs becomes a bannible offence, I
> will continue to do it, based on my editorial discression.
> you have been warned.

You may want to consider the fact that it takes more time and effort to
add stubs than it does to remove them.

Personally, I see stubs as being like throwing out a lifeline to some
relevant community that you don't even know yet. It's like saying, "Hey,
I created this short article about an Australian rock star/politician,
for god's sake can someone who knows about Australian rock stars or
Australian politicians come along and clean it up!" Removing the
politician half, for example, would reduce significantly the number of
people who might find it and fix it.

IMHO, stubs are vulnerable because they have so few links to them or
from them, and are so likely to get "lost". More links increases the
chances that some kind person will stumble upon it and fix it. I never
actively seek out stubs to work on - but if I hit one, I occasionally
flesh it out a bit.

Steve


subject: [WikiEN-l] Well, we have at least one important supporter

body:
Sherool wrote:

> On the topic of webcomic strips I found this a little amusing (it's a
> few  days old so sorry if it's already been posted, I'm currently up
> to 836  unread messages from the mailing list :P):
>
> http://www.penny-arcade.com/comic/2005/12/16

Wow!! I've been plowing through it the last couple days.  I must be
doing something right to have my list down to a mere 185. :-)


from_name: Sam Fentress (Asbestos)

subject:
[WikiEN-l] Original research vs.
	Fact-checking(Wikipedia:Biographies of living persons)

body:
On 12/21/05, Steve Bennett <stevage at gmail.com> wrote:

>
> It occurs to me that in academia, one occasionally sees "personal
> correspondance" or "publication forthcoming" cited.  Is there something
> wrong with stating "The New York times gives Jim Smith's birthday as 24
> May 1964, although Jim has stated that it's 24 May 1965[1]" where [1] is
> Personal email to Wikimedia Foundation, 5 Nov 2005.  It's verifiable in
> the sense that you could always email Wikimedia and ask them if that's
> true.
>
> Steve
>
>

If it's a personal email to the Wikipedia Foundation, or to our lawyers or
something, then that's a different matter. The problem is that the Wikimedia
Foundation aren't the ones putting the facts in the articles. It's if
User:RandomName puts in a new date of birth and cites at the bottom
"Personal Correspondence". There's no way we can check if that's true, and
there's no one to turn to if the article's subject starts demanding
corrections and accountability.

Sam
--
Asbestos
http://en.wikipedia.org/wiki/User:Asbestos


body:
    http://en.wikipedia.org/wiki/Talk:Andrea_Dworkin/Archive1 is the brief

>>debate we had over whether or not to go with unconfirmed reports of
>>her death. We predated the Guardian, the first major media to pick it
>>up, by at least 24 hours and probably more.
>>
>>(I still think we should have waited until after the Guardian published,
>>though)
>>
>>
>>
>>     Yeah, I was thinking of Dworkin, not Sontag. Thanks. And I agree
>>     we should
>>
>>     have waited.
>>
>>     TD
>>
                Wikipedia is an encyclopedia. Death information can wait
                for reports in the media. I think the example above is
                original research and should have waited. I hope
                everyone understands that I'm not advocating original
                research. I'm advocating fact-checking.
                Sydney


from_name: Brion Vibber

subject: [Wikitech-l] MediaWiki 1.5.4 released

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

MediaWiki 1.5.4 is a security and bugfix maintenance release.

A hardcoded internal placeholder string has been replaced with a random
one. This closes a hole where security checks in inline style attributes
could be bypassed, injecting JavaScript code that could execute in
Microsoft Internet Explorer.

Other browsers would not be vulnerable.

Several minor fixes are included in this release, most notably a fix
to clear the "you have new messages" flag properly for usernames
containing spaces when e-mail notification is enabled.

See the changelog at the end of the release notes for a full list of
fixes.

Release notes:
http://sourceforge.net/project/shownotes.php?release_id=379951

Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.5.4.tar.gz?download

MD5 checksum:
c5cff706c4d2fc8dd5aabd10f1714be0  mediawiki-1.5.4.tar.gz

SHA-1 checksum:
12ccdbdd295152937595d4a00c41ae156bf19015 mediawiki-1.5.4.tar.gz

Before asking for help, try the FAQ:
http://meta.wikimedia.org/wiki/MediaWiki_FAQ

Low-traffic release announcements mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce

Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

Bug report system:
http://bugzilla.wikimedia.org/

Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDqfJ+wRnhpk1wk44RAodbAKCP6RPb2vysJTeUMMMq5eT9EXUkUgCfXzKL
mL8OeBGrSnXpPWteNI42ylI=
=oCrk
-----END PGP SIGNATURE-----


from_name: Conrad Dunkerson

body:
Bryan Derksen wrote:

> Every type of stub I've seen so far has some sort of corresponding
> non-stub category that the article can be placed in, so whenever I
> remove extra stub templates I make sure the article's properly
> categorized. They don't get "lost" that way.

Hmmm... instead of having a hierarchy of 'categories' and a parallel
hierarchy of 'stub categories' it might make sense to just have one
hierarchy and a single generic stub notice. Only drawback I can see is
that there isn't currently a simple way to identify 'articles in this
category with a stub notice' or 'articles in category-1 AND category-2'.
Still, it probably wouldn't be too difficult to have category views with
'display only articles also in the Stub category'. Would cut the
categorization and sorting work significantly.


subject:
[WikiEN-l] Original research vs.	Fact-checking
	(Wikipedia:Biographies of living persons)

body:
sydney poore wrote:

>                 Wikipedia is an encyclopedia. Death information can wait
>                 for reports in the media. I think the example above is
>                 original research and should have waited. I hope
>                 everyone understands that I'm not advocating original
>                 research. I'm advocating fact-checking.

It could have gone on Wikinews as 'reports indicate' until verified by
mainsteam press.


subject:
[WikiEN-l] Original research
	vs.	Fact-checking(Wikipedia:Biographies of living persons)

body:
Sam Fentress (Asbestos) wrote:

>On 12/21/05, Steve Bennett <stevage at gmail.com> wrote:
>
>
>
>>It occurs to me that in academia, one occasionally sees "personal
>>correspondance" or "publication forthcoming" cited.  Is there something
>>wrong with stating "The New York times gives Jim Smith's birthday as 24
>>May 1964, although Jim has stated that it's 24 May 1965[1]" where [1] is
>>Personal email to Wikimedia Foundation, 5 Nov 2005.  It's verifiable in
>>the sense that you could always email Wikimedia and ask them if that's
>>true.
>>Steve
>>
>>
        If it's a personal email to the Wikipedia Foundation, or to our
        lawyers orsomething, then that's a different matter. The problem
        is that the WikimediaFoundation aren't the ones putting the
        facts in the articles. It's ifUser:RandomName puts in a new date
        of birth and cites at the bottom"Personal Correspondence".
        There's no way we can check if that's true, andthere's no one to
        turn to if the article's subject starts demandingcorrections and
        accountability.

Sam

                Sam
                You said ''There's no way we can check if that's true,
                andthere's no one to turn to if the article's subject
                starts demandingcorrections and accountability.''

                This seems to be where we see thing differently. I know
                birth, marriage, divorce, hometown, college, and
                employment are verifiable. If you have the _correct
                _information it is pretty easy. If someone provides
                valid ID (a mixture of distant and current) and gives
                Wikipedia the correct information, then we should be
                able to confirm it from outside sources. This is
                fact-checking not original research.
                -- Sydney Poore
                Go Bengals!


subject:
[WikiEN-l] Original research
	vs.	Fact-checking	(Wikipedia:Biographies of living persons)

body:
Conrad Dunkerson wrote:

> sydney poore wrote:
>
>>                 Wikipedia is an encyclopedia. Death information can wait
>>                 for reports in the media. I think the example above is
>>                 original research and should have waited. I hope
>>                 everyone understands that I'm not advocating original
>>                 research. I'm advocating fact-checking.
>
>
> It could have gone on Wikinews as 'reports indicate' until verified by
> mainsteam press.

        Wikinews is different.  That is fine.

--
Sydney Poore

Go Bengals!


body:
charles matthews wrote:

> "sydney poore"  wrote
>
>> To add unpublished details to a biography is an example of original
>> research.
>> (100% disagreement. A person?s date of birth is not original
>> research. DOB is a basic fact of society. It is verified daily by a
>> wide spectrum of organizations.)
>
> I have felt for a long time that OR _can_ be abused, as a stick to
> beat additions to articles.  The principle does seem to be well
> established, though.  This particular issue suggests to me that we
> haven't yet got the policy quite into focus.
>
> We do want to stop people asserting they have important private
> sources, putting 2 and 2 together to make 5, and putting that on WP.
> Which is a recipe for conspiracy theorists running amok.  It could be
> a real difficulty in some areas (e.g. coverage of espionage).  To say
> that simple fact-checking is out makes, however, for an unpleasant
> dilemma: keep something you know is wrong on the site, or take down a
> wrong fact like DoB and simply leave a gap.
>
> Charles

            Fact-checking. I'm talking about correcting information if
            verifiable facts are provided, updating articles to keep
            current, or verifying as part of a quality assurance program.

            Sydney Poore
            Go Bengals!


from_name: Servien Ilaino

subject: [Wikitech-l] Re: Obstetrician needed for 7 new Wikipedias

body:
I don't see the problem here all have ISO codes who cares about
capitalisation or not, ISO codes are not capitalised for as far as I know
and most will certainly never change and will always stay that way.

Correct and official ISO codes:
nds-nl; Nedersaksisch (personal reply from ISO code commission)
rmy; Romani Vlax (official code; ethnologue)
pdc; Pensylvanian German (official code; ethonologue)
lij; Liguarian (official code; ethnologue. current proposal "roa-lij" or
"lij")

Semi-official codes:
vls; West-Vlaams (the term Flemish is used as collective term for Dutch
dialects in Flandres, but is mostly associated with West-Flemish, so I've
heard. "gem-wvl" could be an option aswell)
ksh; Ripuarian (ksh; Keulsh, Ripuarian not listed on ethnologue)

Not listed on ethnologue, "dialect code" is used (gem-, bat-, map- etc):
bat-smg; Samogitian (not listed on ethnologue)
qbn or map-bms; Banyumassan (not listed on ethnologue)

Servien

2005/12/21, Gerard Meijssen <gerard.meijssen at gmail.com>:
>
> Ray Saintonge wrote:
> > Gerard Meijssen wrote:
> >> Hoi,
> >> Actually you misunderstand me. When you mix standards and the
> >> difference between those standards disappears because of restraints
> >> that YOU are under, it means that what you do is not up to standard.
> >> Consequently it cannot be said that we implement the ISO-639 codes.
> >> When we adopt the ISO-639-3 codes we have the SIL information
> >> included. It is a custom to keep the two character ISO-639-1 codes as
> >> well. This is in my opinion the only way out of this mess. NB We have
> >> been using these codes already for over a year in Wiktionary.
> >>
> >> Yes I know. URL's are case insensitive. We can implement ISO-639-3
> >> and we should do this. NB there are even standard formats to indicate
> >> that a certain script is used as there are ISO codes for those too
> >> (ISO 15924).
> >>
> >> So we either adopt a standard and do it right or we should not say
> >> that we adopt a standard. If you want an official statement as to the
> >> stability of the ISO-639-3, I think that I can get you that.
> >
> > One also needs to remember that ISO 639-3 still reserves a block of
> > codes beginning with the letter "q" tha are user defined.  These can
> > be used for languages that are not included in the standard.  The
> > languages where that would be needed are not going to be the most
> > popular or best known, and are unlikely to become big wikia.  If at
> > some future time thay are given a standard code conversion should not
> > be a huge operation.
> >
> > Ec
> Hoi,
> Many of the current Wiktionaries make use of the ISO-639-3 codes. Here
> there is no relevance  as to the size of a prospective Wiki. We use the
> code to indicate that a word is in a given language. I have extended the
> data design of Ultimate Wiktionary to include room for a translation
> framework. The idea is that is will help us manage the translation the
> Mediawiki messages. Given that UW will be a Mediawiki application and
> that we want the localisation for the languages that make use of it
> (basically all of them) we need a way to manage the translations in a
> structured way..
>
> Please have a look at
>
> http://meta.wikimedia.org/wiki/Ultimate_Wiktionary_data_design#Managing_translations_for_Wikidata_and_other_fixed_texts
> and give me your questions, your comments.
>
> Thanks,
>    GerardM
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


list: textbook-l

from_name: pikola Thierry

subject: [Textbook-l] about learning vocabulary using images from commons

body:
Hello,
I would like to hear some feedback about the wikibook
http://es.wikibooks.org/wiki/Vocabulario_%28es%29 from
those working on language learning wikibooks.

This wikibook is only written in the learning language
because the images should be enough to understand its
meaning. The great advantage of this system is that we
only need one wikibook to learn one language.

I still have to improve it much. Until now it only has
vocabulary. But I want to create a reference area
where lexical words will link in order to solve
gramatical difficulties. The references tables should
be simple and also monolingual.

If there is positive feedback, I am planning to
translate it into English into the English wikibooks.

Thank you,
Javier Carro

___________________________________________________________________________
Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.
T?l?chargez sur http://fr.messenger.yahoo.com


from_name: Edward Z. Yang

subject: [Wikitech-l] Special:UploadLocal needs a better UploadForm

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

I previously emailed this mailing list (
http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/21070
) asking about uploading big files. The single I response I recieved was
not sufficient... Commonist did not support non-Wikimedia projects, so I
set off to create my own special page extension to MediaWiki.

I have completed it, but there are a few hairy bugs pertaining to
MediaWiki that I need to sort out. And, perhaps, a friendlier API for
UploadForm.

It was a tricky problem: I wanted to keep code duplication down to a
minimum, but I had to use a class that was not designed to be extended
and have different functionality: it was a very procedural/transaction
script style class. I ended up extending it, overloading the
constructor, and supplying all the information that the constructor
previously determined from the reqest.

So... my hairy bug:

When an image upload is successful, wgOut gets this idea that we should
redirect to the image page. This is a bad idea for multiple uploads for
obvious reasons. However, I have not been able to isolate the source of
the call: a trace to the point where the header is called reveals that
wgOut buffers output.

I have overloaded these functions: mainUploadForm(), uploadError() and
showSuccess(), so they are probably not sending the redirect, but it
persists. I finally solved the issue by, after executing all the forms,
setting the redirect back to '', which is hackish.

Also, $wgMessageCache-> seems to be malfunctioning inexplicably for
certain messages. Some of them are instantiated, some aren't. Are there
any caveats to the function?

My main beef, however, is the way my subclass blatantly ignores all the
private recommendations and overloads them. Are they used in the sense
of being protected? Since I'm not following the rules, my extension is a
hack, albeit an elegant one that doesn't touch the original code and
minimalizes duplication. I'd volunteer to refactor SpecialUpload.php:
it's a fairly isolated piece of code, and splitting up the code into
more functions will make custom upload extensions much easier to write.

I also have to publish the extension. So... what do you think?

- --
 Edward Z. Yang      Personal: edwardzyang at thewritingpot.com
 SN:Ambush Commander Website: http://www.thewritingpot.com/
 GPGKey:0x869C48DA   http://www.thewritingpot.com/gpgpubkey.asc
 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDqdTpqTO+fYacSNoRAtBBAKCD90gQ4GHGBWxmuheKb3FguRVqpACfeojm
fg8H6uvBCENSypUixkapuDI=
=JOLT
-----END PGP SIGNATURE-----


list: wiktionary-l

from_name: Gerard Meijssen

subject: [Wiktionary-l] [Fwd: Just for fun]

body:
Hoi,
There are some people that do not like the name "Ultimate Wiktionary"
for the Ultimate Project. The name is used for the project. This does
not mean that we have to use ultimate.wiktionary.org as its URL. Sue
Ellen came up with the name Wiktionary2, Arle came up with this design.

I am sure there will be more suggestions to choose from.. We just have
to come up with them :)

Thanks,
   GerardM

Just for fun:

Same font as the Wikipedia logo (Hoefler Text, which demonstrates
someone in the early stages of Wikipedia was a Mac user since Hoefler
Text is an Apple font).

Take this as something tossed out: even if the name Wiktionary^2 is
used, I won't be hurt if this isn't used...

-Arle


list: foundation-l

subject:
[Foundation-l] "Fair Use does not apply to DSM material or any
	other APA/APPI content." um, wtf?

body:
Any File wrote:

>David Gerard wrote:
>
>
>>        [Response re: DSM-IV-TR criteria (all identifiers removed,
>>original forwarded to permissions at wikipedia.org):
>>
>>            We are inclined to deny Wikipedia permission to use our
>>content as we do not allow anyone to alter our material and we do not
>>want our material posted online. I can assure you that we have
>>complete rights to our material and Fair Use does not apply to DSM
>>material or any other APA/APPI content.
>>
>>
>They want to keep for themselves they right of seling the definitions
>and the right of chaning them.
>
>I know that copyright apply only to intellectual right, not to facts.
>I can not proibits people to publish that 14-Carbonuim-14 or
>230-Thorium are radioactives.
>
>If they claim that these definitions are covered by copyright rights
>they are claming that they are ficticious, just like a text of a novel
>is.
>
Copyrighting a definition that has the purpose of standardising a
concept across an industry doesn't make sense.  That would force those
who are not members of their cabal to define the term differently, and
thus effectively defining a different disorder.  The resultant ambiguity
would seem contrary to public policy in health care.

The copyrightability of definitions is a troubling idea in a broader
context.  The accuracy of definitions can depend on precise wording.
If, with the intent of circumventing copyright infringement we rewrite a
definition we may no longer be talking about the same thing.

Ec


list: wikimedia-l


from_name: Adrian Buehlmann

subject:
[Wikitech-l] Re: Stable version now with cache (Tim,
	this one's for you!:-)

body:
"Gregory Maxwell" <gmaxwell at gmail.com>
wrote in message
> [snip]
>
> Anything else would defeat the purpose. We need to provide the right
> tools to minimize the pain of operations like this.   ... And, of
> course, avoid putting factual information in template pages if that is
> followed strictly, who cares if a 'stable' page has a somewhat
> outdated look and feel.

That sounds really promising. I hope this decouples rippling changes
from templates to articles.

If I understand this correct, this might help a lot on
{{en:book reference}} [1] and {{en:web reference}} [2], as those use that
unpopular {{en:qif}} [3] (BTW, qif is now protected).

It does not matter, whether an article uses an old version of book
reference or not. A manual action per using article to update to
a newer version of book reference would be just fine if we could in turn
continue using book reference in articles (which we can't if {{qif}} is
eliminated [4] without an equivalent replacement, which might possibly
be AzaToth's code proposal [5]).

Templates should not be used to spread updated information onto a bunch
of articles, if this harms the servers (and it obviously does, as it
is implemented now).

Adrian Buehlmann [6]

References:
[1] http://en.wikipedia.org/wiki/Template:Book_reference
[2] http://en.wikipedia.org/wiki/Template:Web_reference
[3] http://en.wikipedia.org/wiki/Template:Qif
[4] http://mail.wikipedia.org/pipermail/wikitech-l/2005-December/033092.html
[5] http://meta.wikimedia.org/wiki/User:AzaToth/Logic
[6] http://en.wikipedia.org/wiki/User:Adrian_Buehlmann


from_name: Aron Rubin

subject: [Wikitech-l] Re: which html constructs are evil

body:
Magnus Manske wrote:
> Uwe Brauer wrote:
>> Right, I find the : and :# :* especially annoying since, they only
>> work for one single (long line) but not for a paragraph. That's why I
>> prefer much
>>
>>

>>
>>

>> over : etc. So I understand correctly the use of such constructs and
>>
>> Is ok?
>
> IMHO blockquote is OK, as we do not have an equivalent in wiki markup.
>
> We do, however, have wiki markup for lists, in which case wiki markup is
> always preferred.
> Same goes for tables (yes, the syntax is weird),
, bold/italics, dd/dt.

I have taken to generating some templates like Template:" (aka
Template:%22) for example which is specified as:

{{{1}}}

written this looks like:
{{"|This is a quoted set of text}}

I suppose you could also do something like this for Template:" :

{{{1}}}
{{{2}}}

used like this:
{{"|This is quoted text|
    Aron Rubin}}

Aron

--

ssh aron at rubinium.org cat /dev/brain | grep ^work:

Aron Rubin                       Member, Engineering Staff
Lockheed Martin                  E-Mail: arubin at atl.lmco.com
Advanced Technology Laboratories Phone:
3 Executive Campus               Fax:
Cherry Hill, NJ USA 08002        Web:    http://www.atl.lmco.com


body:
> impulsively. Still, I very much think it makes the article
> look silly to have more stub templates than content. Adding

Some cynics would say that there are two solutions to that problem :)

Steve


from_name: Any File

body:
David Gerard wrote:
>
>         [Response re: DSM-IV-TR criteria (all identifiers removed,
> original forwarded to permissions at wikipedia.org):
>
>             We are inclined to deny Wikipedia permission to use our
> content as we do not allow anyone to alter our material and we do not
> want our material posted online. I can assure you that we have
> complete rights to our material and Fair Use does not apply to DSM
> material or any other APA/APPI content.

They want to keep for themselves they right of seling the definitions
and the right of chaning them.

I know that copyright apply only to intellectual right, not to facts.
I can not proibits people to publish that 14-Carbonuim-14 or
230-Thorium are radioactives.

If they claim that these definitions are covered by copyright rights
they are claming that they are ficticious, just like a text of a novel
is.

AnyFile


from_name: GerardM

subject: [Wiktionary-l] Re: [Fwd: Just for fun]

body:
Hoi,
As the logo provided by Arle was not included by the mail server, I
have uploaded it to Commons..
http://commons.wikimedia.org/wiki/Image:Wiktionary2.gif

Thanks,
   GerardM

On 12/21/05, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
> Hoi,
> There are some people that do not like the name "Ultimate Wiktionary"
> for the Ultimate Project. The name is used for the project. This does
> not mean that we have to use ultimate.wiktionary.org as its URL. Sue
> Ellen came up with the name Wiktionary2, Arle came up with this design.
>
> I am sure there will be more suggestions to choose from.. We just have
> to come up with them :)
>
> Thanks,
>    GerardM
>
>
> Just for fun:
>
>
>
> Same font as the Wikipedia logo (Hoefler Text, which demonstrates
> someone in the early stages of Wikipedia was a Mac user since Hoefler
> Text is an Apple font).
>
> Take this as something tossed out: even if the name Wiktionary^2 is
> used, I won't be hurt if this isn't used...
>
> -Arle
>


subject: [Wiktionary-l] [Fwd: [Fwd: Just for fun]]

body:
Hoi,
As the suggested logo was not included by the mail server, I did upload
for you to Commons.. It can be found here
http://commons.wikimedia.org/wiki/Image:Wiktionary2.gif
Thanks,
   GerardM

Hoi,
There are some people that do not like the name "Ultimate Wiktionary"
for the Ultimate Project. The name is used for the project. This does
not mean that we have to use ultimate.wiktionary.org as its URL. Sue
Ellen came up with the name Wiktionary2, Arle came up with this design.

I am sure there will be more suggestions to choose from.. We just have
to come up with them :)

Thanks,
  GerardM

Just for fun:

Same font as the Wikipedia logo (Hoefler Text, which demonstrates
someone in the early stages of Wikipedia was a Mac user since Hoefler
Text is an Apple font).

Take this as something tossed out: even if the name Wiktionary^2 is
used, I won't be hurt if this isn't used...

-Arle


from_name: charles matthews

subject: [WikiEN-l] Improper block redux

body:
Bad karma, man.

Charles


from_name: Karl A. Krueger

subject: [WikiEN-l] SPOV threatens NPOV

body:
It seems to me that the sides of this debate are somewhat talking past
each other.  I take the opposition to the term "pseudoscience" as based
on the claim that we should not be judging whether particular
experiments or observations are done scientifically or not.

In that, I actually agree.  Wikipedia isn't a judge or critic of
scientific methodology.  In such cases we should report what was done
and how the world responded to it.

But I've been talking about fields where there _aren't_ any experiments
or methodology to report on.  There's just speculation, tradition,
marketing, or religious pronouncement ... and an adherent claiming that
the noises of same are "scientific".

I just don't see what's non-neutral about saying that speculation
doesn't count as science just because someone says it is.  Or that while
3000-year-old religious tradition is a fine thing, it isn't a form of
scientific methodology.

Is it the "pseudo-" prefix, that some people have taken as an imputation
of criminal fraud?  We could simply say "nonscience" or "not based on
experiment" or whatever instead.  But I don't think we should fail to
report the fact that some fields _do_ claim to be "science" for
political or marketing reasons, even when there's no science around.

--
Karl A. Krueger <kkrueger at whoi.edu>


from_name: Phil Boswell

subject:
[WikiEN-l] Re: Defamatory Biographies - another problem
	loomingforWikipedia?

body:
"Angela" <beesley at gmail.com> wrote in message
news:8b722b800512210536t474b01acy39d04cdf3a23f410 at mail.gmail.com...
[snip]
> It's possible to add a stub category without adding a stub template.
> Perhaps this would be a suitable compromise between those who need the
> categories to be there and those who don't want multiple "this is a
> stub..." notices on one article? Compare
> <http://en.wikipedia.org/w/index.php?title=Ambrosius_Stub&oldid=27617688>
> with
> <http://en.wikipedia.org/w/index.php?title=Ambrosius_Stub&oldid=27615177>,
> for example.

If you don't like stub notices, isn't it possible to fix your personal CSS
so they don't show up?

I'm sure there's instructions somewhere, or if necessary, plenty of people
who would be more than happy to help.

HTH HAND
--
Phil
[[en:User:Phil Boswell]]


list: wikipedia-l

from_name: Wikipedia Romania (Ronline)

subject: [Wikipedia-l] Re: Stable versions policy

body:
>
> If you read Brion's message carefully, you will realize that the concept
> of stable versions he refers to in the present system are commonly
> called "protected pages". I trust you have heard of those.
>
> --Michael Snow

 One thing I don't like is people trying to ram new policies down our
throats in the pretext that "they're already there" or "they won't cause
significant change". There is currently nothing like stable versions at all
on Wikipedia. What's commonly called protected pages are pages which are
protected for vandalism, etc. I have never so far seen a page protected just
because it is a complete article. That is, protected pages are not a article
quality tool, but rather an anti-vandalism structure. And they should be
kept that way.

Sure, stable versions would use the same system as protected pages - the
problem I have is with their function, with the concept of protecting
"completed articles", not with the way in which the software is coded for
them.

Ronline


from_name: Bryan Derksen

subject: [Wikipedia-l] Stable versions policy

body:
Magnus Manske wrote:

>I actually haven't implemented the "view stable as default" mechanism
>yet, and there's no technical need for that. Currently, there's only a
>header describing what kind of version you see right now, and if there's
>an alternative. I won't mind if it stays that way.
>
>
Nor I. A "view most recent stable version" link would be handy to let
people easily jump there, but not really vital.

>>But our goal isn't to _show_ an encyclopedia to people, it's to get
>>people to help us _write_ one. Let Answers.com worry about showing our
>>material to people.
>>
>>
>Funny.
>en.wikipedia.org says in its logo "Wikipedia - the free encyclopedia".
>So when normal people (not wikipedians;-) come to that page, what do you
>think they expect to see? It's not "Wikipedia, the wiki that develops
>texts for the encyclopedia you can see at Answers.com".
>
>
If people have a misperception about Wikipedia, I think we should try to
change that misperception rather than redefining the project to fit it.

>The status and the *perception* of wikipedia has changed since 2001.
>We're not trying to build an encyclopedia anymore. We /have become/ one.
>
>
We are in possession of many of the raw materials for one, but we are
still a work in progress. It says so on [[Wikipedia:About]], which I
find more useful as a reference than the tagline on a logo. If we're not
trying to build an encyclopedia any more should we remove the edit links
entirely? I know you're not really proposing that, but only due to
assuming good faith - taking your statement solely at face value implies
to me that you think Wikipedia's "done."

It can't be "done." What would I do for the rest of the century? I've
already made room in my schedule.

>In 2001, we were not really used as a source of knowledge. That /might/
>have started 2002, or later. Today, we are one of the largest
>repositories of knowledge. We can now either
>1. teach every single one of our potential users in the ways of wikis
>and how to use them, look through the page history, and still treat
>everything they read with utmost caution, /or/
>2. present a random user a good encyclopedia, with the option for more
>(current versions, editing, the like)
>
>I'd prefer #1, but, well... :-)
>
I call logical fallacy, this is clearly a false dichotomy. Why must
option 1 demand perfection in order to be acceptable, with option two
being the only possible alternative if perfection cannot be achieved?

I say we go with option 3: "do what's best for developing Wikipedia's
content by trying to get more people involved in editing even if this is
not ideal for people who come to Wikipedia solely to read it, because
our most important target audience is not those who come here to read
our material but those who want to _reuse_ it." That's the whole point
of doing this under the GFDL, after all.


from_name: Andrew Gray

subject: [WikiEN-l] Re: Broken 'Create Account' Page

references:
<000101c60567$7d8f6e00$ea01a8c0@minou>
	<43A870D6.3060906@student.canterbury.ac.nz>
	<fb7fdd9c0512210303hdfe4571h1d42f285b59f5ade@mail.gmail.com>
	<dobju0$80s$1@sea.gmane.org>
	<fb7fdd9c0512210517w47ab1af2n12735bf6a0f6d6a2@mail.gmail.com>
	<43A9A0B8.7090807@student.canterbury.ac.nz>

body:
On 21/12/05, George Jenkins <gvj11 at student.canterbury.ac.nz> wrote:

> Thanks. That should cause a little less confusion.
>
> However, the next part of my problem is that my compaines IP address
> still blocked. Could someone who has the power to unblock IP's please
> unblock 202.37.96.11 (See http://www.apnic.net/apnic-bin/whois.pl for
> evidence that this is IP is not an open proxy, rather it belongs to my
> company, Tait Electronics).

I've unblocked for the time being, since this looks valid to me; I'll
drop Curps a line. Apologies for any inconvenience.

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


from_name: David Gerard

subject: [WikiEN-l] Parascience subst. pseudoscience

body:
Ray Saintonge wrote:

> Being scientifically accurate, no matter where it leads us, is superior
> to being todies of SPOV-pushing liars.

Er, WTF? What on earth are you talking about? "SPOV-pushing liars"?

- d.


subject:
[WikiEN-l] Defamatory Biographies - another problem	looming
	forWikipedia?

body:
David Gerard wrote:

>For those revolted by multiple stubs (and I agree that they have all
>Geoff's listed points against them), the talk page could be workable -
>they wouldn't be blots on the article warranting {{toomanyboxes}} and
>they'd still be findable in the relevant stub category. WSS would need
>collective persuasion that this was a good idea, else they would likely
>assume it was an error and fix it.
>
>
I remember actually trying this way back when and I got yelled at for
it. I remember this quite clearly because that's the exact time I
shrugged my shoulders and thought "I'll just delete the extras
completely, then." :)


subject: [Wikitech-l] Quick patch to images .cvsignore

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

During my testing, I noticed that under certain conditions a temp folder
would be created in images/. .cvsignore doesn't tell us to ignore this
folder... so..

- --- C:/Documents and Settings/Edward/My Documents/My
Webs/jpsband/mediawiki/t/images/.cvsignore
+++ images/.cvsignore
@@ -3,4 +3,5 @@
 thumb*
 timeline*
 tmp*
+temp*
 ?

I reckon no one would have problems with committing such a patch...

- --
 Edward Z. Yang      Personal: edwardzyang at thewritingpot.com
 SN:Ambush Commander Website: http://www.thewritingpot.com/
 GPGKey:0x869C48DA   http://www.thewritingpot.com/gpgpubkey.asc
 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDqe10qTO+fYacSNoRAk7dAJ9+/VzUT6bYnhx+sCGtYFwZKiyTUQCaAkL4
M85XD8vdm7QqJrK65KjYjgs=
=HZm4
-----END PGP SIGNATURE-----


subject:
[WikiEN-l] Defamatory Biographies - another problem
	looming	forWikipedia?

body:
Geoff Burling wrote:
> On Tue, 20 Dec 2005, David Gerard wrote:
>>Geoff Burling wrote:

>>>(And for the record, when I find an article with more than one stub tag
>>>attached, I always reduce the number to one. Don't like it? Then turn
>>>the stub into an article, & we'll both be happy.)

>>PLEASE DON'T DO THIS. Different stubs are subcategories of different
>>parent categories. Someone from a wikiproject about content will often
>>go into that project's stub category and start work on stuff they find
>>there.

> Are you serious? To repeat myself, how many stub notices does Wikipedia
> need on any given article? This is the silliest idea I've seen proposed
> here -- including many I have proposed -- for these & probably many
> more reasons:

> -- just how many people actually look for stubs in their area of interest?
> I've seen anecdotal evidence that few people bother to chase down stubs.
> (When I am on the hunt for a topic to work on, I'm as just as likely to
> look under the more broad categories as under the stubs.)

I don't know about others, but I look through [[Category:Scientology
stubs]] when I'm bored.

> -- this confuses meta-information (which should be on the Talk page)
> with warnings to the reader (which should be on the article page) I
> believe this falls under the category of "instruction creep". If an
> there is a reason an article needs more than one stub notice, then
> shouldn't they go on the talk page?

That's a good idea, actually. Would you be averse to moving second and
third stubs to talk pages instead of just deleting them?

> And last, & perhaps most important:
> -- just exactly when was this policy dreamed up, debated, & voted on?

People started doing it presumably because they found it useful.

> Until reducing multiple stubs becomes a bannible offence, I will
> continue to do it, based on my editorial discression. you have been warned.

Well, I can't stop you :-) But if you could please move them to talk so
they're still findable by interested editors (presumably with a note of
why), that'd be good.

>>I didn't say 90%, I said 20-30%!

> You're right. I went back & checked my log of Wiki-EN mail, & I
> misremembered the figure. (I'm amazed, though, at how many people threw
> around "90%" when talking about issues.) I sincerely apologize.

Although it's still a horrible percentage. I wonder what the numbers are
like now.

- d.


subject:
stubification to the max! (was Re: [WikiEN-l] Defamatory
	Biographies -	another problem looming	forWikipedia?)

body:
Mark Gallagher wrote:

> Stub templates, as far as I'm concerned, are the domain of WSS.  Not our
> problem.

Indeed :-) If they want to organise every short article, I'm happy to
let them!

>If I'm willing to go the extra mile and add exact stub
> templates, I will; if I'm not, I'll just put {{stub}} and let them sort
> it out.

I must confess that I do this too ;-)

>  If we don't like how stub categorising is handled, the solution
> is to either participate in WSS and argue with *them*, or to simply
> refuse to participate and stick to plain-jane {{stub}}.  It's not to
> deliberately mess around the work they're doing (as you're proposing,
> and SPUI received a block for a while back for doing).

It's not entirely clear to me why some admins seem to regard SPUI as
target practice. He's brash and forthright and bold (sometimes too
bold), and is an ex-GNAA we borged, but as per the bottom of [[WP:NPA]],
no-one is fair game and boldness isn't a block-on-sight offence.

> It depends how you define "drek".  If "drek" means unsalvagable, then
> I'd agree, no more than 20-30%.  If it means "crap", then (before anon
> users were prevented from creating new articles), I'd say easily 90% of
> new articles created by anons were crap and in need of cleanup, if not
> necessarily nuking from orbit.

Before anons creating articles was switched off, 2000 out of 4000 new
articles a day were getting speedied. What are the numbers now?

- d.


body:
Angela wrote:

> It's possible to add a stub category without adding a stub template.
> Perhaps this would be a suitable compromise between those who need the
> categories to be there and those who don't want multiple "this is a
> stub..." notices on one article? Compare
> <http://en.wikipedia.org/w/index.php?title=Ambrosius_Stub&oldid=27617688>
> with <http://en.wikipedia.org/w/index.php?title=Ambrosius_Stub&oldid=27615177>,
> for example.

Who on Earth can remember the one trillion stub types? Not me.
WikiProject Stub Sorting are the ones who know them.

For those revolted by multiple stubs (and I agree that they have all
Geoff's listed points against them), the talk page could be workable -
they wouldn't be blots on the article warranting {{toomanyboxes}} and
they'd still be findable in the relevant stub category. WSS would need
collective persuasion that this was a good idea, else they would likely
assume it was an error and fix it.

- d.


from_name: Mark Williamson

body:
Servien, the issue is the _version_ of ISO. Some people seem to be worried
about the stability of ISO 639-3.

Mark

On 21/12/05, Servien Ilaino <servien at gmail.com> wrote:
>
> I don't see the problem here all have ISO codes who cares about
> capitalisation or not, ISO codes are not capitalised for as far as I know
> and most will certainly never change and will always stay that way.
>
> Correct and official ISO codes:
> nds-nl; Nedersaksisch (personal reply from ISO code commission)
> rmy; Romani Vlax (official code; ethnologue)
> pdc; Pensylvanian German (official code; ethonologue)
> lij; Liguarian (official code; ethnologue. current proposal "roa-lij" or
> "lij")
>
> Semi-official codes:
> vls; West-Vlaams (the term Flemish is used as collective term for Dutch
> dialects in Flandres, but is mostly associated with West-Flemish, so I've
> heard. "gem-wvl" could be an option aswell)
> ksh; Ripuarian (ksh; Keulsh, Ripuarian not listed on ethnologue)
>
> Not listed on ethnologue, "dialect code" is used (gem-, bat-, map- etc):
> bat-smg; Samogitian (not listed on ethnologue)
> qbn or map-bms; Banyumassan (not listed on ethnologue)
>
> Servien
>
>
> 2005/12/21, Gerard Meijssen <gerard.meijssen at gmail.com>:
> >
> > Ray Saintonge wrote:
> > > Gerard Meijssen wrote:
> > >> Hoi,
> > >> Actually you misunderstand me. When you mix standards and the
> > >> difference between those standards disappears because of restraints
> > >> that YOU are under, it means that what you do is not up to standard.
> > >> Consequently it cannot be said that we implement the ISO-639 codes.
> > >> When we adopt the ISO-639-3 codes we have the SIL information
> > >> included. It is a custom to keep the two character ISO-639-1 codes as
> > >> well. This is in my opinion the only way out of this mess. NB We have
> > >> been using these codes already for over a year in Wiktionary.
> > >>
> > >> Yes I know. URL's are case insensitive. We can implement ISO-639-3
> > >> and we should do this. NB there are even standard formats to indicate
> > >> that a certain script is used as there are ISO codes for those too
> > >> (ISO 15924).
> > >>
> > >> So we either adopt a standard and do it right or we should not say
> > >> that we adopt a standard. If you want an official statement as to the
> > >> stability of the ISO-639-3, I think that I can get you that.
> > >
> > > One also needs to remember that ISO 639-3 still reserves a block of
> > > codes beginning with the letter "q" tha are user defined.  These can
> > > be used for languages that are not included in the standard.  The
> > > languages where that would be needed are not going to be the most
> > > popular or best known, and are unlikely to become big wikia.  If at
> > > some future time thay are given a standard code conversion should not
> > > be a huge operation.
> > >
> > > Ec
> > Hoi,
> > Many of the current Wiktionaries make use of the ISO-639-3 codes. Here
> > there is no relevance  as to the size of a prospective Wiki. We use the
> > code to indicate that a word is in a given language. I have extended the
> > data design of Ultimate Wiktionary to include room for a translation
> > framework. The idea is that is will help us manage the translation the
> > Mediawiki messages. Given that UW will be a Mediawiki application and
> > that we want the localisation for the languages that make use of it
> > (basically all of them) we need a way to manage the translations in a
> > structured way..
> >
> > Please have a look at
> >
> >
> http://meta.wikimedia.org/wiki/Ultimate_Wiktionary_data_design#Managing_translations_for_Wikidata_and_other_fixed_texts
> > and give me your questions, your comments.
> >
> > Thanks,
> >    GerardM
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>

--
"Take away their language, destroy their souls." -- Joseph Stalin


subject: [Wikitech-l] Yet another reason to have a "stable article" system

body:
Leon Planken wrote:

> The second solution above (branching) could also be implemented by
> allowing just two branches: a 'development' branch and a 'stable'
> branch.  Or just a separate namespace (if you will) for stable articles,
> editable only by users with the appropriate rights.

The 'stable branch' idea sounds workable - no changes beyond typos or
seriously problematic content (e.g. libel, copyvio). Particularly if
combined with Magnus' idea of a Mediawiki installation that only
receives the "good" articles/versions from a read-write Wikipedia.

Jimbo's original request for a ten-minute delay for anon readers would
be a better idea for presenting a less unpolished face to the world,
IMO, but I understand that's presently considered a technical nightmare
and is unlikely in the short term.

- d.


subject:
[WikiEN-l] Original research vs. Fact-checking
	(Wikipedia:Biographies of living persons)

body:
"sydney poore"  wrote

> To add unpublished details to a biography is an example of original
> research.
> (100% disagreement. A person?s date of birth is not original research. DOB
> is a basic fact of society. It is verified daily by a wide spectrum of
> organizations.)

I have felt for a long time that OR _can_ be abused, as a stick to beat
additions to articles.  The principle does seem to be well established,
though.  This particular issue suggests to me that we haven't yet got the
policy quite into focus.

We do want to stop people asserting they have important private sources,
putting 2 and 2 together to make 5, and putting that on WP.  Which is a
recipe for conspiracy theorists running amok.  It could be a real difficulty
in some areas (e.g. coverage of espionage).  To say that simple
fact-checking is out makes, however, for an unpleasant dilemma: keep
something you know is wrong on the site, or take down a wrong fact like DoB
and simply leave a gap.

Charles


body:
Magnus Manske wrote:

> Second, no branching. Never. Ever. Branching in wikis is evil. Evil (tm)!
> If there's no version worthy of "stable", none should be marked as such!

I must admit there's a lot to that view :-)

I think allowing a 'stable branch' with severely restricted checkin
isn't too horrible, if it's not the main Wikipedia. I mean something
with change restrictions about as stringent as ancient versions of
Solaris get.

- d.


from_name: John Lee

subject: [WikiEN-l] A newbie on article prefill templating

body:
MacGyverMagic/Mgm wrote:

>On 12/21/05, Steve Bennett <stevage at gmail.com> wrote:
>
>
>>>That's why to start simple, to see if we need to. Something
>>>to help the newbies and not annoy the experienced editors.
>>>
>>>
>>Speaking as a semi-experienced editor, I wouldn't mind the odd template.
>>Typing is boring. Let the machine do it.
>>
>>Incidentally, there was a proposal somewhere to change the nomenclature
>>from "references" and "external links"  to "sources" and "further
>>reading".  I've seen this implemented once or twice and it seems to work
>>a lot better, and remove all the confusion over when to use URLs, swaps
>>academic naming conventions ("references") for more understood
>>"sources", etc.  If a template is being created, it's probably a good
>>opportunity to think about making a decision on that, and implementing
>>it there.
>>
>>Steve
>>
>>
>>
>I'm not really happy about "Further reading". Not only do some
>external links show films, or images (which don't require reading), it
>also fails to take into account that further reading is much thought
>about with regard to print sources and may lead to people being
>confused on where to put external links.
>
>And that's without mentioning the 800,000 articles that'd need changing.
>
>Mgm
>
>
Ditto Mgm. I'm not worried about the 800k articles we'd have to change -
we got through categorising fine, didn't we? What I'm concerned about is
that, as he said, external links != further reading. Maybe we could
change "further reading" to "other resources"?

John Lee
([[User:Johnleemk]])


body:
John Lee wrote:
> MacGyverMagic/Mgm wrote:

>> I'm not really happy about "Further reading". Not only do some
>> external links show films, or images (which don't require reading), it
>> also fails to take into account that further reading is much thought
>> about with regard to print sources and may lead to people being
>> confused on where to put external links.
>> And that's without mentioning the 800,000 articles that'd need changing.

> Ditto Mgm. I'm not worried about the 800k articles we'd have to change -
> we got through categorising fine, didn't we?

Also, it's eminently bot-suitable. One of the first things Kate did on
en: was run a bot to change "External link", "External Links" and
"External Link" to "External links".

>What I'm concerned about is
> that, as he said, external links != further reading. Maybe we could
> change "further reading" to "other resources"?

Or maybe we could leave it alone! I don't at all see the problem with
"References" and "External links". (And some articles, e.g. [[Xenu]],
actually have "References" and "Sources" and "External links".) I think
the current convention is fine.

- d.


body:
MacGyverMagic/Mgm wrote:

> Why not keep "External links" and add "Further reading" to separate
> print and online publications.

Some articles have this too. It's all good :-)

- d.


references:
<87ek49j5y6.fsf@mat.ucm.es>
	<43A701CC.2020809@web.de>	<do8i3i$i3q$1@sea.gmane.org>
	<87lkyf3kp6.fsf@mat.ucm.es>	<43A827CE.8020706@web.de>
	<873bkmsky3.fsf@mat.ucm.es>
	<9f02ca4c0512210434x39e641c5i@mail.gmail.com>

body:
Rowan Collins wrote:
> On 21/12/05, Uwe Brauer <oub at mat.ucm.es> wrote:

>>What is the *problem* in using HTML constructs? Speed in parsing?

> I think the main problem is *consistency* - if you're trying to let as
> many people edit as possible, having multiple variants of markup for
> doing [nearly] the same thing just makes everything that much harder
> to learn, and gives people that much more chance to be baffled when
> looking at the source.

HTML was invented as a human-writable language. Unfortunately, the
humans in question were computer-literate physicists at CERN, and less
technically-minded humans have a lot of trouble with it. Do you remember
looking at web page source code in 1995/1996? "Tag soup." People used
tag soup because they wanted a result on the page, and never mind the
programming formalisms.

The advantage of wikitext for mere humans is that it starts working as
plain text, then you can add wikitext soup to it and you still get a
result that nontechnical people can read and write.

Wikitext is formally horrible, but seems to work with human editors.
Wikipedia is one of those wonderful pieces of technology that works for
technophobes *and* advanced geeks (e.g. Mac OS X, LiveJournal, Firefox)
- which I think should be a goal of all programs where possible, btw.

People learn wikitext like learning a language. They try stuff and it
gets meaning across. They learn more and it gets more of the meaning
across. They gain proficiency as they go.

- d.


subject: [WikiEN-l] Improper block redux

body:
Brock Batsell wrote:
> Kurt Maxwell Weber wrote:

>> Anyway, karmafist has now placed another indef block on me (because he
>> "didn't see it on the logs".  This is getting ridiculous.

> I have discussed the block with several administrators and there's more
> history there than I realized.  Your edits were disruptive, as I said
> before, and you had been blocked twice before for the same reason.
> Since you ignored the first section of my e-mail regarding the validity
> of your use of the word deletionist (which you have ignored in the
> past), I won't be defending you any longer in AN/I.

I unblocked Kurt and left a note on Karmafist's talk page saying why,
and another note on WP:ANI about why, and requesting that admins keep to
24 hour blocks maximum.

I also left a long note on [[User talk:Kmweber]].

The problem with Kurt is that he is of the school of "if you can't prove
me wrong to my satisfaction, then it means I am right, and can continue
to behave this way". Zephram Stark and zen-master are other examples.
They are incredibly disruptive and annoying, and basically drive normal
editors into an incandescent rage.

Thankfully, we *don't* have to prove them wrong to their own
satisfaction ... so I asked that admins monitoring his edits keep it to
instructive and loving cattleprod zaps, until he learns what works and
what doesn't.

Working productively with people you consider completely incorrect
idiots is pretty much mandatory for Wikipedia. It's *not optional*. Kurt
seems convinced we're mostly wrong and illogical, but still has to be
able to work with such people without driving them into an incandescent
rage to stay here and edit.

- d.


from_name: Ashar Voultoiz

subject: [Wikitech-l] Re: Thai Wikinews logo

body:
amgine at saewyc.net wrote:
> I've been unable to contact anyone who can help this project gain a logo.
>
> Thai Wikinews has created a logo,
> http://commons.wikimedia.org/wiki/Image:Wikinews-logo-th.png. A 135 pixel
> size may be found at
> http://upload.wikimedia.org/wikipedia/commons/thumb/a/a6/Wikinews-logo-th.png/135px-Wikinews-logo-th.png
>
> I'm sure the project would really appreciate if this change could be
> implimented.
>
> Amgine

Hello,

Please follow the guide on:

http://meta.wikimedia.org/wiki/Requests_for_logos

Basicly:

1/ upload the picture on the wiki with the name 'Wiki.png'
2/ protect it
3/ add your request on the above meta page or open a bugzilla request
on http://bugzilla.wikimedia.org/

cheers,

--
Ashar Voultoiz


from_name: Michael Snow

body:
Bryan Derksen wrote:

> Alfio Puglisi wrote:
>
>> There are some independent issues there have been mixed up, confusing
>> the discussion:
>
> Indeed, this is the usual pattern when stable versions are discussed. :)
>
>> 1) Using the review process to somehow decide that a certain revision
>> of an article is the good one. That's the stable revision.
>
> No problem here, always nice to add more tools to the toolbox. I've
> been wanting this sort of development since forever.
>
>> 2) What to present readers. The latest revision? The last stable
>> revision? Some combination of the two?
>
> This is where I'm differing from Magnus. I think the "default" view
> should be the latest version, not the stable version, because that's
> the version that we need editors to actually _work_ on.

This is more confusion of issues. The question is about readers, and you
respond by talking about editors. Granted, there is some overlap, but
increasingly we need to acknowledge that the two are distinct groups and
many in the first group will never be in the second.

The default for readers should be a stable version. The default for
editors should be the latest version, the one that can be, and needs to
be, edited. The issue is how to guess whether someone is in a particular
group.

One solution that comes to mind immediately is to use logging in as a
guide. If someone doesn't log in, they're presumed to be a reader and
given the stable version, if any, and the development version (suitably
labeled) if no stable version exists. If someone logs in, they're
presumed to be an editor and given the development version, with a
preferences option in case they wish to change this.

To forestall the inevitable complaint, this would not be a step in the
direction of eliminating "anonymous" edits. In fact, because it provides
more "reliable" content for most readers, it could and should be
accompanied by lifting the restrictions on "anonymous" editing.

> Wikipedia is a work in progress, our goal is to _produce_ an
> encyclopedia rather than merely _displaying_ one.

True enough, but then you say...

> But our goal isn't to _show_ an encyclopedia to people, it's to get
> people to help us _write_ one. Let Answers.com worry about showing our
> material to people.

"Wikipedia is first and foremost an effort to create *and distribute* a
free encyclopedia of the highest possible quality to every single person
on the planet in their own language." (emphasis mine)

Our goal is very much to show people an encyclopedia, and trying to
treat the writing process as if it's wholly separable from this is a
mistake. If Answers.com, Directmedia, or anyone else wants to help with
this, that's great, but we have a mission to distribute, and we should
not abdicate it by saying other people will take care of it. Executing
core objectives is not something you outsource.

--Michael Snow


subject: [Wikitech-l] Re: Using Wiki with MS SQL Server

body:
Durumeric, Zakir B wrote:
> We are starting to look into using Wikimedia as a type of knowledge base
> for our organization. We currently use MS Server and SQL Server 2000. We
> have setup PHP on IIS, but I was wondering if it is possible to have
> Wikimedia work off of MS SQL Server instead of MySQL. If not, it's not a
> huge problem to install MySQL server on a linux or win machine, but we
> would like to be able to link articles from other database interfaces we
> have designed in the past using MS SQL server.

Hello,

We use a database abstraction layer wich currently support mysql,
postgreSQL and maybe Oracle. There is no support fro MSSQL out of the box.

So you have two solutions:

1/ code a layer for MSSQL and eventually give it back to the community
(i believe it will have to be published at least under GPL).

2/ use mySQL (which is free but might not be supported by your
organization).

--
Ashar Voultoiz


from_name: MacGyverMagic/Mgm

body:
I agree with you Sydey, that biographies should be accurate, but
taking information straight from the subject constitutes original
research and since we can't see their identification papers it's not
verifiable.

How do you suppose we verify the correctness of a given birthdate if
there's no newspapers or books stating the date the subject says is
correct.

(And don't forget you need to verify you're actually talking to the
subject to begin with)

Mgm


from_name: Ray Saintonge

subject:
[WikiEN-l] Defamatory Biographies - another
	problem	loomingforWikipedia?

body:
Conrad Dunkerson wrote:

> Bryan Derksen wrote:
>
>> Every type of stub I've seen so far has some sort of corresponding
>> non-stub category that the article can be placed in, so whenever I
>> remove extra stub templates I make sure the article's properly
>> categorized. They don't get "lost" that way.
>
> Hmmm... instead of having a hierarchy of 'categories' and a parallel
> hierarchy of 'stub categories' it might make sense to just have one
> hierarchy and a single generic stub notice. Only drawback I can see is
> that there isn't currently a simple way to identify 'articles in this
> category with a stub notice' or 'articles in category-1 AND
> category-2'. Still, it probably wouldn't be too difficult to have
> category views with 'display only articles also in the Stub category'.
> Would cut the categorization and sorting work significantly.

A slightly more advanced search function might help that.

Ec


subject:
[Wikitech-l]
	Re: http://en.wikipedia.org/wiki/Comparison_of_wiki_software

body:
Thomas Gries wrote:
> I updated that page.
> - because MediaWiki is now at version 1.5.3, and
> - has email notification built-in (even when this is still disabled on
> the major project sites).
> T.

Which page ? :o)

--
Ashar Voultoiz


subject: [WikiEN-l] Improper block redux

body:
David Gerard wrote:

> Thankfully, we *don't* have to prove them wrong to their own
> satisfaction ... so I asked that admins monitoring his edits keep it to
> instructive and loving cattleprod zaps, until he learns what works and
> what doesn't.

As of 8pm this evening, I removed all blocks on Kmweber. Note that I
won't be unblocking again. But we'll see how things go.

- d.


body:
On 21/12/05, Taco Deposit <tacodeposit at gmail.com> wrote:
> On 12/21/05, sydney poore <poore5 at adelphia.net> wrote:
> >
> > To add unpublished details to a biography is an example of original
> > research.
> > (100% disagreement. A person's date of birth is not original research.
> > DOB is a basic fact of society. It is verified daily by a wide spectrum
> > of organizations.)
>
> Weren't we just celebrating, a few months ago, how we were able to "scoop"
> all the traditional news outlets on the news of Susan Sontag's death? That
> was unpublished information (at the time).

It may be of some interest:

http://en.wikipedia.org/wiki/Talk:Andrea_Dworkin/Archive1 is the brief
debate we had over whether or not to go with unconfirmed reports of
her death. We predated the Guardian, the first major media to pick it
up, by at least 24 hours and probably more.

(I still think we should have waited until after the Guardian published, though)

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


body:
David Gerard wrote:

>Ray Saintonge wrote:
>
>
>>Being scientifically accurate, no matter where it leads us, is superior
>>to being toadies of SPOV-pushing liars.
>>
>>
>Er, WTF? What on earth are you talking about? "SPOV-pushing liars"?
>
I've corrected my typo above.  For a better understanding of what I
said, please see the context of my comments.

Ec


subject: [Wikipedia-l] Stable versions policy

body:
>
> I think you have misunderstood the concept of stable versions entirely.
>
> Currently, new versions of an article can be added through editing an
> existing version of it. This *does not* change the existing version, it
> merely produces a new one, which is shown as default when you request a
> page for reading without specifying the version number. Noone can, and
> noone ever could, edit any *version* of an article. Just *the* article,
> by creating a new version. That point seems to have escaped your
> attention.
>
> A stable version merely changes the *default view* from the latest
> version to another that has been declared stable by someone trustworthy.
> You can still see the latest version if you want, and you can still
> create new ones based on any old version.
>

There is something that you don't seem to understand. By making the stable
version default to the majority of readers, then Wikipedia's instant
editability becomes compromised. I'll give you an example - say a stable
version has been created for an article about the Romanian economy. Monthly,
stats change, and I'd also like update some prose about the role of ICT in
the Romanian economy. So, as an editor, I go to the editable version and
change it, and - bang - as you said, it's instantly there.

BUT, and this is the big but, my edits would not be instantly displayed on
the default version. People coming into the Romanian economy article would
see the old stable version, and only *if* they choose to see the updated
version, which people won't do for lack of verifiability, would they see the
new data. Now, you're going to say to me - aah, but the stable version can
always be updated. Yes, I concede that, but the proposal states that for a
stable version to be approved, it must go through a lot of consensus
(otherwise, what's the point?).

So, I hope you see that stable versions goes against the very nature of
"instantly-editable" Wikipedia. People will no longer be encouraged to
update stats, to add new, *good* information, if they know that their
information won't be immediately accessible, but will only be featured on
what is in practical purposes a secondary draft version.

> So, the only thing that will changes is that for anons (and logged-in
> users depending on their settings) reading articles, the *initial* view
> will be the stable version. This features a text like "this is a stable
> version, the latest version is [[here]]" in the header.

Do you realise that that is still a very significant change, as explained
above?

So, despite your rather polemic claims, there is *no* (as in *0*,
> *zero*, *nada*) freedom taken away from anyone. Everyone can still edit
> every article.

Don't get me wrong here - I'm not trying to make polemic claims. I'm not
trying to insult anyone. It's just a bit annoying that Wikipedia is about to
launch something that will change its nature significantly, and there seems
to be no awareness to it. What's more, everyone is saying "well, the changes
aren't big at all. Why are you worrying?"

On the contrary, setting a stable version will again allow the editing
> of perpetually protected pages! So, more freedom to anyone.

What perpetually protected pages? Not to insult anyone, but this smells so
much like election propaganda.
http://en.wikipedia.org/wiki/Wikipedia:Protection_policy says:

A permanent or semi-permanent protection is used for:

   - Protecting high visibility pages such as the Main
Page<http://en.wikipedia.org/wiki/Main_Page>from vandalism.
   - Maintaining the integrity of the site's logo.
   - Maintaining the integrity of key copyright and license pages (for
   legal reasons).
   - Maintaining the integrity of press releases.
   - Protecting certain *"system administration"* pages.
   - Protecting the often-used texts in the MediaWiki namespace.
   - User pages and their subpages that are subject to repeated
   vandalism.

So, the policy doesn't allow for *articles* to be protected. And, never have
I seen an article protected indefinitely before.

Ronline


subject: [Wikipedia-l] Stable versions policy

body:
Magnus Manske wrote:

> In 2001, we were not really used as a source of knowledge. That /might/
> have started 2002, or later. Today, we are one of the largest
> repositories of knowledge. We can now either
> 1. teach every single one of our potential users in the ways of wikis
> and how to use them, look through the page history, and still treat
> everything they read with utmost caution, /or/
> 2. present a random user a good encyclopedia, with the option for more
> (current versions, editing, the like)
> I'd prefer #1, but, well... :-)

I must admit I've been strongly pushing 1. in press interviews ;-)

- d.


from_name: Blackcap

subject: [WikiEN-l] One line summaries of WP Guidelines and Policies

body:
On 12/21/05, Steve Bennett <stevage at gmail.com> wrote:
>
> Criticisms have included that the suggested summaries simplify or
> distort the relevant policies, that the template is ugly (I agree :)),
> that the template is redundant considering the first sentence is often
> (but surprisingly rarely!) a summary of the policy, and that users may
> feel they have grasped a whole policy when they've only read a
> "powerpoint" bullet point version of it.

To copy what I said on [[Wikipedia talk:Semi-protection
policy<http://en.wikipedia.org/wiki/Wikipedia_talk:Semi-protection_policy#One_line_summary>
#One line summary<http://en.wikipedia.org/wiki/Wikipedia_talk:Semi-protection_policy#One_line_summary>
]]:

It seems to me that the problem isn't that we need a box to sum things up
but that we need better first lines. Just take the information which you
would put in the box and instead put it in the first line. Then, you don't
have a massive ugly box, you have all of the same information, and it
removes the simplistic summary of policies (i.e. from
WP:BAN<http://en.wikipedia.org/wiki/WP:BAN>,
the useless and
PowerPoint<http://en.wikipedia.org/wiki/Microsoft_PowerPoint#Criticism_of_Powerpoint>-eque
*"Users may be banned for varying times. They may appeal, but must not
circumvent the ban, so don't bait them or help them to try."*).

I feel that many people never read the guidelines, as there are too
> many, and they're not well structured or organised together. By creating
> a single page with an accurate, concise summary of each guideline, a
> user can get a very good feel for not only how Wikipedia works, but also
> how the relevant policies and guidelines are structured, so they know
> where to go for more detail.
>

I agree: one of my main complaints about WP is that the Help stuffs aren't
readily visible and hard to find (this becomes less of a problem once you
discover Meta, but hey!). However, we already have the one-liner page: it's
at [[Help:Contents <http://en.wikipedia.org/wiki/Help:Contents>]]. This
handy little page is easily accessible if you use the vastly superior
Classic skin (it's right underneath the link to your talk page), but is
somewhat more hidden if you don't. If it became more obvious then it would
alleviate some of the problems you're talking about (IMHO).

For those alternatives and reasons, I don't think that this box is
necessary.

--
[[User:Blackcap]]


from_name: Connor Lee

subject:
[Wikitech-l] Re: [HelpDesk-l] Cannot change content of navigation
	bar because $wgUseDatabaseMessages=false

body:
I have CCed this question to the Wikitech mailing list. I hope they can be
of assistance to you.

Connor Lee
Wikimedia Help Desk

On 12/14/05, Jan Vanoverpelt <jan.vanoverpelt at gmail.com> wrote:
>
> Dear,
>
> After installation of the Mediawiki-software, I changed the default
> "English" language into Dutch by changing $wgLanguageCode in
> localsettings.php AND by setting $wgUseDatabaseMessages=false in
> defaultsettings.php (the latter had to be done in order to see the
> changes, like is indicated in the Mediawiki-FAQ).
>
> My problem is that because $wgUseDatabaseMessages=false, I cannot display
> the page "special:allmessages" anymore, neither can I change the content of
> the navigation bar. As a solution for this problem, the FAQ-answer proposes
> to run the script rebuildMessages.php in the maintenance-folder. I did
> this but without any results.
>
> Does anyone know how I can fix this problem so I am allowed to see the
> page special:allmessages and change the content of the navigation bar while
> I still have my wiki-site in the Dutch language?
>
> thanks in advance!
>
> _______________________________________________
> HelpDesk-l mailing list
> HelpDesk-l at Wikimedia.org
> To unsubscribe from this list, visit:
> http://mail.wikipedia.org/mailman/listinfo/helpdesk-l
>
>
>


from_name: Magnus Manske

subject:
[Wikitech-l] Re: Stable version now with cache (Tim,	this one's
	for you!:-)

body:
Phil Boswell wrote:
> Just one question: if a given template is updated, and it is decided that
> the changes should be propagated, is it possible to do this automagically,
> or does some poor sod have to go around "re-stabilising" a bunch of
> articles?
>

Right now: No.

My initial implementation didn't use caching, because I assumed that as
templates shouldn't influence the article content, we could just protect
all templates by default. IMHO that would be reasonable, as templates do
influence a lot of articles.

Then someone on this list said no, we need to cache the article version
*as it is at the moment of "stabelizing"*. So what I did was to
partially run the parser on a version to be "stabelized", namely the
template replacement (and the <nowiki> and HTML-tag orgy). That
partially parsed text is then cached, and silently inserted via hook on
revision loading.

Now it's "well, *some* templates should change".
You can see how I am a little confused. Either an article version is
good as it is, or it isn't. A template change shouldn't alter that fact.
If it does, the version in question might not have been worth called
stable in the first place.
Implementing the "some" option means a lot of work (implementing a
front-end for saying which templates should be updated, finding the
articles that use it, find the *templates* that use it; if template A
uses template B, and template B is changed and the changes are
considered safe, should articles using template A be updates, even
though template A is not considered safe? And so on).

As a site note, when (notice the *when* instead of the *if*, almighty
roots!) my Tasks feature is going into production, many of the "daily
management" templates will not be used anymore, which makes changes to
these obsolete.

Magnus


subject:
[WikiEN-l] Original research vs.
	Fact-checking(Wikipedia:Biographies of living persons)

body:
On 21/12/05, Sam Fentress (Asbestos) <asbestos999 at gmail.com> wrote:
> On 12/21/05, Steve Bennett <stevage at gmail.com> wrote:
>
> > It occurs to me that in academia, one occasionally sees "personal
> > correspondance" or "publication forthcoming" cited.  Is there something
> > wrong with stating "The New York times gives Jim Smith's birthday as 24
> > May 1964, although Jim has stated that it's 24 May 1965[1]" where [1] is
> > Personal email to Wikimedia Foundation, 5 Nov 2005.  It's verifiable in
> > the sense that you could always email Wikimedia and ask them if that's
> > true.
>
> If it's a personal email to the Wikipedia Foundation, or to our lawyers or
> something, then that's a different matter. The problem is that the Wikimedia
> Foundation aren't the ones putting the facts in the articles. It's if
> User:RandomName puts in a new date of birth and cites at the bottom
> "Personal Correspondence". There's no way we can check if that's true, and
> there's no one to turn to if the article's subject starts demanding
> corrections and accountability.

Okay, so how would "allow personal correspondence where evidence is
copied to the Foundation" sound?

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


from_name: Geoff Burling

subject:
[WikiEN-l] Defamatory Biographies - another problem looming
	forWikipedia?

body:
On Wed, 21 Dec 2005, David Gerard wrote:

> Angela wrote:
>
> > It's possible to add a stub category without adding a stub template.
> > Perhaps this would be a suitable compromise between those who need the
> > categories to be there and those who don't want multiple "this is a
> > stub..." notices on one article? Compare
> > <http://en.wikipedia.org/w/index.php?title=Ambrosius_Stub&oldid=27617688>
> > with <http://en.wikipedia.org/w/index.php?title=Ambrosius_Stub&oldid=27615177>,
> > for example.
>
>
> Who on Earth can remember the one trillion stub types? Not me.
> WikiProject Stub Sorting are the ones who know them.
>
> For those revolted by multiple stubs (and I agree that they have all
> Geoff's listed points against them), the talk page could be workable -
> they wouldn't be blots on the article warranting {{toomanyboxes}} and
> they'd still be findable in the relevant stub category. WSS would need
> collective persuasion that this was a good idea, else they would likely
> assume it was an error and fix it.
>
You had me until that last sentence. I'm gonna continue with my "delete
all but one stub template per article" ways until one of the folks from
the Stub Sorting group decides to have a talk with me.

And before anyone thinks I'm in the process of irreparably destroying
Wikipedia with my lawlessness (okay, as much destruction as removing stub
templates can cause), let me state that on average I modify about one
article a week for this reason. Some days, when I'm on a rip, I might
strip stubs from as many as two or three articles. So it's not as if I'm
attempting to imitate some grand scheme like Wik did, monitoring the
changes on thousands of pages & reverting each one where he did not approve
of the edit.

And I admit that I agree for the most part with that WikiProject's goals:
one fat collection of articles under {{stub}} was just not workable. It's
just that some times I have to wonder if all of the energy sorting these
stubs wouldn't be better applied to making them into full-length articles,
especially after Angela's example with [[Ambrosius Stub]] -- although
now that I've had a moment to think about it, I suspect someone was
having too much fun adding {{stub}}'s to Mr Stub's article.

However, I often encounter some real head-scratchers, such as [[Ibn Yasin]],
whose article is marked with a {{philosopher-stub}} & an {{Islam-stub}}:
just how many philosophy wonks are going to make a substantial change to
an article about a West-African Islamic mullah? (At the moment, the most
serious problem with this article is neither philosophical nor religious,
but the least obvious: the date of his death. This article says it
was 1059, another article 1056, & a book I borrowed from the local
library says it was 1057. If I had more confidence in the book, I'd be
bold & change them all to conform with it.)

What I see is the problem here is that eager new editors, who are looking
for something easy to do, start adding every stub template or category
label that fits the article they can think of. I know I've been overly
enthusiastic in the past with some of my edits, so unless the WSS people
insist that I stop my stub pruning or be hauled before the ArbCom, I'm
assuming that most of these multiple stubs are the work of newbie editors
who will outgrow this habit in a month or two.

Geoff

P.S. Had I known my email would have generated so many follow-ups, I would
have changed the subject line. But I doubt I could have improved on Mark
Gallagher's "stubification to the max!"