from_name: geni

subject: [WikiEN-l] Just a wiki

body:
On 7/10/06, 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?
>
> Ian
>

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).

--
geni


list: commons-l

source: pipermail-mbox

from_name: peter green

subject: [Commons-l] intelligence in flagging

body:
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


list: wikipedia-l

from_name: Platonides

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

body:
Andre Engels, your position is: changes to interface should get consensus
before. So, when a new extension is added, or changed, and there're several
new (renamed) messages, should i kindly ask permission for translating it
from english? Don't be ridiculous! I translate them, and if i make mistakes
or something is wrong, another one will change it. It's a wiki, do you
remember? Changing outdated messages is fine to me. And if the other version
is equivalent, there's no 'large change'.

> The action itself was hostile. On Wikipedia we work with consensus,
> not one person doing something and the rest being given a fait
> accompli.
We also [[Wikipedia:Assume good faith|]]. Asking a poll on every change
would [[Wikipedia:Don't disrupt Wikipedia to illustrate a point|disrupt
Wikipedia]]

> 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.
*Then*, it should be argued, but only after it was asked.

> That's your opinion. Mine is that there was. It would have been better
> to discuss this in advance.
And teh sysop's opinion that it wasn't :D

>Someone who does that and afterward does not realize that it's a bad idea,
>breaks
> it.

He doesn't need to realize that "it is a bad idea". There isn't even
consensus about if it was a good idea or not!
You can simply make policy saying: "Noone can change more than 5 mediawiki
messages in a month without having asked the community". Then you can claim
bad faith (or ignorance...). Anyway, i'm sure this user wil think twice and
five times before changing a MediaWiki messsage.


list: foundation-l

from_name: Domas Mituzas

subject: [Foundation-l] MediaWiki 1.7.1 and Wikipedia

body:
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.

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.

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.

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.

Domas


list: wikimedia-l


from_name: Marco Chiesa

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

body:
My 2 cents: if this is a matter only for nl.wiki, then it should be dealt
with by the nl.wiki community and the nl.wiki mailing list. The other (more
important) thing is: how big were the changes? If it is only a change from
"something" to "Something" or from "Something, something else" to "Something
and something else", I don't think there's any need to discuss. If the
changes were more substantial, maybe telling in advance could have been
useful, but anyway being bold is always a good thing. I just hope the goal
of this thread is not just making a point.
Marco/Cruccone

On 7/10/06, Platonides <Platonides at gmail.com> wrote:
>
> Andre Engels, your position is: changes to interface should get consensus
> before. So, when a new extension is added, or changed, and there're
> several
> new (renamed) messages, should i kindly ask permission for translating it
> from english? Don't be ridiculous! I translate them, and if i make
> mistakes
> or something is wrong, another one will change it. It's a wiki, do you
> remember? Changing outdated messages is fine to me. And if the other
> version
> is equivalent, there's no 'large change'.
>
> > The action itself was hostile. On Wikipedia we work with consensus,
> > not one person doing something and the rest being given a fait
> > accompli.
> We also [[Wikipedia:Assume good faith|]]. Asking a poll on every change
> would [[Wikipedia:Don't disrupt Wikipedia to illustrate a point|disrupt
> Wikipedia]]
>
>
> > 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.
> *Then*, it should be argued, but only after it was asked.
>
> > That's your opinion. Mine is that there was. It would have been better
> > to discuss this in advance.
> And teh sysop's opinion that it wasn't :D
>
>
> >Someone who does that and afterward does not realize that it's a bad
> idea,
> >breaks
> > it.
>
> He doesn't need to realize that "it is a bad idea". There isn't even
> consensus about if it was a good idea or not!
> You can simply make policy saying: "Noone can change more than 5 mediawiki
> messages in a month without having asked the community". Then you can
> claim
> bad faith (or ignorance...). Anyway, i'm sure this user wil think twice
> and
> five times before changing a MediaWiki messsage.
>
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


list: wikitech-l

subject: [Wikitech-l] User block changes

body:
Well, global blocks may be just as useful sometimes :) But then, why do we
have autoconfirmation and semi-protection? Wasn't it also a waste of our
time semi-blocking and then blocking? ;)

And you have also to remember some problems like user-complaining (not
really resolved when they can answer on its discussion page).

A more fine grained system can be better, as you have more abilities. If you
don't want to remove
permissions one at a time, make a complete block. Soft-blocks and
upload-only blocks, *are a requesting*, so more graining doesn't seem so
useless.

About a expenditure of dev time, it doesn't seem difficult to me. Simply
change the IsBlocked() for IsBlockedEdit(), IsBlockedUpload()... They only
need to have a and-mask on the blocked flag (more complicated would be the
blocking amounting). This is the moment to do it, when several changes to
blocks are being added and there is a schema update.

Tim 'would be happy to hear about our ideas'. I simply speak what had been
thought about. If it's not a good idea, well... it can be dropped. I will
still be able to sleep at nights :-)

Platonides


from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2006-07-11

body:
An automated run of parserTests.php showed the following failures:

Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test Template with thumb image (wiht link in description)... FAILED!
Running test message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test Parsing optional HTML elements (Bug 6171)... FAILED!
Running test Inline HTML vs wiki block nesting... FAILED!
Running test Mixing markup for italics and bold... FAILED!
Running test 5 quotes, code coverage +1 line... FAILED!
Running test HTML Hex character encoding.... FAILED!
Running test dt/dd/dl test... FAILED!

Passed 407 of 424 tests (95.99%) FAILED!


from_name: Andre Engels

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

body:
2006/7/10, Platonides <Platonides at gmail.com>:
> Andre Engels, your position is: changes to interface should get consensus
> before. So, when a new extension is added, or changed, and there're several
> new (renamed) messages, should i kindly ask permission for translating it
> from english? Don't be ridiculous! I translate them, and if i make mistakes
> or something is wrong, another one will change it. It's a wiki, do you
> remember? Changing outdated messages is fine to me. And if the other version
> is equivalent, there's no 'large change'.

There's nothing outdated about the messages, and changing numerous
existing translations is quite different from translating them afresh.

> > The action itself was hostile. On Wikipedia we work with consensus,
> > not one person doing something and the rest being given a fait
> > accompli.
> We also [[Wikipedia:Assume good faith|]]. Asking a poll on every change
> would [[Wikipedia:Don't disrupt Wikipedia to illustrate a point|disrupt
> Wikipedia]]

I'm not saying there should be a poll. I'm saying there should be
given an opportunity to discuss. No objections? Fine, go ahead.
Objections? Fine too, the thing can only get better from that. It sure
beats giving people a fait accompli.

> > 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.
> *Then*, it should be argued, but only after it was asked.

After what was asked?

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


list: wikien-l

subject: [WikiEN-l] Just a wiki

body:
On 7/11/06, stevertigo <vertigosteve at yahoo.com> wrote:
> 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
>

Dunno about Teenage sysops we have some pretty good ones (some have
been on arbcom). I'm more a WP:CP man myself but each to his own
backlog.

--
geni


from_name: Tim Starling

subject: [Wikitech-l] User block changes

body:
Wildrick Steele wrote:
> 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.

It is indeed a good moment to fix it, which is why I did so. Apologies for
not including it in the changelog.

-- Tim Starling


subject: [Wikitech-l] User block changes

body:
Ilmari Karonen wrote:
> Ideally, you'd want to sort them by expiration time, but I suppose this
> may not be trivial.

It's 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=_

I'll look into that.

-- Tim Starling


from_name: rose.parks at att.net

subject: [Wikipedia-l] Campaigns Wikia

body:
Thank you, Andre.
     The message I posted was purposely written with the intention of saying nothing either positive or negative. And, the main reason for that is that I am not familiar with the site and have formed no opinions about it.

                         As Ever,

                              Ruth Ifcher
--

 -------------- Original message ----------------------
From: "Andre Engels" <andreengels at gmail.com>
> 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
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


body:
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


from_name: Robert Scott Horning

subject: [Foundation-l] Wikibooks 3-year anniversary

body:
The Wikibooks community has decided to "publish" an annual report of the
activities of the project as a part of a formal report to the Wikimedia
community at large, and to the Wikimedia Foundation board of trustees in
particular.

Yesterday (July 10th) was the 3-year anniversary since
http://textbooks.wikipedia.org/ was first started and the first content
was added to what is now the Wikibooks project.  There have been some
signficant milestones which have been met, and some very interesting
projects that have been going on.

For the full report, please see:

http://en.wikibooks.org/wiki/Wikibooks:State_of_the_Project/2006

We tried to include other languages as best as we could, but the
communication between the various language Wikibooks projects is
unfortunately spotty at best.

Thanks to all of the participants who have helped make Wikibooks what it
is today.

--
Robert Scott Horning


from_name: Brion Vibber

body:
Delirium wrote:
> 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.

Here are the extensions that affect content rendering currently in use:

Cite/Cite.php
ParserFunctions/ParserFunctions.php

A few wikis also have:
intersection/DynamicPageList.php

Additionally enabled and used in the edittools but not generally in content:
CharInsert/CharInsert.php

Math and SVG rendering are also in use on Wikipedia, so should be enabled if
taking our current content straight.

$wgLegalTitleChars should have "+" appended to it for compatibility. This will
most likely be added to the default in the next revision, unless I forget about
it again.

You can find a fuller list of extensions at Special:Version.

-- 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/20060711/1f48b586/attachment.pgp


body:
Delirium wrote:
> 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.

Here are the extensions that affect content rendering currently in use:

Cite/Cite.php
ParserFunctions/ParserFunctions.php

A few wikis also have:
intersection/DynamicPageList.php

Additionally enabled and used in the edittools but not generally in content:
CharInsert/CharInsert.php

Math and SVG rendering are also in use on Wikipedia, so should be enabled if
taking our current content straight.

$wgLegalTitleChars should have "+" appended to it for compatibility. This will
most likely be added to the default in the next revision, unless I forget about
it again.

You can find a fuller list of extensions at Special:Version.

-- 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/20060711/1f48b586/attachment-0001.pgp


body:
Delirium wrote:
> 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.

Here are the extensions that affect content rendering currently in use:

Cite/Cite.php
ParserFunctions/ParserFunctions.php

A few wikis also have:
intersection/DynamicPageList.php

Additionally enabled and used in the edittools but not generally in content:
CharInsert/CharInsert.php

Math and SVG rendering are also in use on Wikipedia, so should be enabled if
taking our current content straight.

$wgLegalTitleChars should have "+" appended to it for compatibility. This will
most likely be added to the default in the next revision, unless I forget about
it again.

You can find a fuller list of extensions at Special:Version.

-- 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/20060711/1f48b586/attachment.pgp>


body:
Delirium wrote:
> 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.

Here are the extensions that affect content rendering currently in use:

Cite/Cite.php
ParserFunctions/ParserFunctions.php

A few wikis also have:
intersection/DynamicPageList.php

Additionally enabled and used in the edittools but not generally in content:
CharInsert/CharInsert.php

Math and SVG rendering are also in use on Wikipedia, so should be enabled if
taking our current content straight.

$wgLegalTitleChars should have "+" appended to it for compatibility. This will
most likely be added to the default in the next revision, unless I forget about
it again.

You can find a fuller list of extensions at Special:Version.

-- 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/20060711/1f48b586/attachment-0001.pgp>


from_name: Delphine Ménard

subject: [Foundation-l] Wikimedia visual identity guidelines

body:
On 7/6/06, Jean-Denis Vauguet <jd at typhon.org> wrote:

> I created a subsection on the (right?) WMF translation page on Meta:
> http://meta.wikimedia.org/wiki/Translation_requests/WMF#Miscellaneous
>
> 'Need to go, so it's work in progress for fr. I hope it's the way to go,
> hit me if I've been bold *too much* and made a mistake.

Thank you. Yes, that is the way to go.

A disclaimer at the top saying that the English version is the
official one would be grand.

Best,

Delphine
--
~notafish


from_name: stevertigo

subject: [Commons-l] intelligence in flagging

body:
Its not an issue of determining responsibility. Its an issue of efficiency, as it is
more efficient to read the image for information.

S

--- Siebrand Mazeland <s.mazeland at xs4all.nl> wrote:

> On a more general note: in my opinion an uploader is ALWAYS responsible for
> correct and complete license and source information. It is not a duty for an
> admin to go and get it when either is missing, nor should the Commons admin
> chase al around the Wikimedia landscape to notify an uploader on his home
> wiki(s).
>
> It is the responsibility of admins to ensure no policy violations occur, to
> notify users of possible violations and/or missing information and educate
> users where needed.
>
> Requiring admins to follow each and every link in search for information
> regarding an image is definately not the way to go, in my opinion.
>
> Cheers!
>
> Siebrand
>
> -----Oorspronkelijk bericht-----
> Van: commons-l-bounces at wikimedia.org
> [mailto:commons-l-bounces at wikimedia.org] Namens Platonides
> Verzonden: dinsdag 11 juli 2006 13:00
> Aan: commons-l at wikimedia.org
> Onderwerp: Re: [Commons-l] intelligence in flagging
>
>
> "stevertigo" wrote:
> > This presents itself as a problem as Ive noticed a certain automation,
> > and sadly a lack of intelligence,
>
> Yes, you're right. That image was automatically flagged as no-license by
> Orgullobot, so there's automation and bots are not very intelligent ;-)
>
> The good notice is that nobody lost time flagging it, maybe it wasn't even
> check by a human before you arrived. The uploader got a message but didn't
> correct it.
>
> _______________________________________________
> 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


from_name: Kirill Lokshin

subject: [WikiEN-l] Persondata?

body:
On 7/11/06, Magnus Manske <magnus.manske at web.de> wrote:
> Are we prefering {{Persondata}} or {{Infobox biography}}?
>
> Should they be merged, somehow?
>
> I'm asking this because I'm writing a tool to generate Persondata from
> article text as a copy&paste text. Can scan whole categories at once.

One ({{Persondata}}) is raw metadata, but is applicable to _all_
biographies; the other ({{Infobox biography}}) is designed for display
to users, but has been replaced in certain types of biographies
(politicians, royalty, military leaders) with more specialized
templates.

Ideally, we could have a tool that would be able to parse at least the
major infobox types and fill out the persondata fields; but I'm not
sure how much work it would be, considering that there is a certain
variation in how different infoboxes deal with particular data.

--
Kirill Lokshin


from_name: Mattis Manzel

subject: [Wikipedia-l] Campaigns Wikia

body:
Roughly the same functionality, no adds, full
[http://www.communitywiki.org/odd/WikiNet/HomePage
wiki-net]-integration, exists since June 2005:

[http://www.communitywiki.org/odd/NodeWikiForPoliticalWikis/HomePage
political-wiki-center]

thx.

mattis

rose.parks at att.net schrieb:
> Thank you, Andre.
>      The message I posted was purposely written with the intention of saying nothing either positive or negative. And, the main reason for that is that I am not familiar with the site and have formed no opinions about it.
>
>                          As Ever,
>
>                               Ruth Ifcher
> --
>
>
>  -------------- Original message ----------------------
> From: "Andre Engels" <andreengels at gmail.com>
>
>> 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
>> _______________________________________________
>> Wikipedia-l mailing list
>> Wikipedia-l at Wikimedia.org
>> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

___________________________________________________________
Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de


from_name: poore5 at adelphia.net

subject: [WikiEN-l] Persondata?

body:
---- Magnus Manske <magnus.manske at web.de> wrote:
> Kirill Lokshin schrieb:
> > On 7/11/06, Magnus Manske <magnus.manske at web.de> wrote:
> >
> >> Are we prefering {{Persondata}} or {{Infobox biography}}?
> >>
> >> Should they be merged, somehow?
> >>
> >> I'm asking this because I'm writing a tool to generate Persondata from
> >> article text as a copy&paste text. Can scan whole categories at once.
> >>
> >
> > One ({{Persondata}}) is raw metadata, but is applicable to _all_
> > biographies; the other ({{Infobox biography}}) is designed for display
> > to users, but has been replaced in certain types of biographies
> > (politicians, royalty, military leaders) with more specialized
> > templates.
> >
> I'll stick to Persondata, then.
> > Ideally, we could have a tool that would be able to parse at least the
> > major infobox types and fill out the persondata fields; but I'm not
> > sure how much work it would be, considering that there is a certain
> > variation in how different infoboxes deal with particular data.
> >
> >
> I've done raw text extraction for the German Personendaten. While the en
> version is still experimental, it works OK in many cases:
> http://tools.wikimedia.de/~magnus/persondata.php?category=1984_deaths
>
> I could add popular infoboxes (any suggestions?) and German
> Personendaten, if a de article exists.
>
> Magnus

Hello Magnus,

Could you explain a little more about how you plan to use the tool?

I have some concerns about using it on Biographies of living people on Wikipedia-en. We have too much unverified information added to these article. I strongly believe that each article needs to be examined closely to verify the content meets our Wikipedia:BLP guidelines before it is added to a template.

Regards,
Sydney Poore


body:
On 7/11/06, Delirium <delirium at hackish.org> wrote:
> 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

http://en.wikipedia.org/wiki/Special:Version

--
geni


from_name: Jeff V. Merkey

body:
Brion Vibber wrote:

>Delirium wrote:
>
>
>>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.
>>
>>
>
>Here are the extensions that affect content rendering currently in use:
>
>Cite/Cite.php
>ParserFunctions/ParserFunctions.php
>
>A few wikis also have:
>intersection/DynamicPageList.php
>
>Additionally enabled and used in the edittools but not generally in content:
>CharInsert/CharInsert.php
>
>Math and SVG rendering are also in use on Wikipedia, so should be enabled if
>taking our current content straight.
>
>$wgLegalTitleChars should have "+" appended to it for compatibility. This will
>most likely be added to the default in the next revision, unless I forget about
>it again.
>
>You can find a fuller list of extensions at Special:Version.
>
>-- brion vibber (brion @ pobox.com)
>
>
>
Brion,

I downloaded 1.6.8 last night and the SVG rendering was still broken.  I
can hack the script and get it working, but I would rather wait for
you to post a 1.6.9 release.  Also, the HTML tidy suggestion is not an
option -- we should fix our bugs rather than use an external program
to cleanup the mess left by the bugs :-).

I got 1.7 installed, however, the page rendering is still trashed.
Would you like an account on wikigadugi.org to poke around in my database
and MediaWiki setup to see if there's a problem there or for some
insights?   I am open to giving you one to help me determine how best to
solve the issues of "as is" XMl dumps so other folks supporting
Wikimedia won't encounter this problem again.

Jeff


from_name: Death Phoenix

subject:
[WikiEN-l] Should we block unregistered AOL users? (was:
	[Wikitech-l] User block changes)

references:
<e8su7s$h8r$1@sea.gmane.org> <e8vdjk$d5s$1@sea.gmane.org>
	<44B3D213.40203@vyznev.net>

body:
On 7/11/06, Ilmari Karonen <nospam at vyznev.net> wrote:
>
> As some of you may have noted, we now have a couple of new options to
> choose when blocking users.  Tim Starling, who implemented the feature,
> posted the following clarification on the wikitech-l list:
>
> Tim Starling wrote:
> <snip>
> >
> > This holds regardless of the anon-only option. This means that anon-only
> > range blocks or IP blocks can be used to mitigate the effects of
> autoblocks
> > on shared IP addresses, because an anon-only block will allow logged in
> > users to edit regardless of the presence of a matching autoblock. This
> has a
> > potential to be counterintuitive -- unblocking someone's IP can in fact
> > cause them to be blocked. But I thought it was better than the other
> solutions.
>
> Given the above, would it now be advisable to block the entire AOL proxy
>   pool from editing by unregistered users?  This would have the side
> effect that AOL users would no longer be hit by random autoblocks.
>

My initial opinion on this would be to do so. It would be great if we could
replace the entire advice section of [[Wikipedia:Advice to AOL users]] with
"Register an account" and no longer have to deal with the headaches of AOL
vandalism affecting valid users.


subject: [Commons-l] intelligence in flagging

body:
"stevertigo" wrote:
> This presents itself as a problem as Ive noticed a certain automation, and
> sadly a lack
> of intelligence,

Yes, you're right. That image was automatically flagged as no-license by
Orgullobot, so there's automation and bots are not very intelligent ;-)

The good notice is that nobody lost time flagging it, maybe it wasn't even
check by a human before you arrived. The uploader got a message but didn't
correct it.

For more info about Orgullobot, see
http://commons.wikimedia.org/wiki/User:Orgullobot
*Collects newly uploaded files from Special:Newimages, waits two hours, and
if by then it is obviously not properly tagged, marks it as such and
requests that the user who uploaded it clarify its copyright status.

Now, i have set the image information.

Platonides


from_name: Ray Saintonge

subject: [Foundation-l] GFDL publisher credit (was: Wikibooks for sale)

body:
Erik Moeller wrote:

>On 7/4/06, Anthony <wikilegal at inbox.org> wrote:
>
>
>>It would also be nice
>>to once and for all answer the question as to whether or not Wikimedia
>>claims to be the "publisher" as the term is used in the GFDL.
>>
>>
>
>This is the first time this has come to my attention, and I would also
>appreciate a response on this issue. The GFDL explicitly requires the
>"publisher" to be credited in the history of modified versions
>(section 4.I), though not in the title (indeed, it explicitly states
>that the new publisher should be credited instead). It does not
>provide a definition for the term "publisher." It is not our current
>practice to require publisher credit to the WMF, though it is also
>somewhat unclear when section 2, "Verbatim Copying" and when section
>4, "Modifications" would apply; "Verbatim Copying" only places minimal
>requirements on third parties.
>
>Does the WMF consider itself the publisher?
>
>I think it would be quite important to have a legally authoritative
>interpretation of the GFDL as it applies to Wikimedia Foundation
>project content. So far we've been basically "playing it by ear" when
>it comes to GFDL compliance.
>
Whether WMF considers itself a publisher is a matter of policy.  A
"legally authoritative interpretation" is a different matter, and no
lawyer's interpretation in an opinion letter will be authoritative.
Legal authority can only come from real court decisions.

Ec


subject: [Foundation-l] GFDL publisher credit

body:
Jeffrey V. Merkey wrote:

>Erik Moeller wrote:
>
>
>>On 7/4/06, Anthony <wikilegal at inbox.org> wrote:
>>
>>
>>>It would also be nice
>>>to once and for all answer the question as to whether or not Wikimedia
>>>claims to be the "publisher" as the term is used in the GFDL.
>>>
>>>
>Under US Law, Wikimedia is the "publisher" because they create
>"collections" of works of the
>Wikipedia site and "publish" them to the world as XML dumps.
>
Viewed by itself this is not a meaningful statement.  Different parts of
US law (even only with reference to federal law) can define "publisher"
in entirely different and often contradictory ways.  Any definition that
can be used for copyright purposes could be quite different from that
which is applicable to libel.

>Whether electronic or in book form, they
>are publishing. This being said, given the nebulous and undefined state
>of internet IP law,
>whether they are a publisher or not, there's no legal precedence to
>determine liability, so at present
>they are operating in an area of experimental law on the frontiers of
>human knowledge.
>
Of course.

Ec


subject: [Foundation-l] GFDL publisher credit


from_name: Anthony

subject: [Commons-l] intelligence in flagging

body:
On 7/11/06, Siebrand Mazeland <s.mazeland at xs4all.nl> wrote:
> On a more general note: in my opinion an uploader is ALWAYS responsible for
> correct and complete license and source information. It is not a duty for an
> admin to go and get it when either is missing, nor should the Commons admin
> chase al around the Wikimedia landscape to notify an uploader on his home
> wiki(s).
>
> It is the responsibility of admins to ensure no policy violations occur, to
> notify users of possible violations and/or missing information and educate
> users where needed.
>
> Requiring admins to follow each and every link in search for information
> regarding an image is definately not the way to go, in my opinion.
>
In my opinion the way to go would be to use common sense.  If an image
description says it's a crop of another image, looking at that image
description would be a common sense thing to do.

Of course, if common sense isn't required, and any image without a tag
is immediately deletable without any further checks, then images
shouldn't be allowed to be uploaded without tags in the first place.

Anthony


from_name: Oldak Quill

subject: [Commons-l] PLEASE HELP the Welcome log

body:
Since the welcome template is entirely non-personal, why not get someone to
design a bot to do this job? Within minutes of a user signing up a message
could be left by the bot so giving them some introductory information. It is
preferable that the bot have some inbuilt delay between signup and message
so that the user can see the message pop-up after a few minutes editing.

On 11/07/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
>
> Hello Commonsfolk and recently subscribed admins,
>
> http://commons.wikimedia.org/wiki/User:Orgullobot/Welcome_log
>
> This is another plea for assistance on the Welcome log. PLEASE HELP us
> check it, even if it's only two users each day. There is a backlog of
> nearly two weeks.
>
> Newbies make a ton of mistakes and catching them early and correcting
> them is one way to cut down on future workload in terms of reducing
> required unlinking of images that need to be deleted, stopping problem
> uploaders earlier and reduce 'orphan' uncategorised images.
>
> After you've corrected their mistakes and left them a note explaining
> what they're doing wrong, if necessary, please remove their name from
> the list. It's very straightforward.
>
> Please help... even if you just look for some 'easy' users that had
> made no mistakes and remove their names from the list.
>
> http://commons.wikimedia.org/wiki/User:Orgullobot/Welcome_log
>
> thanks,
>
> Brianna
> User:pfctdayelise
>
> PS: If you don't have 'quick nominate as no source/no license/for
> deletion + notify uploader' links installed, you might like to. See
> http://commons.wikimedia.org/wiki/MediaWiki_talk:Quick-delete.js
> _______________________________________________
> Commons-l mailing list
> Commons-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/commons-l
>

--
Oldak Quill (oldakquill at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/commons-l/attachments/20060711/78d43dfd/attachment.htm


subject: [Commons-l] PLEASE HELP the Welcome log

body:
Ah, I apologise! Yes, I'll attempt to lend a hand.

On 11/07/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
>
> On 11/07/06, Oldak Quill <oldakquill at gmail.com> wrote:
> > Since the welcome template is entirely non-personal, why not get someone
> to
> > design a bot to do this job? Within minutes of a user signing up a
> message
> > could be left by the bot so giving them some introductory information.
> It is
> > preferable that the bot have some inbuilt delay between signup and
> message
> > so that the user can see the message pop-up after a few minutes editing.
>
> A bot *does* do this job.... I am not asking people to welcome users.
> I am asking them to check the user's uploads.
>
> The bot only welcomes new users after they have made at least one edit
> or one upload.
>
> Brianna
> _______________________________________________
> Commons-l mailing list
> Commons-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/commons-l
>

--
Oldak Quill (oldakquill at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/commons-l/attachments/20060711/f9ba9afd/attachment.htm


from_name: Tim 'avatar' Bartel

subject: [Commons-l] intelligence in flagging

body:
Hi,

peter green schrieb am 10.07.2006 23:48:
> 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.

For the first half of the sentence, we have this:
http://tools.wikimedia.de/~daniel/WikiSense/CheckUsage.php

The problem is that the en-wp is broken and have to be checked by hand.
Hopefully this will be fixed soon.

Bye, Tim.

--
PCMCIA?
People Can't Memorize Computer Industry Acronyms?
-> Message-ID: <3A2BF156.91B2A24 at gmx.net>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 546 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/commons-l/attachments/20060711/a4da8aae/attachment.pgp


from_name: Jeremy Tobacman

subject:
[Wikitech-l] Updates: XML parser, weekly stats production, server,
	readership data

body:
[1] Thanks to superb work by Erik Garrison, we now have an efficient,
C-based parser that extracts header data from WMF xml dumps into csv files
readable by standard statistical software packages.
  * Source for this parser will soon be web-available; stay tuned.
  * The csv files will also be available online, either from
download.wikimedia.org (if the parser can be run on the WMF servers) or from
a webserver on karma or at NBER (see below).
  * If you just can't wait, let us know and we'll offer express service :)
  * The csv files consist of these variables with these types:
names:  title,articleid,revid,date,time,anon,editor,editorid,minor
types:  str,int,int,str,str,[0/1],str,int,[0/1]

[2] We have begun to use these csv files to produce weekly sets of
statistics.
See last week's work here:
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wikidemia/Quant/Stats2006-07-03

This week we will finish out that set of stats.
Next week's list needs your creative suggestions:  Please edit directly!
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wikidemia/Quant/Stats2006-07-17

[3] NBER has set us up with a pretty good Linux box, wikiq.nber.org, running
Fedora Core 5.  We hope to have Xen instances available for researchers
interested in doing statistical analysis on the csv files within two weeks.

[4] WMF readership data continues to be irretrievably lost.  What can we do
to begin saving at least some of it as soon as possible?  If we were to save
only articleid for one of every hundred squid requests, and include some
indicator in the file at the end of each day, privacy concerns and
computational burdens would be minimized, and this would still be a great
start.
     How can we make this happen?

Best,
Jeremy


subject: [Commons-l] Radical proposal

body:
Crossposted to
http://commons.wikimedia.org/wiki/Commons:Village_pump#Radical_proposal

Since sorting images seems to be a categorical affair, and that articles here do not
require much in the way of articles or descriptions, is it possible to make article
pages function as if they were a category?
It would save some typing, and reduce use of static linkage (ie. articles) in favor of
dynamic likage (ie. categories).

"Articles" in turn would require fitting into a namespace, though I agree that would
seem to defy convention.
Again, this idea is based on the notion that everything could fit into category pages,
or commons: pages, and little else. A migration/integration campaign would be required.

Steven

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


subject: [Foundation-l] GFDL publisher credit

body:
Fred Bauder wrote:

>On Jul 4, 2006, at 10:44 AM, Jeffrey V. Merkey wrote:
>
>
>>Under US Law, Wikimedia is the "publisher" because they create
>>"collections" of works of the
>>Wikipedia site and "publish" them to the world as XML dumps. Whether
>>electronic or in book form, they
>>are publishing. This being said, given the nebulous and undefined
>>state of internet IP law,
>>whether they are a publisher or not, there's no legal precedence to
>>determine liability, so at present
>>they are operating in an area of experimental law on the frontiers of
>>human knowledge.
>>
>>
>
>Not exactly and now that you are a "publisher" too, let us discuss
>the problem. Someone comes on your wiki and enters the information,
>"John Doe murdered his wife, Jane". You don't notice it and after 6
>months or so John Doe files a libel action. You might want to claim
>that the anonymous ip who entered that information was the publisher,
>not you. There is a variant where that edit was contained in an XML
>dump that you did not notice. Meanwhile Wikipedia has deleted it
>completely, even from the history of the article. This is all pretty
>theoretical until there is significant distribution of a serious
>libel, but I throw it out to think about. Now suppose you did notice
>the information and rather than deleting it you just corrected the
>grammar and spelling. Are you the publisher  now? And who is "you"?
>
At the root of things, "to publish" is "to make things public".  There
is nothing in the concept to imply that the person doing so is in the
business of producing books, magazines, web pages or anything of the
sort.  At one time publication could have been by the medium of a town
crier.

I don't think that the mere proofreader can be considered a publisher.
He does not produce any new information that he makes public.

A key factor in distinguishing between a publisher and an ISP seems to
be editorial control, and oonsciously active participation in the
editing process.  An ISP who is told that there is something illegal
about a page can easily remove it as a result of being so told.  Being
pro-active in this may be more characteristic of a publisher, because it
involves making our own legal decisions about whether a writing is in
some fashion illegal.

Ec


subject: [Foundation-l] GFDL publisher credit


body:
I think it would be important to give the report a more multilingual feel.
Wikibooks is, after all, a project consisting of many language sub-projects
(rather than an English project with non-English sister projects).

On 11/07/06, Robert Scott Horning <robert_horning at netzero.net> wrote:
>
> The Wikibooks community has decided to "publish" an annual report of the
> activities of the project as a part of a formal report to the Wikimedia
> community at large, and to the Wikimedia Foundation board of trustees in
> particular.
>
> Yesterday (July 10th) was the 3-year anniversary since
> http://textbooks.wikipedia.org/ was first started and the first content
> was added to what is now the Wikibooks project.  There have been some
> signficant milestones which have been met, and some very interesting
> projects that have been going on.
>
> For the full report, please see:
>
> http://en.wikibooks.org/wiki/Wikibooks:State_of_the_Project/2006
>
> We tried to include other languages as best as we could, but the
> communication between the various language Wikibooks projects is
> unfortunately spotty at best.
>
> Thanks to all of the participants who have helped make Wikibooks what it
> is today.
>
> --
> Robert Scott Horning
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

--
Oldak Quill (oldakquill at gmail.com)


from_name: Platonides

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

body:
"Andre Engels" wrote:
>> > 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.
>> *Then*, it should be argued, but only after it was asked.
>
> After what was asked?

After someone said that they thought it a large change.


subject: [Wikitech-l] User block changes

references:
<e8su7s$h8r$1@sea.gmane.org> <e8vdjk$d5s$1@sea.gmane.org>
	<7c2a12e20607111506s639aa1f5tc2113631b6e95e2c@mail.gmail.com>

body:
Simetrical wrote:
> Wouldn't it be more intuitive to just say "blocked" takes precedence
> over "unblocked"?  I'm not clear on what the problem is with that,
> although I'm pretty tired at the moment.  Certainly that's how every
> other blocking system I know of (message board, IRC, etc.) works.  Of
> course, IRC also has excepts, invites, and voices to stop range-blocks
> from affecting regulars.
>
> Do we actually need to worry about range-blocks affecting regulars,
> though?

Er, yes -- that's the whole issue. Blocks of ranges such as big ISPs frequently
caught regulars who are stuck with that ISP.

-- 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/wikitech-l/attachments/20060711/2e7beb9c/attachment.pgp>


from_name: Tim Starling

subject: [Wikitech-l] User block changes

body:
A couple of people asked me about interaction between various kinds of
blocks and block options, and indeed, in some cases the behaviour was
undefined or accidental. I've now implemented the following rules:

* The "anon only" and "prevent account creation" options will be silently
ignored on username blocks.
* The precedence of blocks in cases of conflict, from highest to lowest, is:
   * Username block
   * Single IP block
   * Range block
   * Autoblock

This holds regardless of the anon-only option. This means that anon-only
range blocks or IP blocks can be used to mitigate the effects of autoblocks
on shared IP addresses, because an anon-only block will allow logged in
users to edit regardless of the presence of a matching autoblock. This has a
potential to be counterintuitive -- unblocking someone's IP can in fact
cause them to be blocked. But I thought it was better than the other solutions.

-- Tim Starling


from_name: Nick Jenkins

subject: [Wikitech-l] Rollback for trusted users

body:
>From Gregory Maxwell in the "[Wikitech-l] User block changes" thread:
> 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.

I agree. OT (hence the subject name change), but related to this
general principle of just getting out of the way of people that are
fundamentally sensible:

Something that seems a bit strange to me is rollback. The current
situation I believe is that "Admins have a handy 'rollback' feature
which allows them to instant-revert changes from a user's
contributions page".

Sounds great, useful, and sensible. Everything apart from the "admins
only bit". Why stop at admins? Me personally, I'm not a wikipedia
admin (and currently the idea of yet another system that I'm an admin
of in some way holds zero appeal), but the ability to quickly undo
vandalism is useful, and could be given to far more users and be a big
net win for vandalism control. The whole "history -> click on last
edit minus one -> click edit -> type out 'revert' -> click save" cycle
gets very tedious and repetitive after a while.

<rant>
Why do we do this? Yes, there probably has to be some point at which
we start trusting people enough to do easy rollbacks, but "admin" is
too high a standard. If someone has a login, and has (say) >= 1000
edits, and has used the system for (say) >= 3 months, there's a pretty
good chance they can spot an anon committing vandalism on pages on
their watchlist. So why don't we make undoing this easier? Why don't
we help such people more, empower them more, and make what they can
already do just that bit easier and quicker? And I don't just mean me,
or just this specific user and that specific user, I mean all users
who cross a certain measurable threshold of trustworthiness and
commitment, should automatically be given rollback ability. Maybe
start the entry criteria high so that only a few people qualify
initially, and then gradually lower them whilst the gain from lowering
exceeds the pain from misuse - that would be fine, as long as it's a
systematic attempt to empower a whole category of trusted users, as
opposed to a user-by-user non-systematic approach.
</rant>

All the best,
Nick.


from_name: maru dubshinki

subject: [WikiEN-l] Persondata?

body:
On 7/11/06, Magnus Manske <magnus.manske at web.de> wrote:
> poore5 at adelphia.net wrote:
> > Hello Magnus,
> >
> > Could you explain a little more about how you plan to use the tool?
> >
> > I have some concerns about using it on Biographies of living people on Wikipedia-en. We have too much unverified information added to these article. I strongly believe that each article needs to be examined closely to verify the content meets our Wikipedia:BLP guidelines before it is added to a template.
> >
> Well, it can't run fully automatically, there has to be a user making
> the changes. I could prevent the tool from showing a template for people
> with no death date (=probably living;-) if there's great concern about
> that. Otherwise, the tool doesn't generate new data; it merely tries to
> extract the data already in the article and put it into a form that is
> more machine-readable.
>
> Magnus

Magnus: I'm glad to hear someone is working on the
extracting-persondata-from-article idea, which has been bruited about
for a while (but never actually acted on); but how exactly does it
work? Does it parse the first bolded run of text as the name, the
first two years as birth and death dates, and ditto for locations and
birth and death places, etc? Is it a AWB program, a pywikipedia (my
personal hope), a standalone program, what? I am rather interested in
such a program. Also, will it run on Linux and be Free?

~maru


from_name: Magnus Manske

subject: [WikiEN-l] Persondata?

body:
Are we prefering {{Persondata}} or {{Infobox biography}}?

Should they be merged, somehow?

I'm asking this because I'm writing a tool to generate Persondata from
article text as a copy&paste text. Can scan whole categories at once.

Magnus

-------------- 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/wikien-l/attachments/20060711/50498d7c/attachment.pgp


body:
On 7/11/06, Ray Saintonge <saintonge at telus.net> wrote:
> Erik Moeller wrote:
>
> >On 7/4/06, Anthony <wikilegal at inbox.org> wrote:
> >
> >
> >>It would also be nice
> >>to once and for all answer the question as to whether or not Wikimedia
> >>claims to be the "publisher" as the term is used in the GFDL.
> >>
> >>
> >
> >This is the first time this has come to my attention, and I would also
> >appreciate a response on this issue. The GFDL explicitly requires the
> >"publisher" to be credited in the history of modified versions
> >(section 4.I), though not in the title (indeed, it explicitly states
> >that the new publisher should be credited instead). It does not
> >provide a definition for the term "publisher." It is not our current
> >practice to require publisher credit to the WMF, though it is also
> >somewhat unclear when section 2, "Verbatim Copying" and when section
> >4, "Modifications" would apply; "Verbatim Copying" only places minimal
> >requirements on third parties.
> >
> >Does the WMF consider itself the publisher?
> >
> >I think it would be quite important to have a legally authoritative
> >interpretation of the GFDL as it applies to Wikimedia Foundation
> >project content. So far we've been basically "playing it by ear" when
> >it comes to GFDL compliance.
> >
> Whether WMF considers itself a publisher is a matter of policy.  A
> "legally authoritative interpretation" is a different matter, and no
> lawyer's interpretation in an opinion letter will be authoritative.
> Legal authority can only come from real court decisions.
>
Surely a statement from the chief executive of the WMF (who also
happens to be a lawyer), stating that they do not consider themselves
to be a publisher, would make it unlikely that a court would find
someone in violation of the GFDL due to the fact that they failed to
name the WMF as the publisher.

Alternatively, a statement from the chief executive of the WMF,
stating that they do consider themselves to be a publisher, would make
it unlikely that a court would find someone in violation of trademark
law due to the fact that they *did* name the WMF as the publisher.

Finally, even ignoring the legal issues, it'd be really nice to know
what the WMF *wants* people to do.

Whether or not Wikimedia is a publisher for the purposes of the CDA is
one thing - for that question you're right that a court ruling is the
only way to know.  But whether or not Wikimedia is a publisher *for
the purpose of the GFDL* is another matter altogether, since
presumably Wikimedia would be the only one with standing to sue over
neglecting to name it as the publisher of a GFDL work.

Anthony


subject: [Foundation-l] GFDL publisher credit

body:
Anthony wrote:

>On 7/4/06, Jeffrey V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
>
>
>>Erik Moeller wrote:
>>
>>
>>
>>>On 7/4/06, Anthony <wikilegal at inbox.org> wrote:
>>>
>>>
>>>
>>>
>>>>It would also be nice
>>>>to once and for all answer the question as to whether or not Wikimedia
>>>>claims to be the "publisher" as the term is used in the GFDL.
>>>>
>>>>
>>>>
>>>>
>>Under US Law, Wikimedia is the "publisher" because they create
>>"collections" of works of the
>>Wikipedia site and "publish" them to the world as XML dumps. Whether
>>electronic or in book form, they
>>are publishing. This being said, given the nebulous and undefined state
>>of internet IP law,
>>whether they are a publisher or not, there's no legal precedence to
>>determine liability, so at present
>>they are operating in an area of experimental law on the frontiers of
>>human knowledge.
>>
>>
>It's not just the fact that the distribution is taking place on the
>Internet, though.  The fact that everyone is an editor and every bit
>of content is a constant work in progress makes for a reasonable
>argument that these works are in fact not yet published at all.  The
>more I think about it the more I see this as the most sane
>interpretation.
>
If it has been made public it has been published.  The real question
here is _who_ did the publishing.

>Ultimately, it's grey area to the point where it would greatly improve
>matters if Wikimedia would make an official statement as to how it
>wants to be treated.  Does Wikimedia want to hold a copyright interest
>in works other than the logos?  Does it want to be considered a
>publisher *for the purposes of the GFDL*?  Any of the four
>combinations of answers are acceptable, but until one is chosen the
>content is that much less Free.  This is especially true when an
>employee of the foundation implies that playing it safe and assuming
>the foundation does hold a copyright interest and is a publisher is
>somehow a violation of trademark law.
>
Whatever position is taken by Wikimedia on this _must_ come from the
Foundation Board, and be backed up by a resolution.  Simply "playing
safe" is not a position but an avoidance of position.  It creates an
atmosphere of uncertainty.  What seems safe to me may not seem safe to
you, and vice versa.  Whatever the specific issue, we can then argue
about whether we are acting safely, and accomplish absolutely nothing.

If Wikimedia wants to hold a copyright interest inthis material it needs
to be ready to defend those copyrights in a serious way.  Having an
employee make ad-hoc, arbitrary and speculative pronouncements on the
law without a clear policy from the Board to back it up probably puts
the entire project into greater peril than the obvious silliness of the
more ignorant copyright violators.

Ec


subject: [Foundation-l] GFDL publisher credit


subject: [WikiEN-l] Persondata?

body:
Kirill Lokshin schrieb:
> On 7/11/06, Magnus Manske <magnus.manske at web.de> wrote:
>
>> Are we prefering {{Persondata}} or {{Infobox biography}}?
>>
>> Should they be merged, somehow?
>>
>> I'm asking this because I'm writing a tool to generate Persondata from
>> article text as a copy&paste text. Can scan whole categories at once.
>>
>
> One ({{Persondata}}) is raw metadata, but is applicable to _all_
> biographies; the other ({{Infobox biography}}) is designed for display
> to users, but has been replaced in certain types of biographies
> (politicians, royalty, military leaders) with more specialized
> templates.
>
I'll stick to Persondata, then.
> Ideally, we could have a tool that would be able to parse at least the
> major infobox types and fill out the persondata fields; but I'm not
> sure how much work it would be, considering that there is a certain
> variation in how different infoboxes deal with particular data.
>
>
I've done raw text extraction for the German Personendaten. While the en
version is still experimental, it works OK in many cases:
http://tools.wikimedia.de/~magnus/persondata.php?category=1984_deaths

I could add popular infoboxes (any suggestions?) and German
Personendaten, if a de article exists.

Magnus

-------------- 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/wikien-l/attachments/20060711/5e0f9125/attachment.pgp


from_name: Lord Voldemort

subject: [WikiEN-l] Joke

body:
On 7/11/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
> http://en.wikipedia.org/wiki/Joke
>
> I removed the jokes.  Mikka reverted.  My reasoning:
> * no reliable sources for these being considered representative of the
> classes of joke discussed
> * this is about the concept of the joke, it is not [[List of jokes]]
> (and most especially not [[List of randomly selected and generally
> abysmal jokes]])
> * several are gratuitously offensive.  It should be possible to read
> the article on joke, be told that racist jokes exist, but not be
> subjected to them unless you visit a separate article
> * WP:NOT a joke book
> * cruft, cruft, cruft and more cruft.  Most are drive-bys.

Only truly notable jokes should be listed, IMO.  Chicken crossing the
road, etc. Otherwise, [insert everything you laid out above here].
And no, don't send them to Wikibooks, either, since I know that
suggestion was coming from someone. --LV


from_name: Andrew Gray

body:
On 11/07/06, Ilmari Karonen <nospam at vyznev.net> wrote:
> As some of you may have noted, we now have a couple of new options to
> choose when blocking users.  Tim Starling, who implemented the feature,
> posted the following clarification on the wikitech-l list:
>
> Tim Starling wrote:
> > A couple of people asked me about interaction between various kinds of
> > blocks and block options, and indeed, in some cases the behaviour was
> > undefined or accidental. I've now implemented the following rules:
> >
> > * The "anon only" and "prevent account creation" options will be silently
> > ignored on username blocks.
> > * The precedence of blocks in cases of conflict, from highest to lowest, is:
> >    * Username block
> >    * Single IP block
> >    * Range block
> >    * Autoblock
> >
> > This holds regardless of the anon-only option. This means that anon-only
> > range blocks or IP blocks can be used to mitigate the effects of autoblocks
> > on shared IP addresses, because an anon-only block will allow logged in
> > users to edit regardless of the presence of a matching autoblock. This has a
> > potential to be counterintuitive -- unblocking someone's IP can in fact
> > cause them to be blocked. But I thought it was better than the other solutions.
>
> Given the above, would it now be advisable to block the entire AOL proxy
>   pool from editing by unregistered users?  This would have the side
> effect that AOL users would no longer be hit by random autoblocks.

It would also mean they wouldn't be continually bombarded by warning
messages... which is a great worry for a lot of them, judging by the
emails we get.

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


from_name: Simetrical

subject: [Wikitech-l] User block changes

body:
On 7/11/06, Tim Starling <t.starling at physics.unimelb.edu.au> wrote:
> * The precedence of blocks in cases of conflict, from highest to lowest, is:
>    * Username block
>    * Single IP block
>    * Range block
>    * Autoblock

Wouldn't it be more intuitive to just say "blocked" takes precedence
over "unblocked"?  I'm not clear on what the problem is with that,
although I'm pretty tired at the moment.  Certainly that's how every
other blocking system I know of (message board, IRC, etc.) works.  Of
course, IRC also has excepts, invites, and voices to stop range-blocks
from affecting regulars.

Do we actually need to worry about range-blocks affecting regulars,
though?  After all, range-blocks are almost always useful only to
target dynamic IPs, so there's no point exempting a specific IP from
the range; but even if there were, the range block could just be
broken up into a few smaller range blocks.  So unless there's an
additional problem, I'd just give blocked status precedence over
unblocked status.


from_name: Siebrand Mazeland

subject: [Commons-l] intelligence in flagging

body:
On a more general note: in my opinion an uploader is ALWAYS responsible for
correct and complete license and source information. It is not a duty for an
admin to go and get it when either is missing, nor should the Commons admin
chase al around the Wikimedia landscape to notify an uploader on his home
wiki(s).

It is the responsibility of admins to ensure no policy violations occur, to
notify users of possible violations and/or missing information and educate
users where needed.

Requiring admins to follow each and every link in search for information
regarding an image is definately not the way to go, in my opinion.

Cheers!

Siebrand

-----Oorspronkelijk bericht-----
Van: commons-l-bounces at wikimedia.org
[mailto:commons-l-bounces at wikimedia.org] Namens Platonides
Verzonden: dinsdag 11 juli 2006 13:00
Aan: commons-l at wikimedia.org
Onderwerp: Re: [Commons-l] intelligence in flagging

"stevertigo" wrote:
> This presents itself as a problem as Ive noticed a certain automation,
> and sadly a lack of intelligence,

Yes, you're right. That image was automatically flagged as no-license by
Orgullobot, so there's automation and bots are not very intelligent ;-)

The good notice is that nobody lost time flagging it, maybe it wasn't even
check by a human before you arrived. The uploader got a message but didn't
correct it.


subject: [WikiEN-l] Persondata?

body:
I would say that most of the very basic data persondata is concerned with is
largely correct. I have found that simple things like birth and death dates
are usually correct. However, since this tool is human mediated, it may be a
good opportunity to verify basic information provided by many of our
biographies.

On 11/07/06, poore5 at adelphia.net <poore5 at adelphia.net> wrote:
>
> ---- Magnus Manske <magnus.manske at web.de> wrote:
> > Kirill Lokshin schrieb:
> > > On 7/11/06, Magnus Manske <magnus.manske at web.de> wrote:
> > >
> > >> Are we prefering {{Persondata}} or {{Infobox biography}}?
> > >>
> > >> Should they be merged, somehow?
> > >>
> > >> I'm asking this because I'm writing a tool to generate Persondata
> from
> > >> article text as a copy&paste text. Can scan whole categories at once.
> > >>
> > >
> > > One ({{Persondata}}) is raw metadata, but is applicable to _all_
> > > biographies; the other ({{Infobox biography}}) is designed for display
> > > to users, but has been replaced in certain types of biographies
> > > (politicians, royalty, military leaders) with more specialized
> > > templates.
> > >
> > I'll stick to Persondata, then.
> > > Ideally, we could have a tool that would be able to parse at least the
> > > major infobox types and fill out the persondata fields; but I'm not
> > > sure how much work it would be, considering that there is a certain
> > > variation in how different infoboxes deal with particular data.
> > >
> > >
> > I've done raw text extraction for the German Personendaten. While the en
> > version is still experimental, it works OK in many cases:
> > http://tools.wikimedia.de/~magnus/persondata.php?category=1984_deaths
> >
> > I could add popular infoboxes (any suggestions?) and German
> > Personendaten, if a de article exists.
> >
> > Magnus
>
> Hello Magnus,
>
> Could you explain a little more about how you plan to use the tool?
>
> I have some concerns about using it on Biographies of living people on
> Wikipedia-en. We have too much unverified information added to these
> article. I strongly believe that each article needs to be examined closely
> to verify the content meets our Wikipedia:BLP guidelines before it is added
> to a template.
>
> Regards,
> Sydney Poore
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
Oldak Quill (oldakquill at gmail.com)


from_name: Brion Vibber

subject: [Wikitech-l] Rollback for trusted users

body:
Nick Jenkins wrote:
> Why do we do this? Yes, there probably has to be some point at which
> we start trusting people enough to do easy rollbacks, but "admin" is
> too high a standard. If someone has a login, and has (say) >= 1000
> edits, and has used the system for (say) >= 3 months, there's a pretty
> good chance they can spot an anon committing vandalism on pages on
> their watchlist. So why don't we make undoing this easier? Why don't
> we help such people more, empower them more, and make what they can
> already do just that bit easier and quicker?

I'm going to let you in on a little secret:

There's a user JavaScript tool that was developed some time ago which provides
about the same one-touch rollback capability for any user. Rollbacks of course
are nothing special, it's just a little convenience to automate the process,
which in a SoftSecurity fashion gives the interested Good Guys a tiny leg up
against random vandals.

We have the technical capability to add a rollback-only group. But all that
creates is another bottleneck: assigning and managing that permission.

The user JavaScript doohickey is something that people can and do manage
themselves with a little cut-and-paste.

Is it ideal? No. But by allowing the community to self-manage, it's more Wiki
than a top-down-administered permission group and probably gets used more than
such a group would.

-- 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/wikitech-l/attachments/20060711/d057f36d/attachment.pgp>


subject: [Commons-l] intelligence in flagging

body:
It does seem a little silly that people can upload images without a license
tag. This functionality could easily be added - perhaps any upload without a
tag selected from the drop down or an appropriate template in the summary
should not be able to be uploaded.

It would be nice to still allow people to select "I don't know what the
license is" so that those with more experience can help (particularly easy
for us in the case of old photographs).

On 11/07/06, Anthony <wikilegal at inbox.org> wrote:
>
> On 7/11/06, Siebrand Mazeland <s.mazeland at xs4all.nl> wrote:
> > On a more general note: in my opinion an uploader is ALWAYS responsible
> for
> > correct and complete license and source information. It is not a duty
> for an
> > admin to go and get it when either is missing, nor should the Commons
> admin
> > chase al around the Wikimedia landscape to notify an uploader on his
> home
> > wiki(s).
> >
> > It is the responsibility of admins to ensure no policy violations occur,
> to
> > notify users of possible violations and/or missing information and
> educate
> > users where needed.
> >
> > Requiring admins to follow each and every link in search for information
> > regarding an image is definately not the way to go, in my opinion.
> >
> In my opinion the way to go would be to use common sense.  If an image
> description says it's a crop of another image, looking at that image
> description would be a common sense thing to do.
>
> Of course, if common sense isn't required, and any image without a tag
> is immediately deletable without any further checks, then images
> shouldn't be allowed to be uploaded without tags in the first place.
>
> Anthony
> _______________________________________________
> Commons-l mailing list
> Commons-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/commons-l
>

--
Oldak Quill (oldakquill at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/commons-l/attachments/20060711/5b8fad8f/attachment.htm


from_name: poore5 at adelphia.net

subject: [WikiEN-l] Persondata?

body:
---- Magnus Manske <magnus.manske at web.de> wrote:
> poore5 at adelphia.net wrote:
> > Hello Magnus,
> >
> > Could you explain a little more about how you plan to use the tool?
> >
> > I have some concerns about using it on Biographies of living people on Wikipedia-en. We have too much unverified information added to these article. I strongly believe that each article needs to be examined closely to verify the content meets our Wikipedia:BLP guidelines before it is added to a template.
> >
> Well, it can't run fully automatically, there has to be a user making
> the changes. I could prevent the tool from showing a template for people
> with no death date (=probably living;-) if there's great concern about
> that. Otherwise, the tool doesn't generate new data; it merely tries to
> extract the data already in the article and put it into a form that is
> more machine-readable.
>
> Magnus

I thought you said something about doing whole categories. I got the impression that the tool would convert a whole group of articles, over course one after another.

Who would use the tool? Does a human need to verify each fact (not sure of a better word) before it goes into the template?

If not I'm concerned about some false information slipping through.

Otherwise it sounds great.  : - )

Take care,
Sydney aka FloNight


subject: [WikiEN-l] Should we block unregistered AOL users?

body:
Regardless of the fate of AOL users. It is great for Tor users who are
already blanket blocked due to abuse of the proxies.

On 11/07/06, Ilmari Karonen <nospam at vyznev.net> wrote:
>
> Angela wrote:
> > On 7/12/06, Ilmari Karonen <nospam at vyznev.net> wrote:
> >
> >>Given the above, would it now be advisable to block the entire AOL proxy
> >>  pool from editing by unregistered users?  This would have the side
> >>effect that AOL users would no longer be hit by random autoblocks.
> >
> > AOL have agreed to set XFF headers for Wikimedia sites, so this won't
> > be necessary. However, that was a few weeks ago now and I'm not aware
> > of it having been implemented yet. I'll follow up and see if there's
> > any response. I suggest holding off on the blocks for a while longer
> > to see whether we can avoid this.
>
> That's *great* news!  I suppose Tim is also in on this, given that he
> maintains the trusted XFF list?
>
> That said, it might still make sense to block anon editing from the
> proxies until this is implemented, assuming we feel the blocking is a
> good idea at all.  Once the XFF feature has been enabled on both ends,
> those blocks will then (as far as I understand the system) simply stop
> having any effect.
>
> As an implementation detail, if we do this, we should probably set up a
> helpful template and use it in the range block summaries.  That way the
> users affected by the blocks will know exactly what's going on and what
> to do.
>
> --
> Ilmari Karonen
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
Oldak Quill (oldakquill at gmail.com)


from_name: peter green

subject: [Commons-l] intelligence in flagging

body:
>It does seem a little silly that people can upload images without a license tag.
>This functionality could easily be added - perhaps any upload without a tag
>selected from the drop down or an appropriate template in the summary should
>not be able to be uploaded.
at first that sounds like a nice idea but it has two problems.

1: very often for large groups of images from the same (particularlly PD) source a new tag is created both to save the uploader time and to provide a usefull sorting of such images. Any mechanism like this would put a lot of beuracry in the

2: we will most likely end up with a lot of people picking tags at random which is a much harder behaviour to deal with than people not tagging at all.


subject: [Commons-l] intelligence in flagging

body:
These two points seem very clear now that you mention them. I can't really
see a compromise between my proposal and the situations you mention. Such is
brainstorming!

On 11/07/06, peter green <plugwash at p10link.net> wrote:
>
> >It does seem a little silly that people can upload images without a
> license tag.
> >This functionality could easily be added - perhaps any upload without a
> tag
> >selected from the drop down or an appropriate template in the summary
> should
> >not be able to be uploaded.
> at first that sounds like a nice idea but it has two problems.
>
> 1: very often for large groups of images from the same (particularlly PD)
> source a new tag is created both to save the uploader time and to provide a
> usefull sorting of such images. Any mechanism like this would put a lot of
> beuracry in the
>
> 2: we will most likely end up with a lot of people picking tags at random
> which is a much harder behaviour to deal with than people not tagging at
> all.
>
> _______________________________________________
> Commons-l mailing list
> Commons-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/commons-l
>

--
Oldak Quill (oldakquill at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/commons-l/attachments/20060711/17feda88/attachment.htm


subject: [WikiEN-l] Joke

body:
---- Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
> http://en.wikipedia.org/wiki/Joke
>
> I removed the jokes.  Mikka reverted.  My reasoning:
> * no reliable sources for these being considered representative of the
> classes of joke discussed
> * this is about the concept of the joke, it is not [[List of jokes]]
> (and most especially not [[List of randomly selected and generally
> abysmal jokes]])
> * several are gratuitously offensive.  It should be possible to read
> the article on joke, be told that racist jokes exist, but not be
> subjected to them unless you visit a separate article
> * WP:NOT a joke book
> * cruft, cruft, cruft and more cruft.  Most are drive-bys.
>
> Guy (JzG)

Agree all around.

Sydney


subject: [Wikitech-l] User block changes

body:
On 7/11/06, Brion Vibber <brion at pobox.com> wrote:
> Er, yes -- that's the whole issue. Blocks of ranges such as big ISPs frequently
> caught regulars who are stuck with that ISP.

But that's not helped by the new code anyway, except that you can
allow registered users from that ISP to edit (which is independent of
blocking precedence).  Tim mentioned autoblocks, which apparently
always affect even logged-in users, as his reason for adding the
precedence.

Perhaps a more intuitive solution would be to enable the anon only and
no account creation options for username blocks, and just apply them
to autoblocks?  It's slightly less powerful, in that if someone from a
shared IP made a bunch of sleeper accounts before getting blocked they
could use those unless you blocked other users of the IP, but in such
a (probably uncommon) case blocking the clones wouldn't be hard and
would probably be desirable.  Plus, not autoblocking preregistered
users by default has the advantage of avoiding the autoblock in the
first place, rather than allowing it to be lifted more easily.


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

body:
Interesting idea!

Is there *maybe* there some kind SQL injection attack?

E.g. I saved an evil data source like so:
=======================================
<data table="Companies'; insert into user set user_id = '9999',
user_name = 'Nickj2', user_email = 'address at name'; insert into
user_groups set ug_user = '9999', ug_group = 'sysop'; insert into
user_groups set ug_user = '9999', ug_group = 'bureaucrat'; "
template="Infobox company">
name=Microsoft
founded=1492
revenue=$8
</data>
=======================================

And then the all pages list from the table namespace only showed the 3
test tables:
http://www.kennel17.co.uk/testwiki/index.php?title=Special%3AAllpages&from=&namespace=100

So that says to me that *maybe* it did something (otherwise I would
expect the test 3 + this one).

Of course, I then tried to use the "reset and email me my password"
function to get admin rights to see if it was working, but there was
no such user :-(

> www.kennel17.co.uk/testwiki

I'm probably going to regret asking this, but with a hostname like
that I just have to ask: What happened to kennels numbered one through
sixteen inclusive?

All the best,
Nick.


from_name: Ilmari Karonen

subject:
[WikiEN-l] Should we block unregistered AOL users? (was:
 [Wikitech-l] User block changes)

body:
As some of you may have noted, we now have a couple of new options to
choose when blocking users.  Tim Starling, who implemented the feature,
posted the following clarification on the wikitech-l list:

Tim Starling wrote:
> A couple of people asked me about interaction between various kinds of
> blocks and block options, and indeed, in some cases the behaviour was
> undefined or accidental. I've now implemented the following rules:
>
> * The "anon only" and "prevent account creation" options will be silently
> ignored on username blocks.
> * The precedence of blocks in cases of conflict, from highest to lowest, is:
>    * Username block
>    * Single IP block
>    * Range block
>    * Autoblock
>
> This holds regardless of the anon-only option. This means that anon-only
> range blocks or IP blocks can be used to mitigate the effects of autoblocks
> on shared IP addresses, because an anon-only block will allow logged in
> users to edit regardless of the presence of a matching autoblock. This has a
> potential to be counterintuitive -- unblocking someone's IP can in fact
> cause them to be blocked. But I thought it was better than the other solutions.

Given the above, would it now be advisable to block the entire AOL proxy
  pool from editing by unregistered users?  This would have the side
effect that AOL users would no longer be hit by random autoblocks.

(If you're unfamiliar with the AOL proxies and why they're a problem for
us, please see [[Wikipedia:Advice to AOL users]] and [[Wikipedia:Dealing
with AOL vandals]], plus the associated talk pages.)

--
Ilmari Karonen


from_name: Mark Clements (HappyDog)

body:
Nick Jenkins <nickpj at ...> writes:

> Interesting idea!
>
> Is there *maybe* there some kind SQL injection attack?
>
> E.g. I saved an evil data source like so:
> =======================================
> <data table="Companies'; insert into user set user_id = '9999',
> user_name = 'Nickj2', user_email = 'address at name'; insert into
> user_groups set ug_user = '9999', ug_group = 'sysop'; insert into
> user_groups set ug_user = '9999', ug_group = 'bureaucrat'; "
> template="Infobox company">
> name=Microsoft
> founded=1492
> revenue=$8
> </data>
> =======================================
>
> And then the all pages list from the table namespace only showed the 3
> test tables:
>
http://www.kennel17.co.uk/testwiki/index.php?title=Special%3AAllpages&from=&namespace=100
>
> So that says to me that *maybe* it did something (otherwise I would
> expect the test 3 + this one).

This is expected behaviour under the current version.  Table pages are not
automatically created by the addition of data, only when a definition is
added.  If you enter the following wiki code to a normal page:

> <data table="CompaniesNew">
> name=Microsoft
> founded=1492
> revenue=$8
> </data>
> [[Table:CompaniesNew]]

then the link to Table:CompaniesNew would be red.  Following the link will
take you to edit the definition, but removing the &action=edit from the URL
will show you the data.  The table will not appear in AllPages until you
save it.

My plan is to move the data from the bottom of the definition page, to a new
'data' tab, so even if you go to a red-linked definition it will be easy to
click 'data' to view the data it contains.  I also plan to add a special
page called 'Missing tables' or similar.  The two of these should solve the
problem, but if there are any better ideas out there then I'd be interested
to hear them.

> Of course, I then tried to use the "reset and email me my password"
> function to get admin rights to see if it was working, but there was
> no such user :-(

The code is (I hope...) injection safe.  Not FULLY tested, but the obvious
cases should be covered.  It certainly worked in this case :)

> > www.kennel17.co.uk/testwiki
>
> I'm probably going to regret asking this, but with a hostname like
> that I just have to ask: What happened to kennels numbered one through
> sixteen inclusive?

If you got to www.kennel17.co.uk, you can see that Kennels 16 and 18 are in
bad need of repair.  The other kennels (in the background or out of shot)
aren't up to much either, I'm afraid, so that's why I plumped for #17... :-)

Thanks for the feedback.

--
Mark Clements (HappyDog)


subject: [WikiEN-l] Persondata?

body:
poore5 at adelphia.net wrote:
> Hello Magnus,
>
> Could you explain a little more about how you plan to use the tool?
>
> I have some concerns about using it on Biographies of living people on Wikipedia-en. We have too much unverified information added to these article. I strongly believe that each article needs to be examined closely to verify the content meets our Wikipedia:BLP guidelines before it is added to a template.
>
Well, it can't run fully automatically, there has to be a user making
the changes. I could prevent the tool from showing a template for people
with no death date (=probably living;-) if there's great concern about
that. Otherwise, the tool doesn't generate new data; it merely tries to
extract the data already in the article and put it into a form that is
more machine-readable.

Magnus


body:
Angela wrote:
> On 7/12/06, Ilmari Karonen <nospam at vyznev.net> wrote:
>
>>Given the above, would it now be advisable to block the entire AOL proxy
>>  pool from editing by unregistered users?  This would have the side
>>effect that AOL users would no longer be hit by random autoblocks.
>
> AOL have agreed to set XFF headers for Wikimedia sites, so this won't
> be necessary. However, that was a few weeks ago now and I'm not aware
> of it having been implemented yet. I'll follow up and see if there's
> any response. I suggest holding off on the blocks for a while longer
> to see whether we can avoid this.

That's *great* news!  I suppose Tim is also in on this, given that he
maintains the trusted XFF list?

That said, it might still make sense to block anon editing from the
proxies until this is implemented, assuming we feel the blocking is a
good idea at all.  Once the XFF feature has been enabled on both ends,
those blocks will then (as far as I understand the system) simply stop
having any effect.

As an implementation detail, if we do this, we should probably set up a
helpful template and use it in the range block summaries.  That way the
users affected by the blocks will know exactly what's going on and what
to do.

--
Ilmari Karonen


from_name: Anthony

subject: [Commons-l] intelligence in flagging

body:
On 7/11/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> On 12/07/06, Oldak Quill <oldakquill at gmail.com> wrote:
> > It would be nice to still allow people to select "I don't know what the
> > license is" so that those with more experience can help (particularly easy
> > for us in the case of old photographs).
>
> 1 in maybe 100 would be such nice cases, the other 99 would be
> explaining that random stuff off the web is copyrighted. I would
> prefer people find out the license BEFORE uploading. It would save a
> lot of work. We have a [[commons:Help desk|]] for this purpose.
>
Using [[commons:Help desk]] certainly isn't very easy either, though.
And clicking the delete button isn't very much work.

It would be nice if there was some temporary place that people could
upload images which they weren't really sure about.  It could be kept
separate from the other images so articles couldn't include them.  Of
course getting the copyright paranoid group to agree to this is
probably impossible.

Anthony


from_name: Brad Patrick

subject: [Foundation-l] GFDL publisher credit

body:
On 7/11/06, Ray Saintonge <saintonge at telus.net> wrote:
>
> Anthony wrote:
>
> >On 7/4/06, Jeffrey V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
> >
> >>Erik Moeller wrote:
> >>
> >>>On 7/4/06, Anthony <wikilegal at inbox.org> wrote:
> >>>
>

"Having an
employee make ad-hoc, arbitrary and speculative pronouncements on the
law without a clear policy from the Board to back it up probably puts
the entire project into greater peril than the obvious silliness of the
more ignorant copyright violators."

For the record, Ray, Jeff, Eric and Anthony are not employees of the
Foundation.

I am, and I hope you do not have a problem with the idea of a paid general
counsel having as one of his primary responsibilities the generation of
'speculative pronouncements on the law.'  That is rather the point.  My
client, my ethical obligation, and the recipient of my professional legal
advice is the Board.  It's my bar card on the line.  It is not my job to wax
eloquent on the law for the sake of making people on a listserv have more to
rant about.

Thanks for including the word "probably" in the statement above, btw.  I'd
hate to think you were taking a position without leaving yourself rhetorical
wiggle room.  That would probably' be silly as well.

--
Brad Patrick
General Counsel & Interim Executive Director
Wikimedia Foundation, Inc.
bradp.wmf at gmail.com
727-231-0101


subject: [Foundation-l] GFDL publisher credit


subject: [Foundation-l] GFDL publisher credit

body:
On 7/11/06, Ray Saintonge <saintonge at telus.net> wrote:
> Anthony wrote:
> >It's not just the fact that the distribution is taking place on the
> >Internet, though.  The fact that everyone is an editor and every bit
> >of content is a constant work in progress makes for a reasonable
> >argument that these works are in fact not yet published at all.  The
> >more I think about it the more I see this as the most sane
> >interpretation.
> >
> If it has been made public it has been published.  The real question
> here is _who_ did the publishing.
>
{{citationneeded}}


subject: [Foundation-l] GFDL publisher credit


from_name: mboverload

body:
If this works, this is literally a new era of wikipedia vandal-fighting.

On 7/11/06, Angela <beesley at gmail.com> wrote:
>
> I've just had confirmation that this should be working. From AOL this
> morning:
>
> > I have just now added all the domains you have listed below to our
> > config to get XFF headers. You should see them sometime later today when
> > the process is finished updating all of our web proxies.
>
> Thanks to Jim Sheafer for setting this up, and to Mike Wise for
> putting me in contact with him.
>
> Hopefully this means you can now block one AOL user without affecting
> another one.
> http://en.wikipedia.org/wiki/Wikipedia:Advice_to_AOL_users should
> probably be updated when we're sure this is working.
>
> Angela.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>