from_name: Daniel Arnold

subject: [Foundation-l](volunteer) job position : Ombudsperson	checkuser (or checkuser Ombudsperson or whatever)

body:
Am Mittwoch, 21. Juni 2006 16:07 schrieb Robert Scott Horning:
> I've heard a lot of fear mongering and what I percieve to be unwarrented
> fears about abuses to checkuser actions.  Can you give some clear
> examples of what have been percieved as abuses of those with checkuser
> privileges, at least types of problems that have happened as a matter or
> practice?

I did never take the time investigating the background of any checkuser of
others. I just noticed some statistics:

en.wikipedia (and some other smaller projects as well) have overproportional
heavy use of CheckUser. de.wikipedia (the second largest one, which has like
en.wikipedia many trolls but probably has different approaches keeping them
down, which naturally also have their specific positive and negative side
effects) has no checkuser trace in the logfiles (a developer can make a
Checkuser directly at the servers without Checkuser logfile traces but
nonetheless it were only a few in case of de.wikipedia).

> I know I am speaking from an apparent minority opinion on this mailing
> list, but I fail to see what real damage is happening from simply
> looking up the IP address of a user.

My concerns are as follows: A Checkuser of an IP from let us say China or
Saudi Arabia can have *serious* impact if these informations come into the
wrong hands although the probability of a worst case scenario is quite low.

So if en.wp makes heavy regular use of checkuser why shouldn't zh.wp and ar.wp
do the same as well (and logfile data of a palestinian on he.wp is also a
potentially serious matter for example)? It is a question of caution and role
model function of en.wp.

So I don't suggest to en.wp stop checkuser but use it more seriously. Just
block an IP or recently created vandal account unilaterally if you think it's
a sock puppet without investigating deeper (hey you're admin you have to *be
bold* sometimes) and only perform a checkuser afterwards in case there was a
real demand from several third persons.

That way you also avoid creating a large bueraucracy on blocking of small
fishes like IPs and short lived accounts and have more time for far more
important matters.

Checkuser should mainly be a weapon against sock puppets of people that are
involved deeper in the project (let's say several accounts of a single person
that abuses them for quite some time in a sophisticated way with a mixture
out of valid and POV edits).

Just my 2 cents...

Arnomane


list: wikimedia-l

source: pipermail-mbox


list: wikien-l

from_name: Erik Moeller

subject: [WikiEN-l] "the experiment" - did it work?

body:
On 6/21/06, Ian Woollard <ian.woollard at gmail.com> wrote:
> The more complicated you make it, the more unintended consequences there
> are likely to be, the more failure modes there are and the more unwieldy it gets
> to edit the Wikipedia.

*cough*
parametrized templates
mathematical expressions
embedded LaTeX
advanced image thumbnail syntax
magic words
EasyTimeline
wiki table syntax
commons integration
watchlists
categories
localization (to the point of pluralization algorithms for particular languages)
...

MediaWiki is a far cry from being a simple wiki engine like the little
Perl script that Wikipedia used to run on in 2001. Over the years, we
have added capabilities to give users more and more power, and to let
machines take over routine tasks. Some of the above solutions are
mature, others have a lot of room for optimization and simplification.

But do not confuse a simple user experience with a simple
implementation. Making things nice and smooth for the user is often a
lot of work for the developer.

I distinguish the problem of quality review from the problem of
patrolling and anti-vandalism measures. I agree with you that
patrolling and anti-vandalism tools (of which some delayed page
protection mechanism may be one) need not be particularly complex to
work well. The goal of quality review, for me, is to say that a
revision of an article
- has been thoroughly fact-checked
- is deemed to be neutral by the community
- has been checked for copyright violations or other legal issues
- meets stylistic and other formal criteria
- etc.

In essence, I am talking about _positive_ assertions about the
article's quality, rather than the _negative_ assertions for which we
use tagging. While individual tagging works well to make a negative
assertion (if you are wrong, it doesn't do much harm), for a positive
assertion, you need to have community verification and consensus.
Vandalism patrolling, meanwhile, is not about _assertions_ at all --
it is about intervention. It's a different class of problem
altogether.

WP:FAC is a good process in the quality review category, if I may say
so myself, but its scalability is very poor. This is in part because
it expects every editor to know everything. It does not accommodate me
going into a nomination and saying, for instance: "I've done a
copyright check on this article." "This article meets the MoS
criteria." There is no reward in doing so -- the article may still
fail the full review. The process of discussion is lengthy, the
procedure complex, and the standards of quality are very high.

WP:FAC also does not do changeset-specific review. It reviews on the
basis of the whole article only. This works well for the initial
nomination, but by the time the article has passed, it has often
changed significantly already. In other words, the quality of the
assertions we make about articles is dubious, and our ability to cope
with the rapid rate of changes limited.

I am interested in giving users power tools to enable them to review
articles rapidly and bring their skills to the fore. Furthermore, I
would like us to provide machine-readable metadata that allows
external re-users of our content, as well as scripts we use to develop
distributable versions thereof, to make use of the assertions that
have been made through these tools.

This is, I repeat, a complex problem. However, the solution needs not
interfere at all with the regular editing process. We can experiment
with different models alongside normal editing -- those users who do
not click the relevant buttons will never be bothered by any
review-related functionality (except, perhaps, for some visible
metadata on the article itself). I do not believe in models where
anonymous users are only shown reviewed content, for instance. The
content that is shown when you visit a particular URL should always be
the same for all users.

You are right that, if we succeed, the solution will be very neat and
simple from a user's point of view. But it will be the result of a
very long process of debating, thinking, and experimenting, and the
implementation itself may well be very complex.

Erik


from_name: Ilya N.

subject: [WikiEN-l] newbie culture

body:
Being here for 3 years (and I'm pretty sure you've been here for about that
long), I've never seen a 'new generation' start doing something like this.

On 6/16/06, geni <geniice at gmail.com> wrote:
>
> On 6/16/06, Mark Gallagher <m.g.gallagher at student.canberra.edu.au> wrote:
> >
> >  From the famous Herostratus RfA: "There's no excuse to not use the
> > warning templates for users vandalising, especially IP users."
> >
> > And the perpetrator of this idiotic statement is, according to his
> > userpage, an RC patroller (although, blessedly, not apparently a member
> > of CVU).
> >
> > Once we were worried about the newbie contingent getting so large that
> > new users were in fact starting to consider themselves old hands and
> > influencing Wikipedia (see: CVU admins, userbox fiasco).  It's gone
> > beyond that, now: these days, the newbies are offering *advice* to more
> > clueful users, and expecting it to be taken.
>
> So in other words the next generation is comeing through. Experence
> suggests that complianing that "It wasn't like that in my day" doesn't
> work too well.
>
>
> --
> geni
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
~Ilya N. (Now with 2% Juice)
http://ilya.nepfamily.com (My website; DarkLordFoxx Media)
http://en.wikipedia.org/wiki/User:Ilyanep (on Wikipedia)
http://www.wheresgeorge.com - Track your money's travels.


from_name: Andrew Gray

body:
On 21/06/06, Mark Wagner <carnildo at gmail.com> wrote:
> On 6/21/06, Andrew Gray <shimgray at gmail.com> wrote:
> >
> > I have seen a graph of number-of-articles-on-AFD over time, but damned
> > if I can find it. Does anyone else remember it?
>
> I've seen graphs demonstrating that proposed deletion greatly reduced
> the load on AfD, but I haven't seen anything from when anon article
> creation was disabled.

Aha! That'll have been it...

If I get the time I'll graph a few months. When was anon creation stopped?

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


from_name: geni

subject: [WikiEN-l] Oversight log

body:
On 6/21/06, Sam Korn <smoddy at gmail.com> wrote:
> Now, we cannot do this like an RFA election, as there is potentially
> sensitive information.

How were arbcom elected?

In any case the presence of sensitive information would be the least
of your problems. The issue that the odds of the communirty passing
anyone are pretty minimal would likely be the real headache.

--
geni


list: foundation-l

from_name: Nathan Reed

subject: [Foundation-l] New privacy policy

body:
Excellent -- thank you. Reading the policy, I find:

"It is the policy of Wikimedia that personally identifiable data collected
in the server logs, or through records in the database via the CheckUser
feature, may be released by the system administrators or users with
CheckUser access, in the following situations:"

Does this mean that personally identifiable information may be released by
users with CheckUser permissions? For example, is it permissible for me to
release the actual IP address of a vandal to the general public? I'm not
sure, but this may not be a good thing.

I can understand using the information for IP blocks, but perhaps the
release of the information should not be so broad in these cases. Or, maybe
I'm tired, have failed to comprehend the policy completely, and have missed
something.. :D

-N.

On 6/21/06, Anthere <Anthere9 at yahoo.com> wrote:
>
>
> http://wikimediafoundation.org/w/index.php?title=Privacy_policy&oldid=14088
>
> may be found here.
>
> Please, spread the word that all the translations in various languages
> should be updated. Thanks in advance.
>
> Ant
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

--
Nathan Reed
nathanreed at gmail.com


subject: [Foundation-l] New privacy policy


subject: [WikiEN-l] New York Times article

body:
On 6/21/06, Jimmy Wales <jwales at wikia.com> wrote:
> I think that the first is true, and if not we should seriously look at
> why not.  I think that there is no reason for the second to be true.
>

There is. Long term semi protection really only hits a very small
number of subjects. The number of subjects that enough people feel
strong about to cause a problem is unlikely to increase.

> I also think that a serious analysis should not look at the raw number
> of articles (the site is a lot bigger than a year ago, so there should
> be a lot more of everything) but both percentages of articles, and also
> percentages of articles weighted by pageviews and/or edit frequency.

We don't have pageview data.

--
geni


from_name: Sam Korn

subject: [WikiEN-l] Oversight log

body:
On 6/21/06, geni <geniice at gmail.com> wrote:
> How were arbcom elected?

I'm not sure.  I myself was elected, and still don't quite know how.

> In any case the presence of sensitive information would be the least
> of your problems. The issue that the odds of the communirty passing
> anyone are pretty minimal would likely be the real headache.

Oh aye, there's that too...

--
Sam


from_name: Kelly Martin

subject: [Foundation-l] New privacy policy

body:
On 6/21/06, Nathan Reed <nathanreed at gmail.com> wrote:
> Excellent -- thank you. Reading the policy, I find:
>
> "It is the policy of Wikimedia that personally identifiable data collected
> in the server logs, or through records in the database via the CheckUser
> feature, may be released by the system administrators or users with
> CheckUser access, in the following situations:"
>
> Does this mean that personally identifiable information may be released by
> users with CheckUser permissions? For example, is it permissible for me to
> release the actual IP address of a vandal to the general public? I'm not
> sure, but this may not be a good thing.
>
> I can understand using the information for IP blocks, but perhaps the
> release of the information should not be so broad in these cases. Or, maybe
> I'm tired, have failed to comprehend the policy completely, and have missed
> something.. :D

We do have that authority, but we rarely use it.  Normally the only
way we would release an IP address would be in the context of placing
an IP block (or range block) of a vandal, which implicitly publicizes
the IP address to user interrelationship.

Kelly


subject: [Foundation-l] New privacy policy


from_name: Fastfission

subject: [WikiEN-l] A very interesting recent "fair use" case ruling

body:
Graham v. Dorling Kindersley Limited (decided May 9, 2006, U.S. Court
of Appeals Second Circuit), the ruling is worth reading in its
entirety: http://www.lessig.org/blog/archives/05-2514-cv_opn.pdf

It is a very interesting case and I find it very encouraging. The most
relevant aspects in respects to Wikipedia seem to me (non-lawyer that
I am) to be:

1. That moving a work into a very different context seems to be
considered transformative (i.e. from "expressive use of images on
concert posters" into a "biographical work"). Does moving an image
into an "encyclopedic work" make it "transformatively different"?
Under the court's argumentation here, almost certainly (accompanying
the images with textual material and creating something substantially
different as a whole than the original).

2. The Court takes the Kelly v. Arriba Soft Corp. and uses it to say
that reduced size reproductions of posters (or photos, presumably)
counts as using "less" of a work. That's a great thing to have ruled
somewhere, because otherwise the Kelly v. Arriba Soft left open a lot
of questions in that respect (i.e. since it was only for a search
engine and only dealt with very small thumbnails). The court's ruling
basically justifies our current policy in regards to size, that it
should be the smallest size possible in order to permit the
transformative purpose (in our case, to illustrate the article
appropriately).

Pending discussion, this would seem to me to point towards two
directions in policy: make more firm the "reduced size" requirement,
and liberalizing some aspects on how images are used in articles (I
would still rule against galleries and using them in lists for the
most part, but their use in relevant articles accompanying relevant
text would seem pretty assured to be transformative). Of course this
is not the end of the show (one court ruling does not determine
everything, but it does point to some relevant guidelines), but it
does give more confidence in certain assertions in respect to policy.

Other intepretations, thoughts, etc. on how/whether to use this to
guide any of our policies would be greatly appreciated.

FF


list: wikipedia-l

from_name: Derek Ross

subject: [Wikipedia-l] Wikipedia-l Digest, Vol 35, Issue 12

body:
Our own article on Literate programming on en wikipedia...

    http://en.wikipedia.org/wiki/Literate_programming

...has had a link to that excellent wiki site since late April.

Cheers
Derek

----- Original Message ----

From: "Erik Moeller" <eloquence at gmail.com>
Subject: [Wikipedia-l] Literate Programs wiki
To: wikipedia-l at wikimedia.org,    "Wikimedia textbook discussion"
    <textbook-l at wikimedia.org>
Message-ID:
    <b80736c80606182003r80f85e6vdc471110d7764f51 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

A very interesting wiki I just discovered:
http://en.literateprograms.org/LiteratePrograms:Welcome

<Snip>

Erik


from_name: Fred Bauder

subject: [WikiEN-l] Oversight log

body:
The problem is that what we are removing is stuff like personal
information or libelous statements that we really do want to vanish
and not be repeated internally.

Fred

On Jun 21, 2006, at 10:07 PM, James wrote:

> The suitable initial group seems clear enough: every administrator.
>
> Beyond that, the censored log should be available to everyone.
> Administrators often have more than enough to do and any assistance
> non-administrators can do in the way of oversight is a good thing.
>
> Removing the page isn't close to sufficient - it conceals what is
> perhaps the most significant part of what is being overseen: who is
> doing what, where and still concealed from most, why.
>
> It's worth remembering that a few million pages with things not
> vanishing completely have not brought the encyclopedia or Foundation
> down. Making sure we have ample oversight so that people actually look
> hard at what is being done and mention problems is important to our
> process.
>
> Without broad oversight, the capability to make thing silently vanish
> should also be vanishing.
>
> James Day
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


list: commons-l

from_name: Brianna Laugher

subject: [Commons-l] Creative Commons logos up for deletion, again

body:
On 21/06/06, Petr Kadlec <petr.kadlec at gmail.com> wrote:
> > So what are the chances of
> > (a) getting a technical fix so that these images link to the required
> > CC license, in every use on every WM wiki? (then we are compliant)
>
> Note that this is partially possible even now, using CSS. See
> [[Template:Click]].

The number of disclaimers and warnings on that template do not suggest
to me that we should use that as a solution on a quite decent
proportion of our pages. That's a hack, not a technical fix. :P

Brianna


from_name: Jimmy Wales

subject: [WikiEN-l] New York Times article

body:
Steve Bennett wrote:
> These are reasonable questions. Jimbo implies that if P(t) is the
> number of protected articles at time t, and S(t) is the proportion of
> semi-protected articles, then:
> P(now) << P(a year ago)
> That is, that full protection on the whole has greatly decreased. But also that:
>  P(now) + S(now) <= P(a year ago)
> That is, that the total amount of articles off-limits to newbies has
> not increased.

I think that the first is true, and if not we should seriously look at
why not.  I think that there is no reason for the second to be true.

I also think that a serious analysis should not look at the raw number
of articles (the site is a lot bigger than a year ago, so there should
be a lot more of everything) but both percentages of articles, and also
percentages of articles weighted by pageviews and/or edit frequency.

--
#######################################################################
#    Office: 1-727-231-0101       |  Free Culture and  Free Knowledge #
#    http://www.wikipedia.org     |     Building a free world         #
#######################################################################


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] New York Times article

body:
On Wed, 21 Jun 2006 21:46:04 +0100, geni <geniice at gmail.com> wrote:

>There is. Long term semi protection really only hits a very small
>number of subjects. The number of subjects that enough people feel
>strong about to cause a problem is unlikely to increase.

But before there was only protection, which was a blunt instrument and
caused significant pain.  Now there is sprotection which allows most
editors to go about their business so there is much less resistance to
its use; it is not a surprise that it is used to prevent spates of
short-term drive by vandalism, where previously we just put up with
the pain and kept reverting.

Even then articles like Safety, a constant target for IP vandalism, do
not remain protected for long because the protected log is watched by
a number of admins who make it their business to keep protection
periods down to sensible levels.

Guy (JzG)
--
http://www.chapmancentral.co.uk
http://en.wikipedia.org/wiki/User:JzG


from_name: Anthony DiPierro

body:
On 6/21/06, Bryan Derksen <bryan.derksen at shaw.ca> wrote:
> Anthony DiPierro wrote:
> > Until an article is approved, it can be deleted by *any* registered
> > user, there's no need to bother an admin to delete it.  Additionally,
> > if the article is not approved within X days, it is automatically
> > deleted.
>
> All good, IMO, except for the assumption of bad faith right at the end
> there. I don't see why the default has to be "delete". At that point the
> article's been hanging around for X days with a bomb strapped to its
> chest and not a single editor has seen fit to pull the trigger on it,
> suggesting that it probably isn't total trash. It may simply be a little
> questionable, which is something Wikipedia can work with.
>

I suppose it'd be enough to simply provide a list of articles which
sat in that limbo state for X days (or just a list ordered by oldest
first).  In that case I think it's pretty clear you're right - total
trash wouldn't stand a chance, unless it happened to get approved by a
registered editor (which could happen under an AfC type system as
well).


from_name: Delphine Ménard

subject: [Foundation-l] New privacy policy

body:
On 6/21/06, Anthere <Anthere9 at yahoo.com> wrote:
> http://wikimediafoundation.org/w/index.php?title=Privacy_policy&oldid=14088
>
> may be found here.
>
> Please, spread the word that all the translations in various languages
> should be updated. Thanks in advance.

shouldn't the translations bear some kind of a disclaimer that says
that only the English version is "official" and serves in court?

Just wondering.

Delphine

--
~notafish


subject: [Foundation-l] New privacy policy


body:
On 6/21/06, Fastfission <fastfission at gmail.com> wrote:
> It is a very interesting case and I find it very encouraging. The most
> relevant aspects in respects to Wikipedia seem to me (non-lawyer that
> I am) to be:
>
> 1. That moving a work into a very different context seems to be
> considered transformative (i.e. from "expressive use of images on
> concert posters" into a "biographical work"). Does moving an image
> into an "encyclopedic work" make it "transformatively different"?
> Under the court's argumentation here, almost certainly (accompanying
> the images with textual material and creating something substantially
> different as a whole than the original).
>
This part doesn't seem at all new.  "Transformative use" has long been
considered to include the context of the work, and not just whether or
not the work itself was altered.  Use of an artistic work for the
purposes of commentary, such as in an encyclopedia, would generally be
considered highly transformative.  Of course, note the qualification
"of an artistic work".  Taking a diagram from an educational textbook
and using it in an encyclopedia article to accomplish the same basic
purpose would be much less transformative.

> Pending discussion, this would seem to me to point towards two
> directions in policy: make more firm the "reduced size" requirement,
> and liberalizing some aspects on how images are used in articles (I
> would still rule against galleries and using them in lists for the
> most part, but their use in relevant articles accompanying relevant
> text would seem pretty assured to be transformative).

It all depends what the original purpose of the image is.  To make a
blanket statement that using an image in an encyclopedia with relevant
accompanying text is transformative is incorrect.  The original use
may very well have been in an encyclopedia with relevant accompanying
text.

This may sound obvious, but it's a mistake I think a lot of people
might make if the policy isn't clear about it.

FWIW, I still think Wikipedia should limit fair use to situations
where there is no other choice, i.e. commentary.  Even if it were
possible to guarantee that such a use would be fair use to all
potential reusers, that still doesn't help anyone outside the USA.

Anthony


from_name: Raphael Wegmann

body:
Jimmy Wales schrieb:
> geni wrote:
>
>>Problem is that kills one of wikipedia's main attractions.
>
>
> Not if done carefully, I think.  It may kill the main attraction to
> vandals and POV pushers, but that'd be a good thing. :)
>

Well, it might as well attract POV pushers to become
reviewers (censors?), so they can enforce their kind
of "quality protection".

--
Raphael


subject: [WikiEN-l] Oversight log

body:
On 6/21/06, Mark Wagner <carnildo at gmail.com> wrote:
> On 6/21/06, geni <geniice at gmail.com> wrote:
> > On 6/21/06, Sam Korn <smoddy at gmail.com> wrote:
> > > Now, we cannot do this like an RFA election, as there is potentially
> > > sensitive information.
> >
> > How were arbcom elected?
>
> The current batch?  The community selected a number of candidates, and
> Jimbo approved some of them.
>

It was a retorical question (I was heavily involved in setting up the
darn thing). I was trying to make the point that those who had got
oversightship due to arbcomness has been aproved by the community.
Admitedly in an election system which had it's final detials hashed
out in the minutes leading up to midnight. Incerdentaly could we have
some disscussion at
[[Wikipedia_talk:Arbitration_Committee/Elections/December_2006]] so we
don't have to do things that way again?

--
geni


from_name: Anthere

subject:
[Foundation-l] (volunteer) job position : Ombudsperson
 checkuser (or checkuser Ombudsperson or whatever)

body:
> On 6/21/06, James Hare <messedrocker at gmail.com> wrote:
>
>>Methinks it's a quest to be ready in case it actually happens. To express it
>>as an irritating buzzword, "proactive."

Arnomane criticized
 > So data security is very important and it should be made clear to all
 > ckeckusers but creating yet another ombudsman creates IMHO more
avoidable
 > meta-work (= work that does not improve a wikipedia article).
 > IMHO "CheckUser-abuse" is mainly an en.wikipedia problem and should be
 > adressed there locally in the main line.
 >
 > Arnomane

 >And Robert also questionned
 >If the abuse hasn't happened, where is the move to create such a
 >position in the first place?  A quest for political power?

-- Robert Scott Horning

Will that create more meta work ?
No. It will delegate meta work or move meta work to another person. I am
currently doing the job.

Is it a quest for political power ?
No. Given that *I* suggested this position, I can clarify that I am not
seeking more power.

Is it a quest to be ready in case it actually happens ?
It is not a quest. I sure hope abuse will *never* happen. But better to
be ready when it actually happens. And better that I drop doing the job
rather than doing it poorly.

Last point. I asked the board his opinion about the whole issue. Angela
suggested that we could update the privacy policy, which was pretty old
stuff since it did not take into account the checkuser tool ;-)
A new version was still pending. It is now adopted.

ant

> Also Anthere trying to offload work (currently she investigates all
> allegations of checkuser abuse herself).
>
> Kelly


from_name: Ian Woollard

body:
On 21/06/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> Until an article is approved, it can be deleted by *any* registered
> user, there's no need to bother an admin to delete it.  Additionally,
> if the article is not approved within X days, it is automatically
> deleted.

You would only want well established users to be able to delete
articles for some notion of 'well esablished'. Otherwise people will
register just for the joy of deleting other people's articles. If well
established users delete articles inappropriately, then the admins can
lock them out, and they can't do it anymore; so any problem is self
limiting.

> Anthony

--
-Ian Woollard

"Victory can be perceived but not created."


subject: [WikiEN-l] New York Times article

body:
On 6/21/06, Stan Shebs <shebs at apple.com> wrote:
> Empirically I find it to be true. It's amazing how many people
> will fight tooth and nail to get their POV into [[X]], while
> being oblivious to [[History of X]], [[X and Y]], [[X-Z effect]],
> [[list of Xes]], etc, all of which will have extensive material
> inconsistent with the wanted POV. (My unkind belief is that POV
> pushers are simply not smart enough to figure out that the
> encyclopedia has more than one article.)
>

Or they are smart enough to get as far as figureing out that most
people only look at the high profile articles.

--
geni


from_name: stevertigo

subject: [WikiEN-l] Oversight log

body:
TK:
"Unfortunately this means that the log itself has to
be kept private. Those people with oversight can view
it. No one else can."

What people seem to disagree with is with the notion
that the log "has to be kept private" due to someone's
claim of 'legally problematic revisions.' Is Google
facilitating the "damage of Starbucks' reputation" by
not removing "consumer whore" from its Image searches?

Understanding that legal systems are not always
reasonable, WM cant reasonably be responsible for
everything in the history of its articles. And to say
the risk is great is simply to court the clique of
privelege who think they can simply make a phone call
and get things deleted through a privileged legalistic
and back-door process -- for what everyone else does
with the edit button.

Stevertigo

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


from_name: Daniel Arnold

subject:
[Foundation-l] (volunteer) job position : Ombudsperson
	checkuser (or checkuser Ombudsperson or whatever)

body:
Am Mittwoch, 21. Juni 2006 21:50 schrieb Sam Korn:
> You quoted "> 50%" of checkuser uses are on en.wikipedia.  Looking at
> traffic figures (Alexa), this seems about right.
>
> Perhaps it is more de.wikipedia using CheckUser proportionally very
> little rather than en.wikipedia using it proportionally very much.

Well I didn't suggest that en.wp did abuse Checkuser and I also think that
en.wp people didn't abuse it. I am very confident that every single Checkuser
can be justified afterwards.

But what I was suggesting was an alternate aproach which has it pros and cons
as well. I don't think in black-white categories.

I am learning as well. The reason why de.wp does not really use Checkuser is
probably a cultural phenomena which can be understood best by the way how
computer technology is being percieved in Germany/Austria/Switzerland. Every
new technology gets anxiously reviewed by society but later after people
deliberated about the technology they use it very extensive with a clear
roadmap what they want to to with it; perhapes this explains why German is so
overproportionally represented online but why in contrast new ideas in the
internet mainly come from the US where people just play around with cool new
stuff - take these comments with a grain of salt this is just a
non-scientific personal observation.

Arnomane


list: wikitech-l

from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2006-06-22

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

Running test External image... FAILED!
Running test External image from https... FAILED!
Running test External links: Clickable images... FAILED!
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 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!

Passed 390 of 406 tests (96.06%) FAILED!


body:
Am Mittwoch, 21. Juni 2006 21:52 schrieb Kelly Martin:
> I really think you should refrain from commenting on how checkuser
> should be used on en.wp when you clearly don't have any real
> information about how we currently use it or even our own policies on
> the matter.  You're not even subscribed to the checkuser list.

I don't need to be subscribed to any list in order to make some good suggests
and given the fact that I was the *only one* that gave some exact numbers I
think that my comments where necessary.

Arnomane


from_name: Johan Bos

subject: [Foundation-l] Simple Spanish?

body:
I started a test at incubator:

http://incubator.wikimedia.org/wiki/Category:Sencillo

Everybody able to write a simplified form of Spanish is invited to write an
article for the test.

I also placed a proposal at Meta:

http://meta.wikimedia.org/wiki/Proposals_for_new_projects#Proposal_for_simple_Spanish_wiki

So we will see...

Greetings,

Johan

----- Original Message -----
From: "James Hare" <messedrocker at gmail.com>
To: "Wikimedia Foundation Mailing List" <foundation-l at wikimedia.org>
Sent: Wednesday, June 21, 2006 8:57 PM
Subject: Re: [Foundation-l] Simple Spanish?

> Well, try bringing it up on the Incubator: http://incubator.wikimedia.org
>
> On 6/21/06, Johan Bos <skatinghacker at hotmail.com> wrote:
>>
>> Not as far as I know. I just meant articles in simple Spanish words.
>> Readable for people who just understand for example 1500 words.
>>
>> Greetings,
>>
>> Johan Bos
>>
>> ----- Original Message -----
>> From: "James Hare" <messedrocker at gmail.com>
>> To: "Wikimedia Foundation Mailing List" <foundation-l at wikimedia.org>
>> Sent: Wednesday, June 21, 2006 7:22 PM
>> Subject: Re: [Foundation-l] Simple Spanish?
>>
>>
>> > Simple Spanish Wikipedia is a great idea, since we have Simple English.
>> > However, I heard that Simple English is an actual, established subset
>> > of
>> > the
>> > English language. Can we say the same about Simple Spanish?
>> >
>> > --James Hare
>> >
>> > On 6/21/06, Johan Bos <skatinghacker at hotmail.com> wrote:
>> >>
>> >> Spanish is worldwide a big language. Would it be an idea to start a
>> >> "simple
>> >> Spanish" wiki: sencillo.wikipedia.org? I would be prepared to
>> contribute
>> >> to
>> >> it.
>> >>
>> >> Greetings,
>> >>
>> >> Johan Bos (Jcb)
>> >> _______________________________________________
>> >> foundation-l mailing list
>> >> foundation-l at wikimedia.org
>> >> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>> >>
>> > _______________________________________________
>> > foundation-l mailing list
>> > foundation-l at wikimedia.org
>> > http://mail.wikipedia.org/mailman/listinfo/foundation-l
>> >
>> _______________________________________________
>> foundation-l mailing list
>> foundation-l at wikimedia.org
>> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


subject: [Foundation-l] Simple Spanish?


body:
Am Mittwoch, 21. Juni 2006 23:31 schrieb Anthere:
> > Will that create more meta work ?
> No. It will delegate meta work or move meta work to another person. I am
> currently doing the job.

Yes and I was suggesting that you and everbody else just drop the job entirely
and that maybe there are other solutions without the need for such a hard
work.

I think that it is important for Wikimedia to think about solutions how to
avoid some "meta-work".

You're all doing voluntarily an incredible hard job every day and my main
concern is that you will end up with too much time consuming work which
doesn't improve Wikimedia projects directly (Better content, better software,
better server maintenance, better PR...).

Arnomane


from_name: Brion Vibber

subject: [Wikitech-l] New SVN committer

body:
Jitse Nielsen (jitsenielsen), will be adding Blahtex extension.

-- 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/20060622/c9ec3c2d/attachment.pgp>


subject:
[Wikitech-l] [Wikipedia-l] [Foundation-l] moving
 forward	on	article validation

body:
Magnus Manske wrote:
> A next step would be to output the "file heap" as compressed files to
> save disk space. Further, these compressed files could be merged into
> one single huge file, since the file system has a little trouble coping
> with that many files. That would require a separate file with title and
> position-in-file indices, though.

ZIP or another like archive format that allows random-access to contained files
might be appropriate here.

-- 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/20060622/4a362d61/attachment.pgp>


from_name: Rob Church

subject: [Wikitech-l] patrolling improvement

body:
On 22/06/06, Travis Derouin <travis at wikihow.com> wrote:
> Nice.

Thanks. :)

> this is the SQL i'm using, it works for MySQL but I'm not sure about
> other databases, the "ORDER BY rc_id DESC LIMIT 1" should get you the
> next oldest edit.

That won't work, because sooner or later, older edits (that are no
longer current) will show up, and if people hit Revert, Bad Things
will happen.

Also, the SQL needs to do a bit of a JOIN against a HEAP table.

Rob Church


subject: [Foundation-l] New privacy policy

body:
http://wikimediafoundation.org/w/index.php?title=Privacy_policy&oldid=14088

may be found here.

Please, spread the word that all the translations in various languages
should be updated. Thanks in advance.

Ant


subject: [Foundation-l] New privacy policy


body:
Sam Korn wrote:
> On 6/21/06, Daniel Arnold <arnomane at gmx.de> wrote:
>
>>en.wikipedia (and some other smaller projects as well) have overproportional
>>heavy use of CheckUser.
>
>
> I disagree.  en.wikipedia receives far more traffic than any other
> wiki.  en.wikipedia receives more edits than any other wiki.  I expect
> it would follow that en.wikipedia receives a similarly high proportion
> of trolling and sockpuppetry.
>
> You quoted "> 50%" of checkuser uses are on en.wikipedia.  Looking at
> traffic figures (Alexa), this seems about right.

Already mentionned, but worth repeating.

According to Alexa, the french language wikipedia represent 2% of the
traffic. Given that it is right now the third biggest language on
Wikipedia, I can't help consider that Alexa's international data should
be taken with a pinch of salt.

ant

> Perhaps it is more de.wikipedia using CheckUser proportionally very
> little rather than en.wikipedia using it proportionally very much.
>


subject: [Foundation-l] Simple Spanish?

body:
I agree that Spanish is not too difficult, but it will take a lot of effort
to learn sufficient Spanish to be able to read a Spanish article without
using a dictionary. A "sencillo" article will be readable without a
dictionary for anyone with a basic knowlegde of Spanish.

Another advantage is that probable most Italian and Portugese people will be
able to read "sencillo", without even knowing any Spanish.

Greetings,

Johan

----- Original Message -----
From: "Austin Hair" <adhair at gmail.com>
To: "Wikimedia Foundation Mailing List" <foundation-l at wikimedia.org>
Sent: Thursday, June 22, 2006 12:41 AM
Subject: Re: [Foundation-l] Simple Spanish?

> On 6/21/06, Johan Bos <skatinghacker at hotmail.com> wrote:
>> Not as far as I know. I just meant articles in simple Spanish words.
>> Readable for people who just understand for example 1500 words.
>
> English is the most widely spoken second language on the planet, the
> lingua franca of international communication; it's also really hard.
> The argument for the "simple English" editions is that with more
> non-native speakers than native ones, a special effort should be made
> to cater to those who haven't quite mastered this undoubtedly
> difficult tongue.  While I don't agree, I do recognize the validity of
> that point of view.
>
> While Spanish may have more native speakers, it doesn't enjoy the same
> ubiquity, and its mostly regular syntax means it doesn't pose the same
> difficulty to novices.  You seem to acknowledge the second point
> yourself when you talk about "sencillo" as nothing more than a
> limited-vocabulary edition of the Spanish Wikipedia.
>
> We're only just starting to recover from the damage done by the
> infamous Enciclopedia Libre fork, and I can't see anyone supporting
> any division of those efforts right now.
>
> Austin
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


subject: [Foundation-l] Simple Spanish?


from_name: Alhen

subject: [Foundation-l] Simple Spanish?

body:
Dejavu? This is not the first attempt to start a simple.es wikipedia. Check
this link

http://meta.wikimedia.org/wiki/Requests_for_new_languages/Denied#Simple_Spanish_.286_support_.5B2_anonymous.5D.2C_1_neutral.2C_29_oppose.29


subject: [Foundation-l] Simple Spanish?


subject: [Wikitech-l]Complete image list of a local Wikipédia

body:
Emmanuel Engelhart wrote:
> Is there a chance to get a dump of all pictures (or/and thumbnailed
> versions) used in the french wikipedia if :
> - I give a list of pictures
> - I give the script to get this list of pictures
> - I give the script to store the files in a directory tree.
>
> I currently work to propose a offline-reader prototype (with the french
> wikipedia content) working without (mysql, apache, mediawiki) , and the lack
> of pictures is almost the last problem I can't solve.

Sure, we could do a temporary one for you until a more permanent solution is in
place.

Note that you can put together a list of used local and commons images
relatively easily:

1) Grab 'image', 'imagelinks' tables for frwiki and 'image' table for
commonswiki from download.wikimedia.org

2) The set of unique il_to values in imagelinks gives you the list of all base
filenames.

3) Intersect the list with the img_name values in frwiki's image table. Those
which match have files in wikipedia/fr.

4) Take the leftovers and intersect them with commonswiki's image table. Those
which match have files in wikipedia/commons.

5) Throw away any left; those are references to nonexistent files.

These lists will skip any unused image files.

-- 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/20060622/819e3035/attachment.pgp>


from_name: geni

subject: [WikiEN-l] newbie culture

body:
On 6/22/06, Ilya N. <ilyanep at gmail.com> wrote:
> Being here for 3 years (and I'm pretty sure you've been here for about that
> long), I've never seen a 'new generation' start doing something like this.

Bit over 2. I can't be certian but my generation was the one that had
the issue of people not knowing each other any more. The one that
followed seemed to belive that admins were more powerful than I
remeber. Then there was the CVU and the countervandalism specialists.
Now there is the current generation. Things change. At best we can
sing as we go.

--
geni


from_name: Mark Williamson

subject: [Wikitech-l] Urdu Wikipedia gone?

body:
Hi all, I can't see the Urdu Wikipedia http://ur.wikipedia.org/

What's up?

Mark


from_name: James

body:
It's interesting for many reasons, not least because it is explicit in
rejecting many of the misunderstandings people have used to object to
various fair use cases. Hopefully the explicit statements will resolve
those misunderstandings. Nothing actually new in the decision but it
makes some things really obvious (I hope! :))

First the case itself: a history of the Grateful Dead group, used many
pictures of posters and tickets where a copyright holder had refused
permission under fair use and won in a relatively inexpensive summary
judgment.

"Illustrated Trip is a biographical work, and the original images are
not, and therefore accorded a strong presumption in favor of DK's use.
In particular, the district court concluded that DK's use of images
placed in chronological order on a timeline is transformatively
different from the mere expressive use of images on concert posters or
tickets. Because the works are displayed to commemorate historic
events, arranged in a creative fashion, and displayed in significantly
reduced form, the district court held that the first fair use factor
weighs heavily in favor of DK."

This aspect applies to almost all uses in articles in the work called
Wikipedia by its authors. Whether it's a baseball card, poster, album
cover, book cover, mural, painting or postcard, it's not an
encyclopedia article and the use is in one is transformative and
strongly favors fair use.

Exceptions: using artwork to look pretty. But the same artwork to
illustrate a style of dress or suit of armor is being used for factual
value, not beauty, and is fine because that is transformative. Of
course, using a scientific image to look pretty would be a
transformative use from factual to artistic and hence
transformative...

"Appellant asserts that each reproduced image should have been
accompanied by comment or criticism related to the artistic nature of
the image. We disagree with Appellant's limited interpretation of
transformative use and we agree with the district court that DK's
actual use of each image is transformatively different from the
original expressive purpose."
"In some instances, it is readily apparent that DK's image display
enhances the reader's understanding of the biographical text. In other
instances, the link between image and text is less obvious;
nevertheless, the images still serve as historical artifacts
graphically representing the fact of significant Grateful Dead concert
events selected by the Illustrated Trip's author for inclusion in the
book's timeline. We conclude that both types of uses fulfill DK's
transformative purpose of enhancing the biographical information in
Illustrated Trip, a purpose separate and distinct from the original
artistic and promotional purpose for which the images were created."

You don't need to have specific justification for each image use -
readers know from the context that you're illustrating your point (but
we should still say so in the fair use explanation, because it's
prudent to do so and remove doubt about our intentions).

On to image size but not that at this point the decision has already
said that the use was fine and it's merely strengthening an already
strong position:

"DK was not required to discuss the artistic merits of the images to
satisfy this first factor of fair use analysis. This conclusion is
strengthened by the manner in which DK displayed the images. First, DK
significantly reduced the size of the reproductions. ... While the
small size is sufficient to permit readers to recognize the historical
significance of the posters, it is inadequate to offer more than a
glimpse of their expressive value. In short, DK used the minimal image
size necessary to accomplish its transformative purpose."

"(noting that a work that comments about "pop culture" is not removed
from the scope of Section 107 [fair use]simply because it is not
erudite)."

Sadly for those who dislike articles about popular culture, merely
being about popular culture doesn't remove fair use. :) You get to use
Beanie Baby pictures as well as the most admired modern art under fair
use.

"nearly all of the illustrative uses listed in the preamble paragraph
of ? 107 . . . are generally conducted for profit ... Here,
Illustrated Trip does not exploit the use of BGA's images as such for
commercial gain. Significantly, DK has not used any of BGA's images in
its commercial advertising or in any other way to promote the sale of
the book. Illustrated Trip merely uses pictures and text to describe
the life of the Grateful Dead. By design, the use of BGA's images is
incidental to the commercial biographical value of the book."

For those who wonder about fair use and commercial reusers of content
placed in Wikipedia by its authors. Those commercial users also get
fair use and that was part of the original intent of fair use law.

"Accordingly, we conclude that the first fair use factor weighs in
favor of DK because DK's use of BGA's images is transformatively
different from the images' original expressive purpose and DK does not
seek to exploit the images' expressive value for commercial gain."

This highlights the important parts: transformative and not the
_expressive_ value but the historic value. Size is a factor but not
critical.

"we hold that even though BGA's images are creative works, which are a
core concern of copyright protection, the second factor has limited
weight in our analysis because the purpose of DK's use was to
emphasize the images' historical rather than creative value."

Not in favor of fair use but the factual use not the artistic use
largely eliminates the concern about protecting art.

"We conclude that such use by DK is tailored to further its
transformative purpose because DK's reduced size reproductions of BGA'
s images in their entirety displayed the minimal image size and
quality necessary to ensure the reader's recognition of the images as
historical artifacts of Grateful Dead concert events. Accordingly, the
third fair use factor does not weigh against fair use."

Reduced resolution is helpful but do remember that you can use
whatever size is required. You do need to use sufficient resolution of
portion so the viewer can clearly see what you're trying to show!
We're already using suitable sizes, I think, so no change necessary,
except reassurance for those who wondered whether small images were a
problem if it was showing a small version of it all.

"the parties agree that DK's use of the images did not impact BGA's
primary market for the sale of the poster images."

This should also be the case for almost all uses in Wikipedia, since
Wikipedia use isn't the same as the originals - the only cautions here
would be news agency images in current breaking news situations and
the same ones in historical articles would be fine, because that's
history not news.

On to a bit that often causes confusion... loss of revenue for the
copyright holder. Best summarized with the simple sentences
"[C]opyright owners may not preempt exploitation of transformative
markets. ... Since DK's use of BGA's images falls within a
transformative market, BGA does not suffer market harm due to the loss
of license fees." (because it's not entitled to them anyway). Since
use in Wikipedia will always be transformative, this is very unlikely
to be a negative factor for a use in Wikipedia.

"Appellant argues that DK interfered with the market for licensing its
images for use in books. Appellant contends that there is an
established market for licensing its images and it suffered both the
loss of royalty revenue directly from DK and the opportunity to obtain
royalties from others. ...

We have noted, however, that 'were a court automatically to conclude
in every case that potential licensing revenues were impermissibly
impaired simply because the secondary user did not pay a fee for the
right to engage in the use, the fourth fair use factor would always
favor the copyright holder.'

Moreover, Appellant asserts that it established a market for licensing
its images, and in this case expressed a willingness to license images
to DK. Neither of these arguments shows impairment to a traditional,
as opposed to a transformative market.  In a case such as this, a
copyright holder cannot prevent others from entering fair use markets
merely "by developing or licensing a market for parody, news
reporting, educational or other transformative uses of its own
creative work."

"[C]opyright owners may not preempt exploitation of transformative
markets . . . ."

"Moreover, a publisher's willingness to pay license fees for
reproduction of images does not establish that the publisher may not,
in the alternative, make fair use of those images. Since DK's use of
BGA's images falls within a transformative market, BGA does not suffer
market harm due to the loss of license fees."

And the conclusion:

"we conclude, as the district court did, that the fair use factors
weigh in favor of DK's use. For the first factor, we conclude that DK'
s use of concert posters and tickets as historical artifacts of
Grateful Dead performances is transformatively different from the
original expressive purpose of BGA's copyrighted images. While the
second factor favors BGA because of the creative nature of the images,
its weight is limited because DK did not exploit the expressive value
of the images. Although BGA's images are copied in their entirety, the
third factor does not weigh against fair use because the reduced size
of the images is consistent with the author's transformative purpose.
Finally, we conclude that DK's use does not harm the market for BGA's
sale of its copyrighted artwork, and we do not find market harm based
on BGA's hypothetical loss of license revenue from DK's transformative
market."

And that's the reasoning that's going to apply to uses in Wikipedia as
well, for pretty much the same fundamental reasons: transformative use
and not primarily of value just because of the images, which are
accompanied by the articles that provide the main part of the content.

But once this legal aspect is taken care of, do remember that it's
nice to seek to replace fair use images with more freely licensed
images as those become available. Recruit friends, take pictures on
vacations and around your town and encourage others to do so, so we
can gradually replace all those that can be replaced. It'll take a
while to get everyone on the planet working with us so we have done
this for everything but it'll happen eventually... meanwhile, remember
we're a wiki and successive improvement over time is one of the
fundamental principles of wiki use. We don't insist on perfect first
versions of an article and nor should we do so for images. But we
should encourage perfection in both over time.

James Day


subject: [WikiEN-l] Oversight log

body:
The suitable initial group seems clear enough: every administrator.

Beyond that, the censored log should be available to everyone.
Administrators often have more than enough to do and any assistance
non-administrators can do in the way of oversight is a good thing.

Removing the page isn't close to sufficient - it conceals what is
perhaps the most significant part of what is being overseen: who is
doing what, where and still concealed from most, why.

It's worth remembering that a few million pages with things not
vanishing completely have not brought the encyclopedia or Foundation
down. Making sure we have ample oversight so that people actually look
hard at what is being done and mention problems is important to our
process.

Without broad oversight, the capability to make thing silently vanish
should also be vanishing.

James Day


subject: [WikiEN-l] Oversight log

body:
> The problem is that what we are removing is stuff like personal
> information or libelous statements that we really do want to vanish
> and not be repeated internally.
>
> Fred

Of course, but oversight from the broadest practical group is still
required. I'm not expecting much in the way of trouble from admins
abusing their capability and in the event that there is some, the
admin concerned can be dealt with in other ways.

What I don't want to see is us making it sufficiently interesting that
people start routinely publishing differences between database dumps
to highlight what is removed, or start routinely capturing and
comparing "hot" pages to look for such things. So much oversight that
it's obviously being looked after is one way to do that.

James Day


from_name: Daniel P. B. Smith

subject: [WikiEN-l] What is "spam?"

body:
> From: "Alphax (Wikipedia email)" <alphasigmax at gmail.com>
>
> Nathan wrote:
>> I remember having an imposter with a weird unicode version of the
>> first
>> "N" in my username. In fact, it's my only imposter.
>>
>> I think such usernames should be blocked too.
>>
>> - Nathan (nathanrdotcom)
>>
>
> I think *your* username is innappropriate since you're spamming
> your URL
> in it.

Yeesh. Give him a break.

It's unobtrusive. It's a username, so it never appears in the main
namespace. It's not a link, so it won't affect his site's pagerank.

And if you look at that site, _it's just a personal website,_ no
different in kind from a Wikipedia user page.

On the spectrum from where co-opting Wikipedia for commercial gain is
a ten and obnoxious self-promotion is a one, this is a zero. It's
about as objectionable as using a username that happens to resemble
one's email address.


from_name: Fred Bauder

subject: [WikiEN-l] Oversight log

body:
On Jun 22, 2006, at 1:00 AM, stevertigo wrote:

> Understanding that legal systems are not always
> reasonable, WM cant reasonably be responsible for
> everything in the history of its articles. And to say
> the risk is great is simply to court the clique of
> privelege who think they can simply make a phone call
> and get things deleted through a privileged legalistic
> and back-door process -- for what everyone else does
> with the edit button.
>
> Stevertigo

You say you understand that "legal systems are not always
reasonable". But you do not connect the dots. We can take steps to
reduce the chance we will be the victim of judicial unreasonableness.
As to the clique of privilege, there is a small stratum in society
which has the money, power and prestige to use the legal system (or
effectively publicize their distress). We do not court them, they are
simply more confident that a complaint will be responded too, so are
more likely to complain. A complaint from anyone would hopefully
receive equal consideration.

Fred


subject: [WikiEN-l] Oversight log

body:
Complete log including revision text to all administrators (and
action, including removal of the full view capability from the
administrator concerned, taken if an administrator misuses the
capability) and the former incomplete censored one without the
contents of the text available to all.

That makes it pretty easy for anyone to question an act and any
administrator (perhaps the one they trust most) to check on it and
reassure them that it merited removal.

And revisit perhaps in the event that we see a regular pattern of
problems arising from this. Could happen; we'll see.

James Day


subject: [WikiEN-l] semi-stuff (was Re:  New York Times article)

body:
On Jun 22, 2006, at 1:32 AM, Mark Gallagher wrote:

>
> G'day Alphax,
>
>
>> Guy Chapman aka JzG wrote:
>>
>>
>>> On Wed, 21 Jun 2006 00:44:48 +0200, Jimmy Wales <jwales at wikia.com>
>>> wrote:
>>>
>>>
>>>> It is my intention that we work to creatively
>>>> soften even more restrictions.
>>>>
>>>
>>> How about semi-blocking, letting semi-blocked editors comment on
>>> Talk
>>> but not in article space?
>>>
>>
>> Ideally, blocking would be even more fine-tuned:
>>
>> * Block users from individual namespaces
>> * Block users from individual articles
>> * Fix Bug 550 *and implement the fix*
>>
>
> * Block users from uploading images
> * Block users from creating articles
> * Block users from moving articles
>
> We've all seen users completely blocked because of a regrettable
> tendency to upload copyvios or create POV forks or move-war.  Now,
> they
> could be otherwise intelligent people who think they know about
> copyright law but don't; or useful contributors when they're being
> supervised by other people on controversial articles, but who feel
> free
> to let rip on their "own" fork articles; or people who insist on
> treating the "move" button as a toy and causing unnecessary work for
> admins and unnecessary stress for non-admins.  In that last case,
> Curps'
> bot caught at least one offender, but that's hardly reliable.
>
> It would be nice to be able to prevent certain people from doing
> obnoxious things without blocking them completely.  We shouldn't
> have to
> block otherwise sane users because of a minor foible.
>

The arbitration committee is constantly on the lookout for solutions
which provide partial solutions such as you suggest so that there are
alternatives to simply blocking someone. Mostly they depend on the
using being willing to comply with partial bans on their editing.
This is not done by software, but enforced by administrative blocking
if they violate the partial ban, such as editing particular articles.

Fred

>
> (I don't know Bug 550, but I assume it's the one about the
> autoblocker)
>
>
> Cheers,
>
> --
> Mark Gallagher
> "What?  I can't hear you, I've got a banana on my head!"
> - Danger Mouse
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Anthony DiPierro

body:
On 6/22/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 6/21/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> > When a non-logged in user creates a new article stick "warning, this
> > isn't really part of Wikipedia" on the top of it.  Then, when a logged
> > in user edits it, take the warning off.  If no logged in user edits it
> > within X days, delete it.
>
> I would strongly urge us *not* to make the mistake of assuming that
> "edited by a logged-in user" equals "approved by a logged-in user". We
> should *not* be forcing people to take responsibility for whole
> articles if they simply fix a typo, add a category, or tweak an
> interwiki link. Bad, bad idea.
>
You could always add a checkbox for this (though I would think adding
a category or tweaking an interwiki link would suggest that one does
not think an article is suitable for deletion).


body:
On 6/22/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 6/21/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> > Isn't AfC part of Wikipedia?
>
> Nope, it's in Wikipedia: space.
>
> (as contradictory as that sounds)
>
> Steve

So if new articles by users that weren't logged in had "Wikipedia:" in
front of their title then you wouldn't have a problem with keeping the
crap?

Anthony


subject: [Wikitech-l] Wikimarkup request: -- to em-dash

body:
Steve Bennett wrote:
> Heh, I see in this case it's been requested at least 3 times before.
> Most of the discussion is on
> http://bugzilla.wikimedia.org/show_bug.cgi?id=1485 and is quite
> interesting - issues about when to convert to em-dash vs en-dash. The
> discussion seems to boil down to: everyone agrees that -- to em-dash
> is intuitive, but how do you then implement a syntax for en-dash for
> the few people who want it?

Luckily we've already got one: –

Damn typography snobs... ;)

-- 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/20060622/e2c4c741/attachment.pgp>


from_name: Brad Patrick

subject: [Foundation-l] New privacy policy

body:
On 6/22/06, Jimmy Wales <jwales at wikia.com> wrote:
>
> Nathan Reed wrote:
> > "It is the policy of Wikimedia that personally identifiable data
> collected
> > in the server logs, or through records in the database via the CheckUser
> > feature, may be released by the system administrators or users with
> > CheckUser access, in the following situations:"
> >
> > Does this mean that personally identifiable information may be released
> by
> > users with CheckUser permissions? For example, is it permissible for me
> to
> > release the actual IP address of a vandal to the general public? I'm not
> > sure, but this may not be a good thing.
> >
> > I can understand using the information for IP blocks, but perhaps the
> > release of the information should not be so broad in these cases. Or,
> maybe
> > I'm tired, have failed to comprehend the policy completely, and have
> missed
> > something.. :D
>
> Notice that the privacy policy is what we tell the public that we *may*
> do.  We can and should, in practice, be as privacy conscious as we can
> be, and so checkusers who have any doubt about to whom they should
> release information, and when, and why, should check carefully with
> Angela, Anthere, me, brad, other checkusers, relevant arbcoms, etc.
>
> Even if our privacy policy leaves us room to do something if we need to
> do it, we may choose not to do it in most cases.
>
> --Jimbo
>
>
To second Jimbo, part of what is really important about this is the notion
of "flexible response" especially when dealing with sensitive issues, i.e.
law enforcement (it happens) and emergency situations.  We absolutely are
committed to a minimalist policy and will endeavor to release as little as
possible, whenever possible.  However, we are also ensuring that if a
situation arises that calls for us to do something, we can do so within the
parameters of our own policy.  I think it is a natural evolution and a good
policy.

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


subject: [Foundation-l] New privacy policy


from_name: Matt Brown

subject: [WikiEN-l] Monobook suddenly changed?

body:
On 6/22/06, Steve Bennett <stevagewp at gmail.com> wrote:
> Is there a way of being notified of these changes before they suddenly appear?

Technically these are not changes to the monobook skin itself but to
some of the messages (from the msg: namespace) that are transcluded
into the interface by it.  These messages are editable (although many
are protected and thus editable only by admins) and there has not
been, up to now, any formal procedure for approving changes to them.
They are handled like policy pages and the like.

Currently we have no global warnings if someone edits policy pages either.

Perhaps it would be a good idea, but it would be a significant change
to the way things are done.

-Matt


from_name: Ævar Arnfjörð Bjarmason

body:
On 6/22/06, Steve Bennett <stevage at gmail.com> wrote:
> Hi,
>   Many must have informally requested it: would it be possible and
> desirable to have -- be interpreted as em-dash (?)? It's a very useful
> symbol, particularly in the context of writing an encyclopaedia, but
> is not readily available on the keyboard. Many editors already seem to
> naturally use -- to try and imitate a proper em-dash.
>
> What are the issues involved? Anyone know of other uses of -- that
> should not be interpreted this way? Is there any argument that it
> should become some other kind of dash instead?
>
> Also, I realise there are bots that occasionally go around replacing
> -- with other dashes, but that does seem a bit kludgy.
>
> In the meantime, on en I have created {{--}} which surprisingly no one
> had thought of creating.

This is something that was in the 1.5 development tree before release
but pulled out just before release due to issues with doing dumb -- to
emdash replacement in the not-a-parser. One case I remember it
breaking on was image names which contained --, links around --
([[foo|bar]]--[[bar|foo]] didn't work etc.)


body:
On Jun 22, 2006, at 8:12 AM, Jimmy Wales wrote:

> Will we have to sit through watching some troll be successively banned
> from one action after another as people cry "Why prevent him from
> editing articles about Chemotherapy? All he was doing was uploding
> goatse to articles on homosexuality?  He might be a good user."

You exaggerate.

Fred


subject: [WikiEN-l] semi-stuff (was Re: New York Times article)

body:
On Jun 22, 2006, at 8:16 AM, geni wrote:

> At the moment when I run into someone who just ignores image
> copyright my only option is to try and educate them and if that fails
> try and figure out some way under the rules to block them. I don't
> have a button to deal with people who can't upload images responsibly.
>
>
> --
> geni

Does it make sense to have one? a button, that is.

Fred


body:
On 6/22/06, Steve Bennett <stevage at gmail.com> wrote:
> On 6/22/06, ?var Arnfj?r? Bjarmason <avarab at gmail.com> wrote:
> > This is something that was in the 1.5 development tree before release
> > but pulled out just before release due to issues with doing dumb -- to
> > emdash replacement in the not-a-parser. One case I remember it
> > breaking on was image names which contained --, links around --
> > ([[foo|bar]]--[[bar|foo]] didn't work etc.)
>
> OIC, the substition was taking place too early? Yeah, you wouldn't
> want {{--}} to be treated as if you'd typed {{?}}...
>
> So is it permanently dead?

No, like I said the currently availible implementation has flaws, and
there might also be other issues to work out besides that, such as
locale issues. But I don't think anyone (Brion for one doesn't, IIRC)
objects to the idea of having a working implementation of that in the
parser.


from_name: Keith Old

body:
On 6/22/06, Bryan Derksen <bryan.derksen at shaw.ca> wrote:
>
> Anthony DiPierro wrote:
> > Until an article is approved, it can be deleted by *any* registered
> > user, there's no need to bother an admin to delete it.  Additionally,
> > if the article is not approved within X days, it is automatically
> > deleted.
>
> All good, IMO, except for the assumption of bad faith right at the end
> there. I don't see why the default has to be "delete". At that point the
> article's been hanging around for X days with a bomb strapped to its
> chest and not a single editor has seen fit to pull the trigger on it,
> suggesting that it probably isn't total trash. It may simply be a little
> questionable, which is something Wikipedia can work with.
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
>
>
> If we adopted such a system, it should work so that a user can nominate an
article and an admin can make a decision according to our policy on
deletion. There should also be consideration of the categories of
article that would be liable for speedy deletion and those that would go
through a lengthier process such as Articles for deletion.

As Bryan Derksen argues, we should look at which articles we should work on
and which have no potential at all.

Regards

*Keith Old*


from_name: Magnus Manske

body:
Kyle Anderson schrieb:
> On Thu, 2006-06-15 at 11:47 +0200, Andy Rabagliati wrote:
>
>> I am also
>> interested in post-processing - stripping redlinks, including ''main
>> article'' references on core articles, like ''History of South Africa''
>> etc. I want to be able to tweak parameters, then press a button and get
>> a new CD (from my downloaded XML dump of en and a picture collection,
>> and possibly via a live mediawiki snapshot of that content).
>>
> Live? How did you want to do this? Perhaps using the toolserver?
>
To shamelessly plug one of my toys again:
Included in my Wiki-to-XML-to-(inser your favourite format) is a script
that reads an XML dump and converts it into lots of single files, one
per article. This "file heap" can then be browsed using the
Wiki-to-XML-to-XHTML converter. It thus only depends on PHP and a web
server, which should be easy to bundle with a CD/DVD.
I also had the whole "file heap" indexed with Lucene, but didn't bother
to hack a search frontend into the generated XHTML. Otherwise, I'd have
had fulltext search as well.

A next step would be to output the "file heap" as compressed files to
save disk space. Further, these compressed files could be merged into
one single huge file, since the file system has a little trouble coping
with that many files. That would require a separate file with title and
position-in-file indices, though.
Note that one can't just use the compressed dump file directly, as
seeking in a compressed file is slooooow (it has to decomress everything
that comes before the position you seek). So I'd go for a single file
consisting of compressed individual files stacked on top of each other.

Templates work fine for that solution, categories don't - yet.

Magnus

P.S.: SVN, module "wiki2xml", directory "php", for those interested.

-------------- 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/20060622/eae91a32/attachment.pgp>


from_name: Steve Bennett

subject:
[WikiEN-l] Category:<Subjective-pejorative>, weak consensus,
	and ! NPOV

body:
On 6/22/06, stevertigo <vertigosteve at yahoo.com> wrote:
> I believe this is basic bonehead-level NPOV people,
> and  it should be a good lesson to resolve it. As
> interesting as it is to organize people by their
> faulty views, doing so in this manner only reveals our
> own  faulty adherence to the holy prime directive. And
> if youre one of those people who has to ask what that
> is...

It's a dodgy category bound to offend people. And is it helpful? Are
people likely to browse this category for some research purpose? I
feel that lists like "People that Israel has accused of anti-semitism"
would be more useful in that regard. Allowing such broad
interpretations of "anti-semite" or even "accused of anti-semitism" is
unlikely to be NPOV.

In any case, most of these religion or ethnicity-related categories
are pretty dodgy. I'd like to hear any suggestions anyone has for
dealing with them, and in particular, want to hear what the main
arguments for keeping them are. Ie: what is useful about
"Category:Jewish Americans".

Steve


body:
On 6/21/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> Isn't AfC part of Wikipedia?

Nope, it's in Wikipedia: space.

(as contradictory as that sounds)

Steve


body:
On 6/21/06, Anthony DiPierro <wikilegal at inbox.org> wrote:
> When a non-logged in user creates a new article stick "warning, this
> isn't really part of Wikipedia" on the top of it.  Then, when a logged
> in user edits it, take the warning off.  If no logged in user edits it
> within X days, delete it.

I would strongly urge us *not* to make the mistake of assuming that
"edited by a logged-in user" equals "approved by a logged-in user". We
should *not* be forcing people to take responsibility for whole
articles if they simply fix a typo, add a category, or tweak an
interwiki link. Bad, bad idea.

Steve


from_name: Sue Reed

subject: [WikiEN-l]And you thought Pokémon was trivial...

body:
They are not sourced and there are a bunch of statements like "The reason often given for its retirement ..."

Sue Annesreed1234 at yahoo.com

----- Original Message ----
From: Jimmy Wales <jwales at wikia.com>
To: English Wikipedia <wikien-l at Wikipedia.org>
Sent: Thursday, June 22, 2006 6:55:42 AM
Subject: Re: [WikiEN-l] And you thought Pok?mon was trivial...

Justin Cormack wrote:
> The main article includes the memorable part:
> "Not all episodes of the Cullen run are believed to exist, although many
> of them do. All episodes of the other versions are believed to exist."

Is there a source?  My main concern about all this fancruft is that we
are absolutely going to get burned by a hoaxer if we do not become much
more serious about banning original research and mercilessly editing
stuff that has no sources.

--Jimbo

_______________________________________________
WikiEN-l mailing list
WikiEN-l at Wikipedia.org
To unsubscribe from this mailing list, visit:
http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: stevertigo

body:
--- Mark Gallagher
<m.g.gallagher at student.canberra.edu.au> wrote:
> Well, folks and folkettes, we always have a long
> wait for these things,
> but it looks like we've finally found another
> violation of WP:POINT.

Since when does WP:POINT trump WP:NPOV? I will never
apologise for "violating" POINT if its to make a stand
for NPOV - particularly in light of a leadership
vacuum wherin clear NPOV violations are by "consensus"
allowed to stand.

> For what it's worth, I do agree with you:
> [[Category:Anti-Semitic
> people]] a) does not appear to serve a useful
> purpose, b) is not exactly
> neutral, c) could well be described as a lawsuit
> waiting to happen, if
> applied improperly.

I disagree with the lawsuit paranoia, and dislike is
usage as a crutch in arguments wherin a plain
application of basic bonehead-level NPOV will suffice.
Your agreement is noted, but is it counted?

> You could do with being a little less strident about
> it, though.  Your
> comment on that TfD wasn't going to change anyone's
> mind: it looks quite
> logical to someone who already agrees with you, but
> that's not as
> beneficial as you might think.

I dont know what else to say. Either we have a culture
which respects NPOV or we do not.

Regards,
SV

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


from_name: Mark Wagner

subject: [WikiEN-l] Oversight log

body:
On 6/21/06, Fred Bauder <fredbaud at ctelco.net> wrote:
> The problem is that what we are removing is stuff like personal
> information or libelous statements that we really do want to vanish
> and not be repeated internally.

Then the log as viewable to the world at large should say something
like '10:49, 22 June 2006 Fred Bauder deleted 1 revision(s) of "George
W. Bush" (Personal information)'

--
Mark
[[User:Carnildo]]


from_name: Anthere

subject: [Wikitech-l] mediawiki logo

body:
By the way, my original flower was in gfdl and you asked me Erik, to put
it in public domain so as to make use of the logo easier.

The image you are considering is not public domain. Is that a problem ?

Ant


from_name: The Cunctator

body:
On 6/21/06, Erik Moeller <eloquence at gmail.com> wrote:
>
> On 6/21/06, Ian Woollard <ian.woollard at gmail.com> wrote:
> > The more complicated you make it, the more unintended consequences there
> > are likely to be, the more failure modes there are and the more unwieldy
> it gets
> > to edit the Wikipedia.
>
> *cough*
> parametrized templates
> mathematical expressions
> embedded LaTeX
> advanced image thumbnail syntax
> magic words
> EasyTimeline
> wiki table syntax
> commons integration
> watchlists
> categories
> localization (to the point of pluralization algorithms for particular
> languages)
> ...

Some of these things make it more complicated to edit the Wikipedia. Some of
these things make it easier.


from_name: Death Phoenix

subject: [WikiEN-l] newbie culture

body:
On 6/22/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
>
> Neil Harris wrote:
> > Arwel Parry wrote:
> >> In message
> >> <980278fa0606171146h719fef74g2bc6333b4d42e826 at mail.gmail.com>, John
> >> Lyden <rasputinaxp-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> writes
> >>
> >>> On 6/17/06, Conrad Dunkerson
> >>> <conrad.dunkerson-XfrvlLN1Pqtfpb/ySbbPhw at public.gmane.org> wrote:
> >>>
> >>>> Ok, stop... you're making me all nostalgic. I think it all started to
> go
> >>>> downhill when the modems became capable of transferring text faster
> than
> >>>> you could read it (aka 2400 baud). :]
> >>>>
> >>> By that measure, my downhill was 9600 baud.
> >>>
> >>> Of course, I jumped right from my 1200 baud Multitech to a 14.4K on my
> >>> 486. Jump to lightspeed!
> >>>
> >> Some of us started out on 10 c.p.s. teletypes and input our first
> >> programs on paper tape....
> >>
> >>
> > Paper tape? Luxury. What's wrong with toggling your programs in using
> > the panel switches?
> >
>
> (mutters something about the luxury of switches and having to rely on
> compass needles twiddling and having to wave magnets, uphill both ways
> in the snow)
>

In my day, our computers and calculators were our fingers and toes. I could
only count to eighteen because I lost my pinky and big toe hunting wooly
mammoths.

(uphill, both ways, in the snow)


from_name: Emmanuel Engelhart

body:
Is there a chance to get a dump of all pictures (or/and thumbnailed
versions) used in the french wikipedia if :
- I give a list of pictures
- I give the script to get this list of pictures
- I give the script to store the files in a directory tree.

I currently work to propose a offline-reader prototype (with the french
wikipedia content) working without (mysql, apache, mediawiki) , and the lack
of pictures is almost the last problem I can't solve.

Emmanuel

2006/6/21, Emmanuel Engelhart <emmanuel.engelhart at wikimedia.fr>:
>
> Hi
>
> I tried to set up a local french Wikipedia on my personal computer.
> I didn't find any way to get the complete dump of all pictures used in our
> french articles.
> There is a dump from commons and fr at download.wikimedia.org/images/, but
> I don't want to download almost 300 Go to be sure to have all needed
> pictures.
>
> Can't someone light me ?
>
> Best regards
>
> Emmanuel [Kelson]
>


body:
On 6/22/06, Jimmy Wales <jwales at wikia.com> wrote:
> Mark Gallagher wrote:
> > We've all seen users completely blocked because of a regrettable
> > tendency to upload copyvios or create POV forks or move-war.  Now, they
> > could be otherwise intelligent people who think they know about
> > copyright law but don't; or useful contributors when they're being
> > supervised by other people on controversial articles, but who feel free
> > to let rip on their "own" fork articles; or people who insist on
> > treating the "move" button as a toy and causing unnecessary work for
> > admins and unnecessary stress for non-admins.  In that last case, Curps'
> > bot caught at least one offender, but that's hardly reliable.
>
> It is unclear to me that there really are that many cases of people who
> are extremely annoying in some areas, but whose help would be so
> valuable in other areas.

A great many users, including some of our most prolific editors, have
no clue about image copyright law or policy.  The ability to block
them from uploading images would be quite useful.

What would be even more useful would be for image uploading to be a
privilege, not a right: you don't get the ability to upload images
simply by registering an account.

--
Mark
[[User:Carnildo]]


from_name: Brion Vibber

body:
Chad Perrin wrote:
> On Thu, Jun 22, 2006 at 08:17:42AM -0700, Brion Vibber wrote:
>> Luckily we've already got one: –
>>
>> Damn typography snobs... ;)
>
> That may look like a joke, but I agree -- endashes are rare enough in
> comparison that it seems that if one of the two is going to be somewhat
> unintuitive, it should be the endash, and thus the HTML entity strikes
> me as a good answer to the problem.

Sure, I'd consider the endash to be entirely ignorable from a perspective of
what common people actually expect to be able to use, type, and see.

> Would requiring spaces on either side of the double dash before
> converting it into an emdash improve the parsing behavior any?

No; the conversion simply needs to be smart enough not to damage markup, but to
instead operate only in plain text areas. (Additionally it probably ought to
exclude itself from areas like <pre>, <tt>, and <code>.)

>  It
> should at least solve the image name problem, since spaces in image
> names should (in my honest opinion) be considered a no-no in any case.
> Then again, I'm not in charge, of course.

On the contrary, spaces are highly recommended in image names. Names should be
descriptive; "Lake McFoobar viewed from Mount Baz lookout point.jpg" is strongly
preferred to, say, "DSC000247.JPG".

Note that images' names are going to be more and more decoupled from their
physical filenames in the future; the file extension won't have to be maintained
as part of the wiki name for it and it will be possible to change names after
uploading.

-- 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/20060622/1268df5c/attachment.pgp>


from_name: Ray Saintonge

subject: [Foundation-l] Re : on (re)organizing wikimedia

body:
Birgitte SB wrote:

>I certainly don't want to see an advisory group of 50%
>en.WP editors!  However such token represntation as
>proposed in the Wikicouncil plan would be of little
>practical benifit.  It would be better to appoint (or
>nominate a short list for election) an advisory board
>with an purposeful effort to include editors from both
>all types of sister projects and communities of
>different sizes while keeping the number of people
>within reason.  Another option is to encourage
>different projects to each form their own sort of
>council and each can endorse ideas or write proposals
>with the unique goals of each project in mind.  Those
>are just two rough ideas, there are certainly many
>other alternatives.
>
>I believe it is most important that the input of small
>languages and non-pedia projects is taken into
>conderation in any such advisory council.  Not that
>every editor is given proportional representation.
>The latter would either be too much dominated by en.WP
>or else too large to offer useful and timely advice.
>Honestly the concerns of en.WP are being heard every
>day and would still be heard if they had not a single
>seat on such a council (I am not suggesting that!).
>The real need for such a council is to find out the
>needs/opinions of the smaller projects/lang.
>communities which are not currently being heard.
>
Wikicouncil would certainly be a possible body to oversee overall
day-to-day operations.  It could function in addition to a governing
Board AND and advisory board.

A governing Board somewhat larger than the present Board would have the
reponsibility of safeguarding assets and core policy, as well as
fulfilling legal responsibilities.  It should not be dominated by any
one nation.  A majority should be elected (directly or indirectly) by
the community, but the community should not have 75% of the positions on
the Board.  The remainder of the Board could be appointed in some
suitable way.  A full 75% of the Board members would still be required
to change core values.

An advisory Board could be of indefinite size, completely appointed, and
composed of eminent persons from within and without the community.  Its
function would be simply to advise, and it would have no decision making
powers.

A Wikicouncil needs to represent three broad groups: languages,
countries and overall projects.  It needs to avoid domination by any one
group or sub-group, and at the same time it needs to avoid becoming so
large as to become unwieldy.  The size of the Wikicouncil can be
open-ended but still include policies to slow the growth.

Groups and sub-groups all need a large degree of autonomy, and a higher
level of governance should have its right to impose policies clearly
restricted.  The recommended governance scheme for sub-groups needs to
vary in relation to the size of the group.

For countries it would be easy to suggest one seat for each national
chapter as the initial model, but this could change as the chapter idea
becomes more developed.  Currently there is still only a handful of
chapters concentrated in countries with functional education systems and
internet access, and no account is taken of the size or etnic
diversities of countries.  I think that issues such as whether US
representation should be allocated to states or judicial districts or
whether Belgium should have separate French and Flemish representatives
will need to wait for a later stage of development.

For projects, size matters.  Number of articles is an easy metric to
work with for the sake of these comments.  A metric that also reflects
active membership and the number of megabytes of data in a project may
be more accurate if it can be developed.  I could allow for the fact
that Wiktionay finds stubs perfectly acceptable, or in Wikisource it
could cope with decisions of whether a given book is all on one page or
divided into chapters.

Basing this on the completely arbitrary metric of 25,000 main namespace
articles in a language on any project with that many articles would be
guaranteed one seat on the Wikicouncil.  Smaller languages within that
project would be able to combine their numbers to receive one seat for
each 25,000 articles.  Larger languages within a project on a sliding,
perhaps logarithmic, scale.

Ec


subject: [Wikipedia-l] Sort?

body:
Berto wrote:
> How do I implement a localised sort criteria?
>
> A B C D E ? F G H I J L M N N- O ? P Q R S T U V Z
>
> So I need the accented letters to come in right places in lists... thank God
> there is NO word starting with N-, so we can simply forget about it.

For sorting of pages within category listings, you can manually specify a 'sort
key' which will be used for sorting instead of the page title as listed.

Since eg 'N-ame' will sort before 'Name' you could fake the sort key using ~,
which will sort after:

[[Category:Sorted pages|Name]]
[[Category:Sorted pages|N~ame]]

(However this will not show the separate letter as a heading in the list.)

For now the actual sorting is done by unicode code point, which is far from
ideal, but that's the situation at present.

> Yet we do use ? ? ? ? ? ? that are NOT letters, but only accents. So this
> ones should simply be ignored. It would also be nice if the search would be
> able to find "P?gina" by a wrong request for "pagina". That is, if it could
> ignore accents (apart from ? and ?, as they are proper letters).

I'm working on fixes to the search; this should improve in the coming weeks.

-- 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/wikipedia-l/attachments/20060622/535e0d1b/attachment.pgp


body:
Thx a lot Brion for your quick answer.
I will send you soon a list :-)

Emmanuel

2006/6/22, Brion Vibber <brion at pobox.com>:
>
> Emmanuel Engelhart wrote:
> > Is there a chance to get a dump of all pictures (or/and thumbnailed
> > versions) used in the french wikipedia if :
> > - I give a list of pictures
> > - I give the script to get this list of pictures
> > - I give the script to store the files in a directory tree.
> >
> > I currently work to propose a offline-reader prototype (with the french
> > wikipedia content) working without (mysql, apache, mediawiki) , and the
> lack
> > of pictures is almost the last problem I can't solve.
>
> Sure, we could do a temporary one for you until a more permanent solution
> is in
> place.
>
> Note that you can put together a list of used local and commons images
> relatively easily:
>
> 1) Grab 'image', 'imagelinks' tables for frwiki and 'image' table for
> commonswiki from download.wikimedia.org
>
> 2) The set of unique il_to values in imagelinks gives you the list of all
> base
> filenames.
>
> 3) Intersect the list with the img_name values in frwiki's image table.
> Those
> which match have files in wikipedia/fr.
>
> 4) Take the leftovers and intersect them with commonswiki's image table.
> Those
> which match have files in wikipedia/commons.
>
> 5) Throw away any left; those are references to nonexistent files.
>
>
> These lists will skip any unused image files.
>
> -- brion vibber (brion @ pobox.com)
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>


subject: [WikiEN-l] New York Times article

body:
On 6/21/06, Jimmy Wales <jwales at wikia.com> wrote:
> > These are reasonable questions. Jimbo implies that if P(t) is the
> > number of protected articles at time t, and S(t) is the proportion of
> > semi-protected articles, then:
> > P(now) << P(a year ago)
> > That is, that full protection on the whole has greatly decreased. But also that:
> >  P(now) + S(now) <= P(a year ago)
> > That is, that the total amount of articles off-limits to newbies has
> > not increased.
>
> I think that the first is true, and if not we should seriously look at
> why not.  I think that there is no reason for the second to be true.

First: Anyone notice the NYT correction?

Anyway, the more I consider the facts, the less convinced I am. The
problem is in the interpretation of "anyone can edit". Does it mean
"anyone who wants to edit, can", or does it mean "anyone at all can
edit". Normally this wouldn't matter, but it's critical if we're
attempting to measure "anyone-can-edit-ness" (ACEN).

By the first interpretation, we should take into account the fact that
most edits are made by confirmed users (I think?) If there is a shift
from total protection to semi-protection, then ACEN has gone up. The
measure P(now) < P (then) is the critical one, but P(now) + S(now) <=
P (then) should probably not totally be forgotten.

By the second interpretation, the vast hordes of potential visitors to
the site massively overwhelm the small number who actually carry out
the edits.Shifting towards semi-protection makes no difference at best
(either way they're blocked), so the critical comparison is P(now) +
S(now) <= P (then). The problem is that semi-protection lasts longer
than full protection, as a rule, so that in general this comparison is
far from true.

Semi-protection may indeed have been intended to improve openness and
ACEN, but based on my quick perusal of the protected articles list,
ACEN has gone down. Semi-protection is not the only cause of that (if
a cause at all) - but I think we should be honest about where we stand
now, compared to some arbitrary time in the past. I'm far from
convinced that NYT "got it exactly backwards" - it's a fairly subtle
question of interpretation of what ACE and "open" mean.

> I also think that a serious analysis should not look at the raw number
> of articles (the site is a lot bigger than a year ago, so there should
> be a lot more of everything) but both percentages of articles, and also
> percentages of articles weighted by pageviews and/or edit frequency.

Pageview figures would indeed be nice, for all kinds of statistics. No
one seems to have given a reason why pageview stats could not be
turned on for a day, just to give us some data to play with.

Steve


from_name: Chad Perrin

body:
On Thu, Jun 22, 2006 at 08:17:42AM -0700, Brion Vibber wrote:
> Steve Bennett wrote:
> > Heh, I see in this case it's been requested at least 3 times before.
> > Most of the discussion is on
> > http://bugzilla.wikimedia.org/show_bug.cgi?id=1485 and is quite
> > interesting - issues about when to convert to em-dash vs en-dash. The
> > discussion seems to boil down to: everyone agrees that -- to em-dash
> > is intuitive, but how do you then implement a syntax for en-dash for
> > the few people who want it?
>
> Luckily we've already got one: –
>
> Damn typography snobs... ;)

That may look like a joke, but I agree -- endashes are rare enough in
comparison that it seems that if one of the two is going to be somewhat
unintuitive, it should be the endash, and thus the HTML entity strikes
me as a good answer to the problem.

Would requiring spaces on either side of the double dash before
converting it into an emdash improve the parsing behavior any?  It
should at least solve the image name problem, since spaces in image
names should (in my honest opinion) be considered a no-no in any case.
Then again, I'm not in charge, of course.

I suppose I should go look at the bugzilla discussion now.  I seem to
recall, last time I looked at it, that the endash people were advocating
for -- being translated to endashes and --- to emdashes, which seems
counterintuitive for both, since endashes are supposed to be shorter
than - and emdashes have been represented as -- for so long and in so
many contexts that using three dashes will just confuse the heck out of
many.  Maybe I'm wrong, but I don't think so.

I'll shut up now and go read bugzilla discussion.  Sorry about the
ramble, just thinking "out loud".

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts." - Paul Graham