body:
On 7/9/06, Sarah <slimvirgin at gmail.com> wrote:
> The policy is based on common sense, not dogma. When you send a letter
> to a newspaper for publication, you're expected to supply your name,
> address, and telephone number so that someone from the newspaper can
> check that you really did send it. Nothing like that exists for
> Usenet. It's all very well to say that if X didn't write the post, and
> we quote from it, X will tell us soon enough. But what happens if X
> claims that, in purporting to quote him, and in leaving that unchecked
> quote on Wikipedia for months until he spotted it, we have damaged him
> in some way? Newspapers have processes in place to avoid this
> scenario, and they have libel insurance for when things go wrong. We
> have none of those things, which is why we piggy-back on other
> people's, by using only material that has already been checked.

With groups.google.com (or previously to that, access to Dejanews, or
previously to that being a close enough friend of Henry's to for him
to be able to dig up the tapes)  it is possible to (semi-reliably) go
back and say "A person with this email account posted the following
article at this time in history: [...]"

That is not to say that forgeries and frauds are unknown in Usenet.
However, such were relatively rare, and are not unknown in other media
which are taken generally to be acceptably accurate sources.

Wikipedia has not set the bar at unquestioned verifyable accuracy for
every source.  When someone adds in or uses a reference, there's no
independent fact checking necessarily performed to see if the source
really exists, or says what it is purported to say, or is not part of
some sort of elaborate forgery project.  And I do not doubt that
within the million-odd articles, we have sources cited which don't
exist, we have sources cited which say something else, and that we
have sources cited which exist and say those things, but are forgeries
or fraudulent.

Usenet posts, in verifyable archives, documenting Usenet activities,
are as reliable as we need them to be.  The existence and contents of
such posts is easily and reliably validated.  As a primary source for
"the contents of Usenet", they're fine.  Articles on Usenet and early
Internet phenomena citing Usenet discussions on the topics (or
contemporary mailing lists) should feel free to use those contents.
If it turns out that a particuar cite was a forged article, we deal
with that the usual way as with any other discredited source.

--
-george william herbert
george.herbert at gmail.com


list: wikien-l

source: pipermail-mbox

from_name: Andrew Gray

subject: [WikiEN-l] Interesting debate over reliable sources

body:
On 10/07/06, poore5 at adelphia.net <poore5 at adelphia.net> wrote:

> Wikipedia has no way to verify information, seek clarity, or simply
> get a response.  For this reason it is essential that we stick with
> reliable third party sources and sparingly use primary sources
> to fill in details for already verified incidents.

The problem is that here we have an interdiction against using a
medium for a primary source ("...as is demonstrated by the fact Smith
made a post to Usenet in June [1] stating he still held that black was
white...") which *also* prevents us using anything published through
that medium as a tertiary source ("...as has been shown by Smith's
extensive research into monography<ref>"Summary of recent work".
Smith. Post to sci.research.black-white</ref>").

This guideline is foolishly thought-out at best, and actively
problematic at worst.

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


from_name: Erik Moeller

body:
On 7/10/06, Sarah <slimvirgin at gmail.com> wrote:

> The policy is based on common sense, not dogma. When you send a letter
> to a newspaper for publication, you're expected to supply your name,
> address, and telephone number so that someone from the newspaper can
> check that you really did send it.

The processes used or not used vary nationally and internationally and
on a case-by-case basis, and even large papers do not necessarily
follow reliable processes.

> Nothing like that exists for Usenet. It's all very well to say that if X didn't
> write the post, and we quote from it, X will tell us soon enough.

That is not the argument I made.

Erik


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] Time 100 footage

body:
Garion1000 wrote:
> On 5/14/06, Jimmy Wales <jwales at wikia.com> wrote:
>>
>> Amanda Congdon (rocketboom.com) was gracious enough to be our press
>> representative at the recent Time 100 party in New York.  She got a lot
>> of footage of the guests, which was quite a group of famous people,
>> probably at least 100 people at the party already have wikipedia
>> articles, many with no photos or fair use photos.
>>
>> As a condition of being invited, I asked that she release her footage
>> and photos under a free license.
>
>
> What's the current status on this? It really would be great to have this.
>
> And otherwise to Jimbo, could this image
> http://www.flickr.com/photos/jimbo_wales/143261674/ be released under a free
> license? :) Since there are only fair use images on [[Ann Coulter]].
>

I second this.

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 564 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060710/4764771f/attachment.pgp


from_name: Phil Boswell

subject: [WikiEN-l] Israel News Agency

body:
Andrew Lih wrote:
>
> On 7/10/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
>> It's back again, after being deleted by Danny and protected by me
>> (ZOMG! Wheel war!).  Having seen Ombudsman among the list of
>> contributors (actually restarted it after the last deletion) does not
>> fill me with confidence...
> I'm startled that Google News finds "Israel News Service" worthy of
> inclusion among its sources.
>
Not that I'd want to be rude to Jimbo, but Google News Alerts sends me
notification when BOMIS pages get updated...not often, but enough for me to
have noticed and chuckled...

HTH HAND
--
Phil
--
View this message in context: http://www.nabble.com/Israel-News-Agency-tf1914988.html#a5248545
Sent from the English Wikipedia forum at Nabble.com.


subject: [WikiEN-l] GFDL Templates

body:
Ilmari Karonen wrote:
>
> Bogdan Giusca wrote:
>>>>Should we have many copyright templates, one to fit everyone's
>>>>taste or just one standard, vanilla-flavored template?
>> g> It doesn't really matter. As long as it carries out the same function.
>> Oh, cool. Then, I'm preparing a flower-power GFDL template, one
>> art-nouveau,
>> hm... maybe even some stuckist templates!
>> Then, we'd need some guidelines for do-it-yourself custom GFDL templates,
>> just like for userboxes. Of course, we'd need a directory for them, too.
>> I wonder whether anti-Iraq War-themed GFDL templates would be allowed...
> <WP:BEANS> {{GFDL-goatse}}? </WP:BEANS>
>
<WP:HOLE> {{GFDL-gnu-se}} </WP:HOLE>

HTH HAND
--
Phil
...who must now go and wash his brain out ;-)
--
View this message in context: http://www.nabble.com/GFDL-Templates-tf1914463.html#a5248594
Sent from the English Wikipedia forum at Nabble.com.


from_name: Karl A. Krueger

body:
On Sun, Jul 09, 2006 at 07:19:04PM -0400, poore5 at adelphia.net wrote:
> Almost without exception Media sources outside the Internet have well
> established codes of ethics and other standards that the individuals
> and institutions must follow.

I propose that these "codes of ethics and other standards" are largely
marketing foofaraw.  The sellers of news have an obvious interest in
the public *perceiving* them as ethical, neutral, unbiased, and so on.
That is quite different from those sellers of news actually *being*
these things.

We can draw our own conclusions about the reliability or ethics of
various media sources, or indeed of specific writers working for said
sellers of news.  We should not take it for granted.

Consider:  There is almost certainly some field in which you consider
yourself well-trained, if not an expert.  I have no idea what that field
is.  However, I ask you to think about the way your field is reported
and discussed in the mainstream news publications.  It is my experience
that the more a person knows about a field, the less satisfied they are
with the competence of mainstream reporting about that field.

(And if you think that competence and ethics are separable, well, I hope
you will think again.  It is, I suggest, unethical to report on a
subject on which one is not competent to do so -- to pretend to deliver
well-judged facts on a topic where one is not capable of judging the
facts due to lack of care, study, or background knowledge.)

> For example: when a media outlet publishes or broadcasts some new
> piece of information about a person or an agency, it is expected per
> ethical and industry standards that some one will make contact and get
> a response before publication/broadcast.

It would be comforting to think so.  However, consider the number of
articles you read which claim that a concerned party "could not be
reached before press time."  That frequently means that the reporter
*may* have tried to phone the party once ... or may not have done so at
all.

It is simply an error to believe so highly that The God Of Professional
Ethics will protect you from malfeasance or nonfeasance on the part of
so-called professional journalists.  A Wikipedia featured article is
held to far higher standards of quality of sources and reliability than
is a front-page article in any major newspaper.


from_name: Philip Welch

subject: [WikiEN-l] Viral swarming teenage vanity spam

body:
On Jul 9, 2006, at 1:24 PM, Michael Snow wrote:

>> Jury nullification also reduced the effectiveness of the American
>> prohibition of alcohol. Similarly, juries in African-American
>> communities have apparently been known to acquit black defendants of
>> certain crimes (particularly drug crimes) in response to perceived
>> racism on the part of the police.
>
> When I pointed out the real meaning of jury nullification I certainly
> had no intention of starting a racially charged digression. While the
> possibility of disparate enforcement of the law along racial lines is
> certainly a serious issue, I've never heard that African-American
> juries
> regularly acquit criminals on the basis of race.

I had no such intention either, I was simply repeating something I
had read previously. I certainly did not mean to imply that "African-
American juries regularly acquit criminals on the basis of race",
because it is not the race of the defendant per se, but rather the
defendant's perceived status as a victim of racism, that is the basis
of such acquittals. Or at least so I have been led to believe.

> Otherwise, to find actual examples of racial jury nullification I
> think
> you have to look at the *white* juries...this explains why
> some of jury nullification's most ardent advocates are found in the
> political fringe where white racists, survivalist militia groups, and
> radical "constitutionalists" meet.
>
> That's all I'll have to say about this, since the discussion no longer
> directly relates to Wikipedia.

There's nothing better than to call jury nullification advocates
racist and then wash your hands of the entire affair. (I was trying
to be neutral in my presentation of what I had heard, but what the
hell--if I'm on a jury, I'm not putting someone in prison for getting
caught with some weed on them, no matter what the law says.
Apparently this means I'm a racist.) Ironically, you're responding to
a message in which I cited jury nullification as an antidote to
police racism. I have to commend you on a masterful job of trolling,
Michael Snow. You skillfully combined the race card, pretending to be
the good guy, and a passive-aggressive tone to subtly take this
discussion beyond the edge of reason, all with the utmost civility.
I'm actually rather impressed.

--
Philip L. Welch
http://en.wikipedia.org/wiki/User:Philwelch


list: wikipedia-l

from_name: rose.parks at att.net

subject: [Wikipedia-l] Campaigns Wikia

body:
Hi All,

     After over a year, I found something I would like to post a message about. To my great surprise, I have seen no other post on this subject. On July 4, 2006, Jimmy Wales opened a new wiki devoted to political topics. You can find it at:

http://campaigns.wikia.com/wiki/Campaigns_Wikia

If you have not visited the site yet, be prepared for Google Ads, POV entries, and - oh yes - an occassional Wikipedian.

Apologies if this is old news...

                      As Ever,

                         Ruth Ifcher

--


from_name: Matt Brown

subject: [WikiEN-l] Israel News Agency

body:
On 7/9/06, Andrew Lih <andrew.lih at gmail.com> wrote:
> I'm startled that Google News finds "Israel News Service" worthy of
> inclusion among its sources.

I'm not so sure Google News has much of a bar to inclusion.

-Matt


from_name: Daniel P. B. Smith

body:
> From: "Matt Brown" <morven at gmail.com>

> On 7/9/06, Sarah <slimvirgin at gmail.com> wrote:
>> The policy is based on common sense, not dogma. When you send a
>> letter
>> to a newspaper for publication, you're expected to supply your name,
>> address, and telephone number so that someone from the newspaper can
>> check that you really did send it.
>
> I've had letters published in many different newspapers and other
> publications.  While all or almost all require such information, I
> have never, ever had any of them check back.
>
> I'd imagine if I was claiming to be a well-known individual, they
> MIGHT check it, but even then, I have my doubts whether they would do
> so every single time.

I've had perhaps six letters published in the Boston Globe over the
last fifteen years. They require the city you live in and a telephone
number for verification. I've been telephoned for verification twice.
I'm not sure exactly what they were verifying--all they did was ask
if I was who I said to be, and ask if they had permission to publish
the letter.

I haven't been called the last three or four times. I don't know
whether they have anything on file or whether they just didn't bother.

Just a data point.

I personally think there's a BIG difference between occasional,
casual checking and the _ability_ to verify, and no checking at all.

On the other hand, in the case of, say, a Usenet post that appears to
be from, say, a university professor named Dr. John Doe at XYZ
University whose email address is john.doe at xyz.edu, whose email
address is available from an online directory at www.xyz.edu... if
you email that address and say "Are you Dr. John Doe and did you post
this?" and he replies "Yes," that's perfectly reasonable
verifiability, at least as good as a published letter to the editor.

A news story with a credited reporter's name, with a by-line in which
the newspaper's name appears (i.e. not a stringer), in which the
reporter says "so-and-so said thus-and-such" is a much higher level
of verifiability, though.


from_name: Anthony

body:
On 7/9/06, maru dubshinki <marudubshinki at gmail.com> wrote:
> On 7/9/06, Anthony <wikilegal at inbox.org> wrote:
> > On 7/9/06, Erik Moeller <eloquence at gmail.com> wrote:
> > > And if you want to say "blog X said Y", then of course "blog X" is an
> > > excellent source for that. The question in both cases is more one of
> > > notability and relevance than one of reliability. What needs to stop
> > > is the blind worshipping of printed paper.
> > >
> > One problem with citing "blog X" when saying that "blog X said Y" is
> > that the blog might very well not exist in a few years. A copy of a
> > New York Times story, on the other hand, will certainly exist for many
> > years.
> >
> And it is *exactly*  transience problems like this that show that we
> need to be working more closely with the Internet Archive people (more
> closely that is than simply letting ourselves be spidered by 'em and
> letting'em d/l database dumps); I've suggested several times that when
> a valid ext. link is submitted, it be discreetly tagged with an IA
> link (assuming it exists), somewhat like how we're *supposed* to be
> validating ISBN links
> (http://bugzilla.wikimedia.org/show_bug.cgi?id=2391; I really wonder
> about this bug- it should be pretty simple and useful, but you know
> the devs... got other fish to fry). Or at least a robot to go around
> adding links (http://sourceforge.net/tracker/index.php?func=detail&aid=1500288&group_id=93107&atid=603141)
> if the original is gone.
>

I agree that this would be useful, to the extent it's possible ("there
is a 6-12 month lag between the date a site is crawled and the date it
appears in the Wayback Machine").  Also, since IA can and will remove
pages from the archive under certain circumstances (one of which is
when a robots.txt file appears later), you still have to worry about
an archive disappearing later.

And of course this doesn't at all address the issue of original
research - rather than proving something by referencing original
sources Wikipedia generally (if not exclusively) should be referencing
facts which have already been analysed by experts in that field.

Referencing in Wikipedia is currently a big mess.  The incremental
tweaks seem to be making things worse in many ways.

Anthony


list: foundation-l

from_name: Aphaia

subject:
[Foundation-l] Wikimania notes : early registration ends,
	writing & media contest

body:
On 7/10/06, Tomek Polimerek Ganicz <polimerek at gmail.com> wrote:
> SJ wrote:
> > Dear all,
> >
> > Early registration for Wikimania ends today; after which the community
> > rate for the conference tickets will go up.  The preliminary program
> > and proceedings are available from the conference site :
> >   http://wm06reg.wikimedia.org/

the page on the above says:

> We've extended the registration deadline, so there's still time to take advantage of the pre-registration rate: $90 (USD) per day ($240 for all three days); Wikimedia contributors who provide a project username pay $30 per day ($70 for the entire conference).

> Beginning July 16th, admission costs $100 per day (still $240 for the full pass), or $40/$90 for Wikimedians. Register soon!

...

So people seem to have enough time register themselves after getting
an answer, if it comes in two days?

--
Aphaia
aka
Kizu Naoko
email: Aphaia @ gmail (dot) com


list: wikimedia-l


from_name: Andre Engels

subject: [Wikipedia-l] Protest!!!!

body:
2006/7/9, Alphax (Wikipedia email) <alphasigmax at gmail.com>:

> > I apologize for my message; I should have kept this internal tot the
> > Dutch Wikipedia, since, as you write, it does not seem to be part of
> > general policy to remove local translations. Rather, this was
> > something of a single-person action. I am now therefore starting a
> > procedure to de-admin this specific person on nl:.
> >
>
> That's a bit harsh. Wouldn't it be easier to inform and educate them
> about their mistake and co-ordinate future translation efforts?

How do you educate someone who does not want to be educated? He is of
the opinion that he has done nothing wrong, GerardM agrees with him. A
number of other Dutch Wikipedians who have spoken out about this issue
have not.

You are right when you say I may have been too rash in starting the
procedure; however I feel fully in my right to continue it. All it
would have taken for me to stop the procedure was for him to say
"Sorry, it would have been better to first discuss it. I will try to
do better from now on." His only reaction to that is, "I have done
nothing to be ashamed of."

--
Andre Engels, andreengels at gmail.com
ICQ: 6260644  --  Skype: a_engels


from_name: Gerard Meijssen

subject: [Wikipedia-l] Protest!!!!

body:
Andre Engels wrote:
> 2006/7/9, Alphax (Wikipedia email) <alphasigmax at gmail.com>:
>
>
>>> I apologize for my message; I should have kept this internal tot the
>>> Dutch Wikipedia, since, as you write, it does not seem to be part of
>>> general policy to remove local translations. Rather, this was
>>> something of a single-person action. I am now therefore starting a
>>> procedure to de-admin this specific person on nl:.
>>>
>>>
>> That's a bit harsh. Wouldn't it be easier to inform and educate them
>> about their mistake and co-ordinate future translation efforts?
>>
>
> How do you educate someone who does not want to be educated? He is of
> the opinion that he has done nothing wrong, GerardM agrees with him. A
> number of other Dutch Wikipedians who have spoken out about this issue
> have not.
>
> You are right when you say I may have been too rash in starting the
> procedure; however I feel fully in my right to continue it. All it
> would have taken for me to stop the procedure was for him to say
> "Sorry, it would have been better to first discuss it. I will try to
> do better from now on." His only reaction to that is, "I have done
> nothing to be ashamed of."
Hoi,
It would have been nice if there was ONE reason given why this is not a
good idea. The only arguments that have been given are hostile; who are
you to do such a thing. It has been argued that the action deleted
messages that are similar in content, because with them being removed,
this will allow for an update when the message is changed. It has been
argued that all project specific messages are kept....

Andre asked why this process was started, he forgets to mention that he
is not even an admin so he is not even part of those who maintain the
localisation on the nl.wikipedia. The Dutch wikipedia has become
increasingly intolerant; the number of de-sysop procedures have
increased dramatically. I think it is appalling that people first start
to threaten with de-sysop and expect some grovelling in order to take
away this threat. Nothing was done to be ashamed of. There are good
arguments why it has been done, the deletions WERE reverted and it is
still not enough to satisfy this lust for blood.

I do not recognise myself in the Dutch Wikipedia I am sad to say.

Thanks,
    GerardM


from_name: Paweł Dembowski

subject: [Wikipedia-l] Campaigns Wikia

body:
> If you have not visited the site yet, be prepared for Google Ads,
> POV entries, and - oh yes - an occassional Wikipedian.
> Apologies if this is old news...
>                       As Ever,
>                          Ruth Ifcher

So? It's not a Wikimedia project, but a private wiki. Not every wiki
has to be NPOV and without ads (and wikia is a commercial wiki
provider, so they're bound to have ads).

--
Ausir
Wikipedia, wolna encyklopedia
http://pl.wikipedia.org


body:
On 10/07/06, Anthony <wikilegal at inbox.org> wrote:
> On 7/9/06, maru dubshinki <marudubshinki at gmail.com> wrote:
> > On 7/9/06, Anthony <wikilegal at inbox.org> wrote:
> > > On 7/9/06, Erik Moeller <eloquence at gmail.com> wrote:
> > > > And if you want to say "blog X said Y", then of course "blog X" is an
> > > > excellent source for that. The question in both cases is more one of
> > > > notability and relevance than one of reliability. What needs to stop
> > > > is the blind worshipping of printed paper.
> > > >
> > > One problem with citing "blog X" when saying that "blog X said Y" is
> > > that the blog might very well not exist in a few years. A copy of a
> > > New York Times story, on the other hand, will certainly exist for many
> > > years.
> > >
> > And it is *exactly*  transience problems like this that show that we
> > need to be working more closely with the Internet Archive people (more
> > closely that is than simply letting ourselves be spidered by 'em and
> > letting'em d/l database dumps); I've suggested several times that when
> > a valid ext. link is submitted, it be discreetly tagged with an IA
> > link (assuming it exists), somewhat like how we're *supposed* to be
> > validating ISBN links
> > (http://bugzilla.wikimedia.org/show_bug.cgi?id=2391; I really wonder
> > about this bug- it should be pretty simple and useful, but you know
> > the devs... got other fish to fry). Or at least a robot to go around
> > adding links (http://sourceforge.net/tracker/index.php?func=detail&aid=1500288&group_id=93107&atid=603141)
> > if the original is gone.
> >
>
> I agree that this would be useful, to the extent it's possible ("there
> is a 6-12 month lag between the date a site is crawled and the date it
> appears in the Wayback Machine").  Also, since IA can and will remove
> pages from the archive under certain circumstances (one of which is
> when a robots.txt file appears later), you still have to worry about
> an archive disappearing later.
>
> And of course this doesn't at all address the issue of original
> research - rather than proving something by referencing original
> sources Wikipedia generally (if not exclusively) should be referencing
> facts which have already been analysed by experts in that field.
>
> Referencing in Wikipedia is currently a big mess.  The incremental
> tweaks seem to be making things worse in many ways.
>
> Anthony
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

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


body:
[Apologies for the last, quotes-only, email - hit the wrong button]

On 10/07/06, Anthony <wikilegal at inbox.org> wrote:

> I agree that this would be useful, to the extent it's possible ("there
> is a 6-12 month lag between the date a site is crawled and the date it
> appears in the Wayback Machine").  Also, since IA can and will remove
> pages from the archive under certain circumstances (one of which is
> when a robots.txt file appears later), you still have to worry about
> an archive disappearing later.

Mmm. IA have made it reasonably clear that they're not there to
compete with paid-for "real archives", if that makes sense - they're
not going to be competing with the NYT for access to NYT backstories,
which are our major need for links to transient pages. It *is* better
than nothing - especially if we extend it to the national
legal-deposit archives that will be slowly appearing - but I'm not
sure if it'd be enough benefit to be worth the work.

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


from_name: Stephen Bain

body:
On 7/10/06, Fastfission <fastfission at gmail.com> wrote:

> 2. being printed by a respected newspaper means that at the very least
> the newspaper has put their own capital and respect on the line for a
> story. This of course does not guarantee truth *in the slightest* but
> does get closer to accountability of information than you have
> elsewhere on the internet (where there is generally no real
> accountability).

This is the crucial point. Someone can trust an article in the New
York Times about as much as they trust the New York Times itself. And
most people reading the Times would know how much they trust it based
on past experience. That way they can go some way to evaluating the
reliability of what they are reading even though they don't have the
resources to check it for factual inaccuracy, bias etc. You can't do
that with somerandomblog.com. You might be able to do it with
blogthatswidelytrusted.com but they're few and far between.

--
Stephen Bain
stephen.bain at gmail.com


subject: [Wikipedia-l] Protest!!!!

body:
2006/7/10, Gerard Meijssen <gerard.meijssen at gmail.com>:

> It would have been nice if there was ONE reason given why this is not a
> good idea.

It is never a good idea to make large changes without discussing or at
least announcing them in advance.

> The only arguments that have been given are hostile; who are
> you to do such a thing.

The action itself was hostile. On Wikipedia we work with consensus,
not one person doing something and the rest being given a fait
accompli.

> It has been argued that the action deleted
> messages that are similar in content, because with them being removed,
> this will allow for an update when the message is changed. It has been
> argued that all project specific messages are kept....

It has been argued that others want to be part of the decision of what
are project specific messages. It has been argued that others want to
know what is going to happen. It has been argued that others want to
be part of the decision on which message of two similar ones is the
better one.

> Andre asked why this process was started, he forgets to mention that he
> is not even an admin so he is not even part of those who maintain the
> localisation on the nl.wikipedia.

So? I am not the only one who feels that something wrong has happened.
As you will find out when the desysop procedure is actually started.

> The Dutch wikipedia has become
> increasingly intolerant; the number of de-sysop procedures have
> increased dramatically. I think it is appalling that people first start
> to threaten with de-sysop and expect some grovelling in order to take
> away this threat. Nothing was done to be ashamed of.

That's your opinion. Mine is that there was. It would have been better
to discuss this in advance.

> There are good
> arguments why it has been done, the deletions WERE reverted and it is
> still not enough to satisfy this lust for blood.

No. Being a sysop is a position of trust. Someone who makes wholesale
changes without discussing in advance shakes this trust. Someone who
does that and afterward does not realize that it's a bad idea, breaks
it.

> I do not recognise myself in the Dutch Wikipedia I am sad to say.

Neither do I. But I would recognise myself even less if this kind of
actions were to be considered correct.

--
Andre Engels, andreengels at gmail.com
ICQ: 6260644  --  Skype: a_engels


subject: [Wikipedia-l] Campaigns Wikia

body:
2006/7/10, Pawe? Dembowski <fallout at lexx.eu.org>:
> > If you have not visited the site yet, be prepared for Google Ads,
> > POV entries, and - oh yes - an occassional Wikipedian.
> > Apologies if this is old news...
> >                       As Ever,
> >                          Ruth Ifcher
>
> So? It's not a Wikimedia project, but a private wiki. Not every wiki
> has to be NPOV and without ads (and wikia is a commercial wiki
> provider, so they're bound to have ads).

So? So nothing. Ruth is just warning people who expect to get to some
kind of Wikipedia as to what to actually expect.

--
Andre Engels, andreengels at gmail.com
ICQ: 6260644  --  Skype: a_engels


from_name: stevertigo

subject: [WikiEN-l] Just a wiki

body:
Ive flagged [[wikipolitics]] as original research.

There is no doubt some higher level article that deals with using the Internet for
political purposes, campaigning and stuff - one that doesnt read like a pandering to
Wikipedia itself, or is otherwise glorifying one flavor of technology as some kind of
political panacea.

Donde esta el beef?

S

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Brion Vibber

subject: [Foundation-l] MediaWiki 1.7.1 and Wikipedia

body:
Jeff V. Merkey wrote:
> This needs to be reviewed. Running 1.8 on your site is not an issue, but
> creating XML dumps
> which are incompatible with released versions is. This is what needs to
> be addressed.

The XML dump format has not changed since 1.5, and should remain backwards
compatible for the forseeable future.

For wiki-agnostic republishing purposes, we're considering making more easily
used HTML dumps available.

If you want the wikitext source, though, you do need to keep in mind that
extensions, bug fixes, etc will continue to evolve along with Wikimedia's needs,
so the exact rendering of given input text may necessarily change a bit over time.

If you have a specific concern, please let us know.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060710/cf2c9008/attachment.pgp


body:
Jeff V. Merkey wrote:
> This needs to be reviewed. Running 1.8 on your site is not an issue, but
> creating XML dumps
> which are incompatible with released versions is. This is what needs to
> be addressed.

The XML dump format has not changed since 1.5, and should remain backwards
compatible for the forseeable future.

For wiki-agnostic republishing purposes, we're considering making more easily
used HTML dumps available.

If you want the wikitext source, though, you do need to keep in mind that
extensions, bug fixes, etc will continue to evolve along with Wikimedia's needs,
so the exact rendering of given input text may necessarily change a bit over time.

If you have a specific concern, please let us know.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060710/cf2c9008/attachment-0001.pgp


body:
Jeff V. Merkey wrote:
> This needs to be reviewed. Running 1.8 on your site is not an issue, but
> creating XML dumps
> which are incompatible with released versions is. This is what needs to
> be addressed.

The XML dump format has not changed since 1.5, and should remain backwards
compatible for the forseeable future.

For wiki-agnostic republishing purposes, we're considering making more easily
used HTML dumps available.

If you want the wikitext source, though, you do need to keep in mind that
extensions, bug fixes, etc will continue to evolve along with Wikimedia's needs,
so the exact rendering of given input text may necessarily change a bit over time.

If you have a specific concern, please let us know.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060710/cf2c9008/attachment.pgp>


body:
Jeff V. Merkey wrote:
> This needs to be reviewed. Running 1.8 on your site is not an issue, but
> creating XML dumps
> which are incompatible with released versions is. This is what needs to
> be addressed.

The XML dump format has not changed since 1.5, and should remain backwards
compatible for the forseeable future.

For wiki-agnostic republishing purposes, we're considering making more easily
used HTML dumps available.

If you want the wikitext source, though, you do need to keep in mind that
extensions, bug fixes, etc will continue to evolve along with Wikimedia's needs,
so the exact rendering of given input text may necessarily change a bit over time.

If you have a specific concern, please let us know.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060710/cf2c9008/attachment-0001.pgp>


list: wikitech-l

from_name: HappyDog

subject: [Wikitech-l] Request For Comment: Wiki Database

body:
(Apologies if this message appears more than once - I have had problems
posting to the list...)

I have been working on the design of a wiki-style database extension to
MediaWiki.  If you can't be bothered to read the description and want to
jump right into a demo, then skip to the bottom of this mail.

WikiDB is a MediaWiki extension that adds a new type of namespace and a
couple of extra tags to the MediaWiki software.  After installing the
extension you are able to set up a table namespace in which you can define
table structures.  No table needs to be defined in order to add data to it,
and data may be located anywhere on the wiki.  This means that you can keep
record-type data inside the article it applies to, rather than being forced
to add it to a central store.  In the true 'wiki way', if you have
information to add, you can add it straight away, without requiring that a
formal structure be set up in advance.  Other people can come and refactor
your work later, once a structure is in place.

Defining a table structure adds additional functionality that allows you to
validate and format data and this structure (as with any wiki page) can be
modified at any time.  For example if you have an 'Albums' table, you can
specify, for example, that the 'year of release' field should be a date.
This will then cause all records that don't fit this definition to be
flagged up.  Change the definition to 'integer between 1850 and 2006' and it
will highlight the rows that are invalid under the new definition.  The
important thing to note is that no data is affected - when displaying any
data it is interpreted according to current the field type, so changing the
field type changes how it is _displayed_, but not how it is _stored_.

Finally, you are able to query the database for information from any table
and format it for display within any wiki page (again, no table definition
required).  Ultimately this will allow complicated queries that include join
expressions and the like, although it is currently quite (very!) basic.

This extension is at a very early (but working) stage of development, and
this is a request for comment from the MediaWiki community.  I am looking
for input at all levels - from code-optimisation to syntax to usage issues.

I have set up a demo on my testwiki (www.kennel17.co.uk/testwiki) which
gives a bit of an introduction to the extension and some details about
implementation.  I will be adding to this as I go on.  The main URL for
the extension is www.kennel17.co.uk/testwiki/WikiDB.

Please bear the following points in mind:

* The extension is in a very early stage of development. Core functionality
is in place, but many planned features are currently lacking (including some
of those mentioned above).

* The syntax is currently fairly long-winded for certain tasks. This will be
streamlined (suggestions welcome) but it is sufficient for proof-of-concept.

* There has been very little optimisation, and there is a lot of potential
for it. I welcome advice on this matter, but do not be put off by
speed/efficiency of the current version.

Thank you for reading - I look forward to your feedback.

--
 Mark Clements (HappyDog)
(To contact me directly, remove the capitals from my address)


from_name: Jeff V. Merkey

body:
I realize that mediawiki-l is a good list for reporting bugs in
mediawiki, however, this posting addresses organizational elements of
the 1.7 release
that I feel need to be taken seriously by the Wikimedia Foundation and
some changes made in your processes.   The statements that follow are
the result of my 20+ years experience as a 1) CEO of high tech companies
2) Chief Scientist of high tech companies 3) Wikipedia developer
 4) Wikigadugi Language Project leader.  Wikimedia can take or leave the
comments -- they are for your benefit and consideration.

<WP:SOAP>

1.  Great that MediaWiki 1.7.1 is released.
2.  Has Dependencies on PHP 5.0.0 (5.1.4).  php 5 is a bug infested
experimental release which does not have consistent installs on the
commerical
Linux distributions, including Red Hat ES 4, Suse 10, etc, crashes on
apache, is poorly documented, and has a slew of defects, is difficult to
install and configure.
3.  Wikitext and MediaWiki has no dependencies for "wikitext" markup on
php versions, so requiring php upgrades is unnecessary and thoughtless,
and should be stopped.  When you allow the developers of a technology to
operate in a vacuum without accountability to customers and end users,
the projects get driven by the community ego and not end goals to
promote the technology to the public.
4.  The biggest failure of community driven programs and open source is
a lack of accountablity to end users and customers.

What should happen in the future:

1.  MediaWiki needs to post releases against commercial Linux distros
and not a "roll your own" with a patchwork of patches and fixes.  As it
stands,
MediaWiki 1.7.1 is not installable or usable on RedHat ES4 or FC5
without major patching and recompiling -- steps outside the skills of
most folks
who need to use Wikipedia content.
2.  Wikimedia needs to enforce MediaWiki releases to allow seamless
importing and use of XML dumps and content.

My 2 cents.

I spend currently about 40% of my time getting around MediaWiki problems
with Wikipedia XML dumps, and 60% of my time actually working on Native
language translations.  The Uto-Aztecan language is being added at
present as the Ute and Unita tribes have joined the WikiGadugi project.
It would be nice if the MediaWiki folks would give more thought to
ensuring their software works properly before posting releases, and the
Wikimedia Foundation needs to enforce compatibilty between its published
XML dumps and make certain they work properly with released MediaWiki
versions.  As it stands, the current setup almost appears
anti-competitive by design to prevent folks from creating Wiki's of
Wikipedia content (though I do not believe this is intentional on the
part of Wikimedia).

The "we are community driven" excuse only works if the community is also
the customer and end consumer of Wikipedia content, which it is not.
Anything we can do to make all of our jobs easier and more pleasant is
appreciated.

</WP:SOAP>

Jeff


body:
Delirium wrote:
> While I know there are plenty of logistical issues involved, I think
> from the point of view of the Foundation's charitable mission this is
> somewhat of a problem, because the point of producing Wikipedia is not
> just to put up an encyclopedia at *.wikipedia.org, but to produce
> encyclopedia articles that are Free and reusable by anyone.  If the
> articles we distribute are only fully renderable by unreleased software
> or software that's particularly complex to set up and configure, that
> discourages third-party reuse.

And if that were true, I might agree.

But PHP 5 is neither unreleased nor particularly complex to set up. It's been in
production for years, is widely available on thousands of free and for-pay
hosting services, and can be installed on any home computer or server in a
manner of minutes using any number of package installers.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060710/ff5e1759/attachment.pgp


body:
Delirium wrote:
> While I know there are plenty of logistical issues involved, I think
> from the point of view of the Foundation's charitable mission this is
> somewhat of a problem, because the point of producing Wikipedia is not
> just to put up an encyclopedia at *.wikipedia.org, but to produce
> encyclopedia articles that are Free and reusable by anyone.  If the
> articles we distribute are only fully renderable by unreleased software
> or software that's particularly complex to set up and configure, that
> discourages third-party reuse.

And if that were true, I might agree.

But PHP 5 is neither unreleased nor particularly complex to set up. It's been in
production for years, is widely available on thousands of free and for-pay
hosting services, and can be installed on any home computer or server in a
manner of minutes using any number of package installers.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060710/ff5e1759/attachment-0001.pgp


body:
Delirium wrote:
> While I know there are plenty of logistical issues involved, I think
> from the point of view of the Foundation's charitable mission this is
> somewhat of a problem, because the point of producing Wikipedia is not
> just to put up an encyclopedia at *.wikipedia.org, but to produce
> encyclopedia articles that are Free and reusable by anyone.  If the
> articles we distribute are only fully renderable by unreleased software
> or software that's particularly complex to set up and configure, that
> discourages third-party reuse.

And if that were true, I might agree.

But PHP 5 is neither unreleased nor particularly complex to set up. It's been in
production for years, is widely available on thousands of free and for-pay
hosting services, and can be installed on any home computer or server in a
manner of minutes using any number of package installers.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060710/ff5e1759/attachment.pgp>


body:
Delirium wrote:
> While I know there are plenty of logistical issues involved, I think
> from the point of view of the Foundation's charitable mission this is
> somewhat of a problem, because the point of producing Wikipedia is not
> just to put up an encyclopedia at *.wikipedia.org, but to produce
> encyclopedia articles that are Free and reusable by anyone.  If the
> articles we distribute are only fully renderable by unreleased software
> or software that's particularly complex to set up and configure, that
> discourages third-party reuse.

And if that were true, I might agree.

But PHP 5 is neither unreleased nor particularly complex to set up. It's been in
production for years, is widely available on thousands of free and for-pay
hosting services, and can be installed on any home computer or server in a
manner of minutes using any number of package installers.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060710/ff5e1759/attachment-0001.pgp>


subject: [WikiEN-l] Just a wiki

body:
Id rather let someone else do it. Somebody might de-admin me again.

Steven

--- Guettarda <guettarda at gmail.com> wrote:

> On 7/10/06, stevertigo <vertigosteve at yahoo.com> wrote:
> >
> > Ive flagged [[wikipolitics]] as original research.
> >
> > There is no doubt some higher level article that deals with using the
> > Internet for
> > political purposes, campaigning and stuff - one that doesnt read like a
> > pandering to
> > Wikipedia itself, or is otherwise glorifying one flavor of technology as
> > some kind of
> > political panacea.
> >
> > Donde esta el beef?
> >
> > S
>
>
> Move it to either the User: space or the Wikipedia: space, and tag it as an
> essay.  Or move it to meta:  It may be an article one day, but it isn't
> now...
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


subject: [WikiEN-l] Just a wiki

body:
Id have to suck a lot of community rooster.
 I just dont have the energy.

Sure wish I could move pages though...

S

--- Guettarda <guettarda at gmail.com> wrote:
> Hmm...how does that work - you'd have to pass TWO RFAs before you actually
> get your sysop flag back?  Or would you have to get 150-160% of the vote for
> your RFA to pass?

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Gregory Maxwell

subject: [Wikitech-l] User block changes

body:
On 7/10/06, Rob Church <robchur at gmail.com> wrote:
> On 10/07/06, Platonides <Platonides at gmail.com> wrote:
> > *Autoconfirmation (accounts with this block would behave like non-confirmed
> > accounts)
>
> That sounds ridiculous and useless, and defeats the idea of being
> autoconfirmed. That isn't an appropriate means to go about it.

After being bit by autoconfirm on itwiki (I couldn't upload over SVG
that had syntactical errors) I wished that there was some sysop button
to speedy autoconfirm me...

I agree that a deautoconfirm would be silly... We've already got
de-autoconfirm.. it's called block.


from_name: Andrew Lih

subject: [WikiEN-l] Israel News Agency

body:
On 7/10/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
> It's back again, after being deleted by Danny and protected by me
> (ZOMG! Wheel war!).  Having seen Ombudsman among the list of
> contributors (actually restarted it after the last deletion) does not
> fill me with confidence...

I'm startled that Google News finds "Israel News Service" worthy of
inclusion among its sources.

Regardless of my opinion that INS is a one-person screed site, it
seems to give it a level of notability higher than other sites we've
put in the "Keep" category.

http://news.google.com/news?hl=en&ned=us&q=israel%20wikipedia&btnG=Search+News

-Andrew (User:Fuzheado)


list: commons-l

subject: [Commons-l] intelligence in flagging

body:
I just logged in to commons, and found a note reporting a problem with
http://commons.wikimedia.org/wiki/Image:Bush_War_Budget_2003-crop.jpg

This, as noted in the text, is a crop of
http://commons.wikimedia.org/wiki/Image:Bush_War_Budget_2003.jpg
which is found to be
public domain.

Those paying close attention will note that the cropped image also has special code in
the title, ("-crop") indicating that its a crop of another image. Nevertheless the
image got flagged.

This presents itself as a problem as Ive noticed a certain automation, and sadly a lack
of intelligence,
in flagging particular images. A more productive usage of time would be to simply
reference the
given link, and add the appropriate information.

Stevertigo

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


list: textbook-l

from_name: Walter Vermeir

subject:
[Textbook-l] Wikibooks 3-year anniversary announcement
	(preliminary)

body:
Robert Scott Horning <robert_horning at ...> writes:
[cut]
>
> I know that this list doesn't really go that far, and that many of the
> same people who subscribe to this list also monitor the Staff Lounge,
> but any help on this is useful.
>
> We would like to proclaim this in a number of places including Wikinews,
> Foundation-l, and a few other places that might be of note with this all
> coordinated on July 10th.   Slashdot was one of the suggested places as
> well, for instance.  If there are any thoughts on how to "publicize"
> this milestone, it would be appreciated.

If I would have known this sooner I could have included this in the "Requests
for help" section.

Now it only that wikibooks exists for 3 years in Wikizine 33. If you have news
you can always send it to me.

Greetings,
Walter


from_name: Simetrical

subject: [Wikitech-l] User block changes

body:
On 7/10/06, Platonides <Platonides at gmail.com> wrote:
> I was recently thinking about how to improve the blocking system. I thought
> in a bit-flag for each action so a finer block could be applied. The list
> which came to my mind is:
>
> *Edit pages
> *Create accounts
> *New pages
> *Move pages
> *Upload files
> *Patrol edits
> *Autoconfirmation (accounts with this block would behave like non-confirmed
> accounts)
> *Block users with that ip to edit
> *Will other users with the same ip get blocked? (autoblocks, only applies to
> blocks to usernames)

I agree that de-autoconfirmation wouldn't be terribly useful, since it
would basically just mean you're barred from a certain set of
privileges, which under this scheme you could block specifically
anyway.

Logically, the list should probably include most $wgGroupPermissions:
createaccount, edit, createpage, createtalk, move, upload, reupload,
reupload-shared, minoredit, delete, deletedhistory, editinterface,
import, importupload, patrol, protect, rollback, trackback (?),
userrights.  Plus, perhaps, a new editowntalkpage permission.

This kind of modular block might be neat, but on the other hand
banning someone from doing the activity and threatening a general
block if the ban is violated is probably just as effective, so it
might not be a very useful expenditure of dev time.


subject: [Wikitech-l] User block changes

references:
<e8su7s$h8r$1@sea.gmane.org> <e8u4iu$nqe$1@sea.gmane.org>
	<7c2a12e20607101143nf57aeb9x22d516bae2266aa1@mail.gmail.com>

body:
On 7/10/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
[snip]
> This kind of modular block might be neat, but on the other hand
> banning someone from doing the activity and threatening a general
> block if the ban is violated is probably just as effective, so it
> might not be a very useful expenditure of dev time.

Right. ... and socially wasteful... Right now we can tell someone to
stop doing a bad thing, and if they ignore, we block. Problem solved.
With a more fine grained system we may well waste our time removing
permissions one at a time. ugh.

If someone can't cooperate they are lost to us and we should just
block, if they can then there is  no need for fancy technical
measures.

The need for anon editing/account creation control is to provide a
work around where good users and bad users share an address because of
factors beyond their control.  It's not a new behavior modification
tool.


body:
Domas Mituzas wrote:

>Hi Jeff,
>
>Making MediaWiki usable by 3rd parties was Brion's initiative, but it
>never produced image of mediawiki that would have same feature set
>like the one we run on live site.
>
>
Thank you for the thoughtful and informative response.

>Of course, extensions used on live site are available to download,
>but I'm not sure everyone can have say.. math support on every
>hosting account. Nor mono with our lucene daemon.
>
>
Yes, I have all of these and they work.

>On the other hand, we always run a version that is not even released
>(right now site runs on 1.8), and there are always features on
>Wikimedia servers that do not exist in rolled out packages.
>
>
This needs to be reviewed. Running 1.8 on your site is not an issue, but
creating XML dumps
which are incompatible with released versions is. This is what needs to
be addressed.

>I don't think php5 is such a menace as you've portrayed, big shops
>(such as Y!) use it, extensions are more developed for php5 than for
>php4, it's OO abilities allow more elegant code (and mediawiki is
>OO'ish), etc.
>
>php5 packages are available for many Linux distributions (some have
>them in 'testing' branches, though) - I've been running php5 RPM on
>my Fedora (even FC3) boxes for quite a while.
>
>
php 5 crashes and is very unstable for a production server without
patching and
a lot of effort to get it working.

>If you think that distributions should have better support for
>MediaWiki, you can ask distributions to do that. They started doing
>mediawiki packages themselves anyway ;-)
>
>Our primary mission is to run website, our secondary mission is to
>provide software and best practices. And those, surprisingly, include
>php5 in the list.
>
>
Well, I would assume that the mission should be to make Wikipedia's
content pervasive. One simple
fix to this is to provide XML dumps which work with released MediaWiki
versions. As it stands, from
an external perspective, the current model appears anti-competitive and
monopolistic (though I as said before,
I do not believe this is intentional).

Please consider providing an XML branch which is compatible with
released MediaWiki versions. This is
not something that should be negotiable or optional -- it should be
mandated as a requirement for publishing
dumps .

Jeff

>Domas
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>
>


from_name: Ilmari Karonen

subject: [Wikitech-l] User block changes

body:
Tietew wrote:
> On Mon, 10 Jul 2006 17:05:31 +1000
> In article <e8su7s$h8r$1 at sea.gmane.org>
> [[Wikitech-l] User block changes]
> Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
>
>>during the schema update. I *think* the winning block will be the earliest
>>one, with all others silently deleted, but we'll see for sure during the update.
>
> How about adding "ORDER BY ipb_id" to patch-ipb_anon_only.sql's
> INSERT INTO ipblocks_newunique.
> It can force to leave each earlist block.
>
> INSERT IGNORE INTO /*$wgDBprefix*/ipblocks_newunique
>         (ipb_id, ipb_address, ipb_user, ipb_by, ipb_reason, ipb_timestamp, ipb_auto, ipb_expiry, ipb_range_start, ipb_range_end, ipb_anon_only, ipb_create_account)
>   SELECT ipb_id, ipb_address, ipb_user, ipb_by, ipb_reason, ipb_timestamp, ipb_auto, ipb_expiry, ipb_range_start, ipb_range_end, 0            , ipb_user=0
>   FROM /*$wgDBprefix*/ipblocks ORDER BY ipb_id;

Ideally, you'd want to sort them by expiration time, but I suppose this
may not be trivial.

Also, would this be a good time to ensure that usernames in ipb_address
are properly normalized?  It seems that at the moment, on enwiki at
least, some of the entries contain underscores and some spaces, the
choice seeming quite random:

http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=+
http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=_

--
Ilmari Karonen


references:
<44B2ADD6.4000101@wolfmountaingroup.com>	<25D144AB-95DA-4650-BD31-9AAE3758F788@gmail.com>	<44B2BA55.2000505@hackish.org>	<44B2BCAD.6060509@pobox.com>
	<44B2D0FC.2020106@wolfmountaingroup.com>

body:
Jeff V. Merkey wrote:
> Brion, it is true.  The XML dumps are not renderable except on the
> unreleased Mediwiki. Take a look at the following.  I am running
> 1.6.7 with all of the extensions installed against the 20060702 XMl
> dumps.  The English and Cherokee versions are both broken.
> Also, SVG images are not rendered on 1.6.7 AT ALL from these dumps due
> to a bug in GetHeight and GetWidth in Image.php.
>
> http://www.wikigadugi.org/wiki/Cherokee_Language
>
> http://www.wikigadugi.org/wiki/Ute_Tribe
>
> http://www.wikigadugi.org/wiki/Back_To_The_Future

These pages are most likely affected by the difference in parser treatment of
embedded HTML in templates when HTML Tidy is engaged.

You can install HTML Tidy (I'm fairly certain current Fedora versions include a
package, if not it's in Extras) and enable its use on your wiki. Unfortunately
the bug (that the behavior is different) hasn't been resolved yet; fortunately
it should be easy enough for you to work around by configuring your site
appropriately.

If the image bug isn't fixed in 1.6.8 already, let me know and I'll merge it for
1.6.9.

(By the way, as mentioned the other day we're pretty offtopic for Foundation-L.)

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060710/f13bde63/attachment.pgp


body:
Jeff V. Merkey wrote:
> Brion, it is true.  The XML dumps are not renderable except on the
> unreleased Mediwiki. Take a look at the following.  I am running
> 1.6.7 with all of the extensions installed against the 20060702 XMl
> dumps.  The English and Cherokee versions are both broken.
> Also, SVG images are not rendered on 1.6.7 AT ALL from these dumps due
> to a bug in GetHeight and GetWidth in Image.php.
>
> http://www.wikigadugi.org/wiki/Cherokee_Language
>
> http://www.wikigadugi.org/wiki/Ute_Tribe
>
> http://www.wikigadugi.org/wiki/Back_To_The_Future

These pages are most likely affected by the difference in parser treatment of
embedded HTML in templates when HTML Tidy is engaged.

You can install HTML Tidy (I'm fairly certain current Fedora versions include a
package, if not it's in Extras) and enable its use on your wiki. Unfortunately
the bug (that the behavior is different) hasn't been resolved yet; fortunately
it should be easy enough for you to work around by configuring your site
appropriately.

If the image bug isn't fixed in 1.6.8 already, let me know and I'll merge it for
1.6.9.

(By the way, as mentioned the other day we're pretty offtopic for Foundation-L.)

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060710/f13bde63/attachment-0001.pgp


body:
Jeff V. Merkey wrote:
> Brion, it is true.  The XML dumps are not renderable except on the
> unreleased Mediwiki. Take a look at the following.  I am running
> 1.6.7 with all of the extensions installed against the 20060702 XMl
> dumps.  The English and Cherokee versions are both broken.
> Also, SVG images are not rendered on 1.6.7 AT ALL from these dumps due
> to a bug in GetHeight and GetWidth in Image.php.
>
> http://www.wikigadugi.org/wiki/Cherokee_Language
>
> http://www.wikigadugi.org/wiki/Ute_Tribe
>
> http://www.wikigadugi.org/wiki/Back_To_The_Future

These pages are most likely affected by the difference in parser treatment of
embedded HTML in templates when HTML Tidy is engaged.

You can install HTML Tidy (I'm fairly certain current Fedora versions include a
package, if not it's in Extras) and enable its use on your wiki. Unfortunately
the bug (that the behavior is different) hasn't been resolved yet; fortunately
it should be easy enough for you to work around by configuring your site
appropriately.

If the image bug isn't fixed in 1.6.8 already, let me know and I'll merge it for
1.6.9.

(By the way, as mentioned the other day we're pretty offtopic for Foundation-L.)

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060710/f13bde63/attachment.pgp>


body:
Jeff V. Merkey wrote:
> Brion, it is true.  The XML dumps are not renderable except on the
> unreleased Mediwiki. Take a look at the following.  I am running
> 1.6.7 with all of the extensions installed against the 20060702 XMl
> dumps.  The English and Cherokee versions are both broken.
> Also, SVG images are not rendered on 1.6.7 AT ALL from these dumps due
> to a bug in GetHeight and GetWidth in Image.php.
>
> http://www.wikigadugi.org/wiki/Cherokee_Language
>
> http://www.wikigadugi.org/wiki/Ute_Tribe
>
> http://www.wikigadugi.org/wiki/Back_To_The_Future

These pages are most likely affected by the difference in parser treatment of
embedded HTML in templates when HTML Tidy is engaged.

You can install HTML Tidy (I'm fairly certain current Fedora versions include a
package, if not it's in Extras) and enable its use on your wiki. Unfortunately
the bug (that the behavior is different) hasn't been resolved yet; fortunately
it should be easy enough for you to work around by configuring your site
appropriately.

If the image bug isn't fixed in 1.6.8 already, let me know and I'll merge it for
1.6.9.

(By the way, as mentioned the other day we're pretty offtopic for Foundation-L.)

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060710/f13bde63/attachment-0001.pgp>


from_name: Guettarda

subject: [WikiEN-l] Just a wiki

body:
On 7/10/06, stevertigo <vertigosteve at yahoo.com> wrote:
>
> Ive flagged [[wikipolitics]] as original research.
>
> There is no doubt some higher level article that deals with using the
> Internet for
> political purposes, campaigning and stuff - one that doesnt read like a
> pandering to
> Wikipedia itself, or is otherwise glorifying one flavor of technology as
> some kind of
> political panacea.
>
> Donde esta el beef?
>
> S

Move it to either the User: space or the Wikipedia: space, and tag it as an
essay.  Or move it to meta:  It may be an article one day, but it isn't
now...


subject: [WikiEN-l] Just a wiki

body:
On 7/10/06, stevertigo <vertigosteve at yahoo.com> wrote:
>
> Id rather let someone else do it. Somebody might de-admin me again.
>
> Steven

Hmm...how does that work - you'd have to pass TWO RFAs before you actually
get your sysop flag back?  Or would you have to get 150-160% of the vote for
your RFA to pass?

Ian

--- Guettarda <guettarda at gmail.com> wrote:
>
> > On 7/10/06, stevertigo <vertigosteve at yahoo.com> wrote:
> > >
> > > Ive flagged [[wikipolitics]] as original research.
> > >
> > > There is no doubt some higher level article that deals with using the
> > > Internet for
> > > political purposes, campaigning and stuff - one that doesnt read like
> a
> > > pandering to
> > > Wikipedia itself, or is otherwise glorifying one flavor of technology
> as
> > > some kind of
> > > political panacea.
> > >
> > > Donde esta el beef?
> > >
> > > S
> >
> >
> > Move it to either the User: space or the Wikipedia: space, and tag it as
> an
> > essay.  Or move it to meta:  It may be an article one day, but it isn't
> > now...
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > To unsubscribe from this mailing list, visit:
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


body:
Tim Starling wrote:

>Jeff V. Merkey wrote:
>
>
>>2.  Has Dependencies on PHP 5.0.0 (5.1.4).  php 5 is a bug infested
>>experimental release which does not have consistent installs on the
>>commerical
>>Linux distributions, including Red Hat ES 4, Suse 10, etc, crashes on
>>apache, is poorly documented, and has a slew of defects, is difficult to
>>install and configure.
>>
>>
>
>PHP 4 is infested with bugs too, the difference is that the PHP devs refuse
>to backport fixes for them. PHP 5 has had 18 releases now, over the course
>of 3 years, and is widely available on commercial web hosts.
>
>It's not the first time we've required PHP updates, we dropped support for
>PHP 4.1.x and then later 4.2.x.
>
>
>
>>What should happen in the future:
>>
>>1.  MediaWiki needs to post releases against commercial Linux distros
>>and not a "roll your own" with a patchwork of patches and fixes.  As it
>>stands,
>>MediaWiki 1.7.1 is not installable or usable on RedHat ES4 or FC5
>>without major patching and recompiling -- steps outside the skills of
>>most folks
>>who need to use Wikipedia content.
>>2.  Wikimedia needs to enforce MediaWiki releases to allow seamless
>>importing and use of XML dumps and content.
>>
>>
>
>I wasn't aware that the linux distros weren't including PHP 5 yet. Here's
>Wikimedia's install script in case it helps:
>
>http://noc.wikimedia.org/~tstarling/install-php
>
>It should work on FC 3, 4 and maybe 5.
>
>
>
>>My 2 cents.
>>
>>I spend currently about 40% of my time getting around MediaWiki problems
>>with Wikipedia XML dumps, and 60% of my time actually working on Native
>>language translations.  The Uto-Aztecan language is being added at
>>present as the Ute and Unita tribes have joined the WikiGadugi project.
>>It would be nice if the MediaWiki folks would give more thought to
>>ensuring their software works properly before posting releases, and the
>>Wikimedia Foundation needs to enforce compatibilty between its published
>>XML dumps and make certain they work properly with released MediaWiki
>>versions.  As it stands, the current setup almost appears
>>anti-competitive by design to prevent folks from creating Wiki's of
>>Wikipedia content (though I do not believe this is intentional on the
>>part of Wikimedia).
>>
>>The "we are community driven" excuse only works if the community is also
>>the customer and end consumer of Wikipedia content, which it is not.
>>Anything we can do to make all of our jobs easier and more pleasant is
>>appreciated.
>>
>>
>
>MediaWiki is primarily written for Wikimedia, development has always been
>driven by Wikimedia's needs. It's no coincidence that we dropped PHP 4
>support not long after we upgraded the Wikimedia cluster to PHP 5. MediaWiki
>is not "community driven" if you take the community to be the external
>sysadmin community. It is driven by the community of Wikimedia users.
>
>I don't know what your problem with the XML dumps is, but I'm sure if there
>is a problem with the format then it can be fixed. If you tell us what it
>is, of course.
>
>Nod to Brion and Domas, I seem to be repeating some of the points they have
>made.
>
>-- Tim Starling
>
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>
>
Thanks for the script. This helps and I appreciate it.

Jeff


body:
Brion Vibber wrote:

>Delirium wrote:
>
>
>>While I know there are plenty of logistical issues involved, I think
>>from the point of view of the Foundation's charitable mission this is
>>somewhat of a problem, because the point of producing Wikipedia is not
>>just to put up an encyclopedia at *.wikipedia.org, but to produce
>>encyclopedia articles that are Free and reusable by anyone.  If the
>>articles we distribute are only fully renderable by unreleased software
>>or software that's particularly complex to set up and configure, that
>>discourages third-party reuse.
>>
>>
>
>And if that were true, I might agree.
>
>

Brion, thanks for offering to help.

Brion, it is true.  The XML dumps are not renderable except on the
unreleased Mediwiki. Take a look at the following.  I am running
1.6.7 with all of the extensions installed against the 20060702 XMl
dumps.  The English and Cherokee versions are both broken.
Also, SVG images are not rendered on 1.6.7 AT ALL from these dumps due
to a bug in GetHeight and GetWidth in Image.php.

http://www.wikigadugi.org/wiki/Cherokee_Language

http://www.wikigadugi.org/wiki/Ute_Tribe

http://www.wikigadugi.org/wiki/Back_To_The_Future

Jeff

>But PHP 5 is neither unreleased nor particularly complex to set up. It's been in
>production for years, is widely available on thousands of free and for-pay
>hosting services, and can be installed on any home computer or server in a
>manner of minutes using any number of package installers.
>
>-- brion vibber (brion @ pobox.com)
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>


from_name: James Hare

body:
Oooh! HTML dumps!

I'll certainly be looking forward to that!

On 7/10/06, Brion Vibber <brion at pobox.com> wrote:
>
> Jeff V. Merkey wrote:
> > This needs to be reviewed. Running 1.8 on your site is not an issue, but
> > creating XML dumps
> > which are incompatible with released versions is. This is what needs to
> > be addressed.
>
> The XML dump format has not changed since 1.5, and should remain backwards
> compatible for the forseeable future.
>
> For wiki-agnostic republishing purposes, we're considering making more
> easily
> used HTML dumps available.
>
> If you want the wikitext source, though, you do need to keep in mind that
> extensions, bug fixes, etc will continue to evolve along with Wikimedia's
> needs,
> so the exact rendering of given input text may necessarily change a bit
> over time.
>
> If you have a specific concern, please let us know.
>
> -- brion vibber (brion @ pobox.com)
>
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>
>
>


from_name: Delirium

body:
Domas Mituzas wrote:

>Making MediaWiki usable by 3rd parties was Brion's initiative, but it
>never produced image of mediawiki that would have same feature set
>like the one we run on live site.
>
>Of course, extensions used on live site are available to download,
>but I'm not sure everyone can have say.. math support on every
>hosting account. Nor mono with our lucene daemon.
>
>On the other hand, we always run a version that is not even released
>(right now site runs on 1.8), and there are always features on
>Wikimedia servers that do not exist in rolled out packages.
>
>
While I know there are plenty of logistical issues involved, I think
from the point of view of the Foundation's charitable mission this is
somewhat of a problem, because the point of producing Wikipedia is not
just to put up an encyclopedia at *.wikipedia.org, but to produce
encyclopedia articles that are Free and reusable by anyone.  If the
articles we distribute are only fully renderable by unreleased software
or software that's particularly complex to set up and configure, that
discourages third-party reuse.

Things like the Lucene search are less of an issue, I think; they're
website infrastructure useful for browsing the encyclopedia, but not
software that's needed to render the articles correctly.

-Mark


subject: [Commons-l] intelligence in flagging

body:
I dont know about all that. All I advocate is a basic bonehead level reading of whats
posted with the image.
It would appear that some are using bots to find and autopost flags and comments. Dunno
if thats as useful.

S

--- peter green <plugwash at P10Link.net> wrote:

> on a related note admins (who i suspect are the bulk of this lists members)
> should remember that anyone can throw any tag they like onto a page. When
> deleting an image because of a tag imo an admin should at MINIMUM.
>
> 1: follow any links on the page (especially ones within wikimedia) looking
> for obvious license/source information
> 2: check the page history (in case the source/license info was removed by
> vandals)
> 3: check that (if applicable) the correct steps to notify the uploader (as
> mentioned in the no source/license tags) were actually carried out (btw do
> you think we should change the policies to require notifying users on what
> appears to be thier primary wiki as well as on commons, i know i only log
> into commons occasionally atm because i'm not actively involved in any
> goings on there since the really unused list became unusable). If they
> weren't notified then the most reasonable course of action is probablly to
> notify them and reset the clock).
> 4: perform a check usage (we really need a proper check usage tool that
> checks all wikis without causing huge server load) and deal with (at least
> remove and if possible replace) any usage of the image.
>
> > -----Original Message-----
> > From: commons-l-bounces at wikimedia.org
> > [mailto:commons-l-bounces at wikimedia.org]On Behalf Of stevertigo
> > Sent: 10 July 2006 22:33
> > To: commons-l at wikimedia.org
> > Subject: [Commons-l] intelligence in flagging
> >
> >
> > I just logged in to commons, and found a note reporting a problem with
> > http://commons.wikimedia.org/wiki/Image:Bush_War_Budget_2003-crop.jpg
> >
> > This, as noted in the text, is a crop of
> > http://commons.wikimedia.org/wiki/Image:Bush_War_Budget_2003.jpg
> > which is found to be
> > public domain.
> >
> > Those paying close attention will note that the cropped image
> > also has special code in
> > the title, ("-crop") indicating that its a crop of another image.
> > Nevertheless the
> > image got flagged.
> >
> > This presents itself as a problem as Ive noticed a certain
> > automation, and sadly a lack
> > of intelligence,
> > in flagging particular images. A more productive usage of time
> > would be to simply
> > reference the
> > given link, and add the appropriate information.
> >
> > Stevertigo
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > Commons-l mailing list
> > Commons-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/commons-l
>
> _______________________________________________
> Commons-l mailing list
> Commons-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/commons-l
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


subject: [WikiEN-l] Just a wiki

body:
Geni, youre not being very helpful with your notions about what "reality suggests" or
what is "acerdemic" or what "isn't posible" or "imposible." I never thought Id say it,
but for your own sake... use a spellchecker.

Similar wheel wars have arisen which have been handled better, some even with special
attention. The community apparently has learned to deal better with these. Apparently
there is now some process review procedure for when the Arbcom screws up. Glad to help
clarify holes in the process. Of course I may be fooling myself, but I am under the
impression that its desirable for editors who make useful edits to have sysop
privelidges.  Its not just a "janitorial" role.

Teenage sysops who like to push their uselessly terse comments as "reality" might make
yourselves more useful by taking care of some WP:RQM . Apparently theres a backlog.

S

--- geni <geniice at gmail.com> wrote:

> Arcom persident suggests you need permission from arbcom to reapply.
>
> Reality suggests the point is acerdemic in any case (not that it is
> imposible just that it isn't posible through RFA).

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Tim Starling

subject: [Wikitech-l] User block changes

body:
Another crosspost to wikipedia-l and wikitech-l, please follow up to one
list only. Tell me offlist if you think the crossposting is useful.

I'm making some changes to user blocks. Here is the changelog entry:

* Allow blocks on anonymous users only (bug 550)
* Allow or disallow account creation from blocked IP addressess on a
per-block basis.
* Prevent duplicate blocks.
* Fixed the problem of expiry and unblocking erroneously affecting multiple
blocks.
* Fixed confusing lack of error message when a blocked user attempts to
create an account.
* Fixed inefficiency of Special:Ipblocklist in the presence of large numbers
of blocks; added indexes and implemented an indexed pager.

This will require a schema update, hopefully it can be done on Wikimedia
with a minimum of disruption.

A unique index will be introduced which will prevent duplicate blocks on
users or IP addresses. To migrate to the new schema, it is necessary that
all existing duplicate blocks be deleted. This will be done automatically
during the schema update. I *think* the winning block will be the earliest
one, with all others silently deleted, but we'll see for sure during the update.

If it's a problem for anyone that these blocks will be removed, please speak
up. I'm not going to create a list of dropped blocks unless anyone has a
really good reason why it's necessary. The original record of the duplicate
block being created, available in Special:Log, will not be deleted, and
there will be a backup of the ipblocks table in case anything goes wrong.

I'll aim to put this change live in about 24 hours from now. It has to be
soon, because we won't be able to deploy any other updates to MediaWiki
until the schema is updated.

I know a lot of people have all sorts of dreams for the perfect blocking
feature, and I'm sorry to say that this won't fulfill all of them. It is a
concrete step forward, it fixes some embarrassing bugs, and it implements a
much requested feature. I'd be happy to hear about your ideas for a perfect
blocking module, just don't expect them to be live on the site within 24 hours.

-- Tim Starling


subject: [WikiEN-l] Time 100 footage

body:
On 7/9/06, Garion1000 <garion1000 at gmail.com> wrote:
> On 5/14/06, Jimmy Wales <jwales at wikia.com> wrote:
> >
> >
> > Amanda Congdon (rocketboom.com) was gracious enough to be our press
> > representative at the recent Time 100 party in New York.  She got a lot
> > of footage of the guests, which was quite a group of famous people,
> > probably at least 100 people at the party already have wikipedia
> > articles, many with no photos or fair use photos.
> >
> > As a condition of being invited, I asked that she release her footage
> > and photos under a free license.
>
>
> What's the current status on this? It really would be great to have this.
>
> And otherwise to Jimbo, could this image
> http://www.flickr.com/photos/jimbo_wales/143261674/ be released under a free
> license? :) Since there are only fair use images on [[Ann Coulter]].
>
> Garion (currently doing some fair use replacement)

I wonder also, given the fact that Rocketboom has imploded this past week.

-Andrew


body:
Brion Vibber wrote:

>Jeff V. Merkey wrote:
>
>
>>Brion, it is true.  The XML dumps are not renderable except on the
>>unreleased Mediwiki. Take a look at the following.  I am running
>>1.6.7 with all of the extensions installed against the 20060702 XMl
>>dumps.  The English and Cherokee versions are both broken.
>>Also, SVG images are not rendered on 1.6.7 AT ALL from these dumps due
>>to a bug in GetHeight and GetWidth in Image.php.
>>
>>http://www.wikigadugi.org/wiki/Cherokee_Language
>>
>>http://www.wikigadugi.org/wiki/Ute_Tribe
>>
>>http://www.wikigadugi.org/wiki/Back_To_The_Future
>>
>>
>
>These pages are most likely affected by the difference in parser treatment of
>embedded HTML in templates when HTML Tidy is engaged.
>
>You can install HTML Tidy (I'm fairly certain current Fedora versions include a
>package, if not it's in Extras) and enable its use on your wiki. Unfortunately
>the bug (that the behavior is different) hasn't been resolved yet; fortunately
>it should be easy enough for you to work around by configuring your site
>appropriately.
>
>If the image bug isn't fixed in 1.6.8 already, let me know and I'll merge it for
>1.6.9.
>
>(By the way, as mentioned the other day we're pretty offtopic for Foundation-L.)
>
>

Well, the technical discussion is certainly off topic.  The discussion
about requiring XML dumps to
work on released MediaWiki versions is something Wikimedia folks need to
think about and be aware of  since its clear folks
were under the assumption the XMl dumps work "as is", which we are
seeing is not the case.

It's clear to me that everyone is on the same page here on this point,
and the thread was useful to establish this
for everyone.  Let's move the discussion off line and you and I can
dialouge about it.

Jeff

>-- brion vibber (brion @ pobox.com)
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>


subject:
[Foundation-l] Uto-Aztecan Languages Added to Wikigadugi.org for
	the English Wikipedia

body:
The following languages are being added to the machine translator for
the following Native Language Variants.  Native Speakers have been
enlisted and are assisting with the construction of the verb stem and
composition constructors for the Machine Translator.  We will
be posting translations of the entire English Wikipedia into the
following Languages:

Northern and Southern Ute
Northern and Southern Shoshonean
Northern and Southern Piaute
Goshute
Uncompahgre Ute
Navajo (Dine)

Most of these variants rely on English phonetics for the output.
Several of the tribes have expressed the desire to map these translations
to the Sequoyah Syllabary.  Initial translations will be published in
text phonetics with some of the translations into the sequoyah syllabary.

Jeff


subject: [Wikitech-l] User block changes

body:
For those of you who found that last post a bit too wordy and complicated,
here's a summary in pictures:

http://noc.wikimedia.org/~tstarling/SpecialBlockip.png


from_name: Wildrick Steele

subject: [Wikitech-l] User block changes

body:
>
> Also, would this be a good time to ensure that usernames in ipb_address
> are properly normalized?  It seems that at the moment, on enwiki at
> least, some of the entries contain underscores and some spaces, the
> choice seeming quite random:
>
> http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=+
> http://en.wikipedia.org/wiki/Special:Ipblocklist?ip=_
>
> --
> Ilmari Karonen
>

Also, there's a problem with long usernames.

Compare:
http://en.wiktionary.org/w/index.php?title=Special%3ALog&type=block&user=&page=User%3ACantsleepclownwilleatmeHAHALOLGOODUSERNAME
http://en.wiktionary.org/wiki/Special:Ipblocklist?action=search&limit=150&ip=CantsleepclownwilleatmeHAHALOLGOODUSERNAME

This must have already been reported at bugzilla, but perhaps this is also
the good moment to fix that.

--
Cheers,
Wildrick
http://en.wiktionary.org/wiki/User:Vildricianus


from_name: Tietew

subject: [Wikitech-l] User block changes

body:
On Mon, 10 Jul 2006 17:05:31 +1000
In article <e8su7s$h8r$1 at sea.gmane.org>
[[Wikitech-l] User block changes]
Tim Starling <t.starling at physics.unimelb.edu.au> wrote:

> during the schema update. I *think* the winning block will be the earliest
> one, with all others silently deleted, but we'll see for sure during the update.

How about adding "ORDER BY ipb_id" to patch-ipb_anon_only.sql's
INSERT INTO ipblocks_newunique.
It can force to leave each earlist block.

-----

INSERT IGNORE INTO /*$wgDBprefix*/ipblocks_newunique
        (ipb_id, ipb_address, ipb_user, ipb_by, ipb_reason, ipb_timestamp, ipb_auto, ipb_expiry, ipb_range_start, ipb_range_end, ipb_anon_only, ipb_create_account)
  SELECT ipb_id, ipb_address, ipb_user, ipb_by, ipb_reason, ipb_timestamp, ipb_auto, ipb_expiry, ipb_range_start, ipb_range_end, 0            , ipb_user=0
  FROM /*$wgDBprefix*/ipblocks ORDER BY ipb_id;
                               ~~~~~~~~~~~~~~~

--
[[User:Tietew]] <tietew at tietew.net>
Wiki: http://meta.wikimedia.org/wiki/User:Tietew
PGP/GPG: 26CB 71BB B595 09C4 0153  81C4 773C 963A D51B 8CAA


from_name: Rob Church

subject: [Wikitech-l] User block changes

body:
On 10/07/06, Platonides <Platonides at gmail.com> wrote:
> *Autoconfirmation (accounts with this block would behave like non-confirmed
> accounts)

That sounds ridiculous and useless, and defeats the idea of being
autoconfirmed. That isn't an appropriate means to go about it.

Rob Church


from_name: Mark Gallagher

body:
G'day Michael,

> This is what confused me. If, as it would seem, you're equating the
> response from gamers with that of a jury, then you've got the concept
>  of jury nullification exactly backwards. Jury nullification does not
>  involve a judge or some other higher authority nullifying the
> decision of the jury. Jury nullification refers to the ability of the
> jury to reach a verdict contrary to the law and the instructions of
> the court. Fans of the concept like to cite John Peter Zenger's

I do indeed have it exactly backwards.  And I don't even have the excuse
of never having heard of the concept before (though I don't know too
much about it).  Call it an elaborate brainfart!

> acquittal on a charge of libel as an example of this.

I suppose you could argue that the IAR principle[0] is Wikipedia's
equivalent, then.

[0] In keeping with my decision to name Important Stuff "principles",
     and other stuff "policy" ...

--
Mark Gallagher
"What?  I can't hear you, I've got a banana on my head!"
- Danger Mouse


from_name: Michael Snow

body:
With apologies, since I last indicated I wouldn't continue a digression
that had moved off-topic, I didn't expect such charges to be made about
me and feel that I should respond publicly. This, however, will
definitely be my last post in this particular discussion regardless, and
if anyone wants to get personal in response I'll ignore it.

Philip Welch wrote:

> On Jul 9, 2006, at 1:24 PM, Michael Snow wrote:
>
>>> Jury nullification also reduced the effectiveness of the American
>>> prohibition of alcohol. Similarly, juries in African-American
>>> communities have apparently been known to acquit black defendants of
>>> certain crimes (particularly drug crimes) in response to perceived
>>> racism on the part of the police.
>>
>> When I pointed out the real meaning of jury nullification I certainly
>> had no intention of starting a racially charged digression. While the
>> possibility of disparate enforcement of the law along racial lines is
>> certainly a serious issue, I've never heard that African-American
>> juries
>> regularly acquit criminals on the basis of race.
>
> I had no such intention either, I was simply repeating something I
> had read previously. I certainly did not mean to imply that "African-
> American juries regularly acquit criminals on the basis of race",
> because it is not the race of the defendant per se, but rather the
> defendant's perceived status as a victim of racism, that is the basis
> of such acquittals. Or at least so I have been led to believe.

However you care to phrase it, I was expressing skepticism about the
reality of the claimed phenomenon. Think of it as a [citation needed],
if you like. You say you read it somewhere, but don't say where. Feel
free to enlighten me off-list if you can.

>> Otherwise, to find actual examples of racial jury nullification I  think
>> you have to look at the *white* juries...this explains why
>> some of jury nullification's most ardent advocates are found in the
>> political fringe where white racists, survivalist militia groups, and
>> radical "constitutionalists" meet.
>>
>> That's all I'll have to say about this, since the discussion no longer
>> directly relates to Wikipedia.
>
> There's nothing better than to call jury nullification advocates
> racist and then wash your hands of the entire affair. (I was trying
> to be neutral in my presentation of what I had heard, but what the
> hell--if I'm on a jury, I'm not putting someone in prison for getting
> caught with some weed on them, no matter what the law says.
> Apparently this means I'm a racist.)

No, it doesn't mean you're racist, nor did I say any such thing. What it
actually means is that if you honestly answer questions that are
appropriately asked, and if the judge and attorneys are at all
competent, you'll be disqualified from serving on any jury for a
marijuana possession case.

You seem proud of your neutral presentation, with some justification,
since it wasn't immediately apparent to me that you advocate jury
nullification. So I wasn't calling you a racist, and I didn't say that
all jury nullification advocates are racist, either. Some are as I have
said, and I make no apologies for pointing out some of the concept's
most undesirable applications. Consider it a caution about the
associations it carries, if you want to continue extolling its virtues.

> Ironically, you're responding to  a message in which I cited jury
> nullification as an antidote to  police racism. I have to commend you
> on a masterful job of trolling,  Michael Snow. You skillfully combined
> the race card, pretending to be  the good guy, and a
> passive-aggressive tone to subtly take this  discussion beyond the
> edge of reason, all with the utmost civility.  I'm actually rather
> impressed.

As I said, it wasn't clear that you were advocating jury nullification
as an "antidote" to anything. In fact, by qualifying the racism as
"perceived", you could just as easily have been questioning whether
there was any racism, challenging the legitimacy of jury nullification
and, more to the point, the conduct of African-American juries
supposedly engaging in it. It wasn't me that brought up race, but since
it was brought up I thought it needed to be pointed out that the
analysis has other racial contexts as well. So I don't feel that I've
done anything to "take this discussion beyond the edge of reason", but
if that's where it's gone, hopefully this can bring it back.

--Michael Snow


from_name: Platonides

subject: [Wikitech-l] User block changes

body:
I was recently thinking about how to improve the blocking system. I thought
in a bit-flag for each action so a finer block could be applied. The list
which came to my mind is:

*Edit pages
*Create accounts
*New pages
*Move pages
*Upload files
*Patrol edits
*Autoconfirmation (accounts with this block would behave like non-confirmed
accounts)
*Block users with that ip to edit
*Will other users with the same ip get blocked? (autoblocks, only applies to
blocks to usernames)

I didn't added sysop actions as they use to need a special group so the
solution would be desysopping and not block deleting ability, but they could
have a place in the flag too.

The SpecialBlock would present a combo or a serie of checkboxes,  or-masked
by the server to get the restriction. A special 'Complete' option (value -1)
would behave as until now.

Of course your interface seems nicer and less complicated, but this kind of
feature could be prepared on the schema update, although not available for
use.

Some combinations are probably useless (block user from edit but allow move
pages ? ) and i have only heard requesting bug 550 and upload block  but i
think this more complete.

Platonides


from_name: Keith Old

body:
On 7/10/06, Daniel P. B. Smith <wikipedia2006 at dpbsmith.com> wrote:
>
> > From: "Matt Brown" <morven at gmail.com>
>
> > On 7/9/06, Sarah <slimvirgin at gmail.com> wrote:
> >> The policy is based on common sense, not dogma. When you send a
> >> letter
> >> to a newspaper for publication, you're expected to supply your name,
> >> address, and telephone number so that someone from the newspaper can
> >> check that you really did send it.
> >
> > I've had letters published in many different newspapers and other
> > publications.  While all or almost all require such information, I
> > have never, ever had any of them check back.
> >
> > I'd imagine if I was claiming to be a well-known individual, they
> > MIGHT check it, but even then, I have my doubts whether they would do
> > so every single time.
>
> I've had perhaps six letters published in the Boston Globe over the
> last fifteen years. They require the city you live in and a telephone
> number for verification. I've been telephoned for verification twice.
> I'm not sure exactly what they were verifying--all they did was ask
> if I was who I said to be, and ask if they had permission to publish
> the letter.
>
> I haven't been called the last three or four times. I don't know
> whether they have anything on file or whether they just didn't bother.
>
> Just a data point.
>
> I personally think there's a BIG difference between occasional,
> casual checking and the _ability_ to verify, and no checking at all.
>
> On the other hand, in the case of, say, a Usenet post that appears to
> be from, say, a university professor named Dr. John Doe at XYZ
> University whose email address is john.doe at xyz.edu, whose email
> address is available from an online directory at www.xyz.edu... if
> you email that address and say "Are you Dr. John Doe and did you post
> this?" and he replies "Yes," that's perfectly reasonable
> verifiability, at least as good as a published letter to the editor.
>
> A news story with a credited reporter's name, with a by-line in which
> the newspaper's name appears (i.e. not a stringer), in which the
> reporter says "so-and-so said thus-and-such" is a much higher level
> of verifiability, though.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

Folks,

In general, I wouldn't expect that a Letter to the Editor would be
significant enough to be mentioned in an article as opposed to other sources
such as books, magazine and newspaper articles and journal articles.

Usenet posts and forum posts in general are even less notable than that even
when they are intelligible and coherent which is often not the case. If Dr
John Doe only said it in a Usenet post and not in a journal article, book or
other more substantial form, then it can't have been that important as a
general rule.

Having said that, I subscribe to the alt-obituaries newsgroup which often
picks up on deaths of notable people before the media reports it. However, I
do a Google News search to see if the media is reporting the death and add
it to the Deaths in 2006 article if there is a media report from a reliable
source. If not, it can wait a day or two until the media picks it up.

In my view, Usenet and other forum posts are not strong sources and we
should have stronger, more substantive sources before including something in
an encyclopedia article as factual.

Regards

Keith Old


body:
Brion Vibber wrote:
> Delirium wrote:
>
>> While I know there are plenty of logistical issues involved, I think
>> from the point of view of the Foundation's charitable mission this is
>> somewhat of a problem, because the point of producing Wikipedia is not
>> just to put up an encyclopedia at *.wikipedia.org, but to produce
>> encyclopedia articles that are Free and reusable by anyone.  If the
>> articles we distribute are only fully renderable by unreleased software
>> or software that's particularly complex to set up and configure, that
>> discourages third-party reuse.
>>
>
> And if that were true, I might agree.
>
> But PHP 5 is neither unreleased nor particularly complex to set up. It's been in
> production for years, is widely available on thousands of free and for-pay
> hosting services, and can be installed on any home computer or server in a
> manner of minutes using any number of package installers.
>

I was speaking of the use of unreleased versions of MediaWiki and
complex/undocumented extension setups (which extensions *are* enabled on
Wikipedia anyway?  I know LaTeX and Cite are; is that all?).  PHP 5 is
fine of course.

-Mark