from_name: Ryan Wetherell

subject: [WikiEN-l] Fiction and Wikia

body:
I like this idea a lot.  Just an external link to a more relevant wiki
isn't really as attention-getting as it should be if people really
want to know more.

On 11/12/06, Phil Sandifer <Snowspinner at gmail.com> wrote:
> It occurs to me that many fictional worlds have superb wikis devoted
> to them over in Wikia. These Wikis are often doing exactly what we're
> trying to avoid doing in Wikipedia - providing large amounts of in-
> universe information.
>
> May I humbly suggest that articles on topics that are covered by such
> Wikia should have boxes at the bottom similar to the Wikiquote boxes
> that direct users to these wikis for an in-universe perspective. That
> is to say, clear, featured links to other projects that host the
> information we've decided isn't suitable for Wikipedia. (Noting that
> the reason for its unsuitability has nothing to do with its
> reliability, and everything to do with our focus.)
>
> Obviously this involves a bit of a paradigm shift, in that we would
> be linking to projects that are not, strictly speaking, sister
> projects. But if we're serious about moving this stuff out of
> Wikipedia (And I sincerely believe we should be serious about it if
> we want to have high-quality out-of-universe articles on Wikipedia,
> since to date nobody has managed to write an article that does both)
> we need to provide the people who use Wikipedia for this sort of
> information a clear alternative - not "go away and find somewhere
> else," but "go to this project over here."
>
> Are there any reasons someone with a good knowledge of template-fu
> shouldn't whip something like this up?
>
> -Phil
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
Who knows when we shall meet again (if ever)?
But time keeps flowin' like a river, to the sea...


list: commons-l

source: pipermail-mbox

from_name: Gregory Maxwell

subject: [Commons-l] Commons != kindergarden

body:
On 11/12/06, Anthony <wikilegal at inbox.org> wrote:
> At the worst backups should require twice as much space as the images
> themselves.  If Wikimedia's backups require much more Brion is doing
> something really really wrong.
>
> Note that I didn't even say hard drive space was cheap.  I just said
> it's cheaper than education.

*sigh*.
If only things were ever that simple.

Simply having 2x disks in the same chassis isn't a backup, and the
total costs for all complex things are non-linear.

> > More importantly: categorization, verification, search, etc are not
> > cheap. Nor is the time of the users we serve.  We'd do a great
> > disservice by allowing commons to become a disordered dumping ground.
>
> You contradict yourself.  Being a disordered dumping ground doesn't
> require categorization, verification, or search.

No I don't.
I suspect you've been confused by my befuddled English.

The avoidance of being a disordered dumping ground requires
non-trivial *per image* work for categorization, verification, etc.
"Upload all your trash" doesn't scale and will ensure that we are
never able to become well ordered... which is an outcome which would
diminish our value to the public.


list: wikitech-l

from_name: George Herbert

subject: [Wikitech-l] On style sheets

body:
On 11/12/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> On 11/12/06, Sebastian Moleski <sebmol at gmail.com> wrote:
> > On 11/12/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> > >
> > > On 11/12/06, Brion Vibber <brion at pobox.com> wrote:
> > > > I've reverted r17507 and r17518 after getting massive complaints
> > > > immediately after they went live in today's site update.
> > > >
> > > > I'd like to ask that people please try to refrain from changing core
> > > > styles like this without testing it against the actual site usage; for
> > > > instance the prominent main pages of English and German Wikipedia and
> > > > their site-specific CSS/JS.
> > > >
> > > > We've gone through this dance enough times in the last few weeks I think
> > > > we should all be able to realize that it's kind of disruptive and should
> > > > be avoided.
> > >
> > > Sorry, sorry . . . it's rather poor of me to constantly forget about
> > > custom styles when most of what I'm committing is UI stuff.
> > > Unfortunately some disruption is inevitable for this kind of stuff,
> > > which I suppose suggests it should be condensed and spaced out to the
> > > extent possible, with ample forewarning every time a batch is going to
> > > be committed.  Maybe I should make a branch where this kind of
> > > potentially disruptive stuff can be committed, and then we can let
> > > stuff accumulate there for a couple of months and until we announce
> > > all the changes and merge to trunk?  Does that sound like a good idea?
> > >
> >
> > Changes to the layout should be proposed before they are made. They need to
> > be tested with current wiki dumps on the largest projects so the actual
> > effects of the changes can be determined. Once that is done, common and skin
> > custom stylesheets can be adapted. And only after all that's done, they
> > should be committed.
> >
> > The current way of doing things is a nightmare from a customer service
> > position because users will notice that something's wrong, some of them will
> > ask at the VP or equivalents, and very few will even know what the problem
> > is or what caused it. So some of those few end up running to IRC to find a
> > developer who can help fix things by either reverting or explaining. All the
> > while, discussion continues, often at a level quite beyond what one would
> > expect based on the triviality of the actual issue. Then accusations are
> > made that somebody was arbitrarily deciding "major things" without process.
> >
> > Unfortunately, I'm not making this up. This actually all happened when the
> > category trees were added and the way category pages were displayed changed.
> > Ridiculous? Absolutely. Yet ample reason to work so it doesn't happen again.
>
> I don't think it's a good idea to jump through hoops when adding new
> features.  That's just silly.  Clear announcement is necessary when a
> change will *break preexisting functionality* such as user
> customizations.  I don't think discussion or announcement is necessary
> for the implementation of
> http://bugzilla.wikimedia.org/show_bug.cgi?id=1578, for instance.
>
> On 11/12/06, Luiz Augusto <lugusto at gmail.com> wrote:
> > Not related to this specific change, but since some weeks ago someone
> > changed something and now every table displayed in some namespaces in some
> > wikis is... white.
> >
> > Examples
> >
> > http://pt.wikisource.org/wiki/Especial:Newpages
> > http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost
>
> They were like that forever until I bugged the devs to supply a patch,
> but that broke other things so I reverted it later.  It's due to a
> flawed implementation of non-main-namespace coloring that many wikis
> have adopted, not a software issue: in Monobook the backgrounds of all
> namespaces are white.
>
> Adding the following to MediaWiki:Monobook.css *should* fix it
> (filling in the correct color instead of #F8FCFF, which is the color
> used by enwiki):
>
> table { background-color: #F8FCFF; }
> .ns-0 * table { background-color: white; }
> _______________________________________________

This brings up a dev/QA related question.

Is it possible to run multiple instances of Mediawiki all talking to
the same database (table sets, etc), assuming that the db formats
haven't changed between the Mediawiki versions used in those
instances?

What I'm thinking is that a beta.en.wikipedia.org instance wouldn't be
so bad, if it had the same data on the back end.

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


list: wikipedia-l

subject: [Wikipedia-l] Semi-protection

body:
On 11/12/06, Erik Moeller <erik at wikimedia.org> wrote:
> On 11/13/06, James Hare <messedrocker at gmail.com> wrote:
> > I believe it's been brought up to use an edit-approval program where new
> > accounts would have to get their edits approved if they're new -- this would
> > be in place of semiprotection.
>
> I oppose this. It undermines the assumption of good faith, whereas S-P
> is specifically used on pages that have a record of vandalism.

The ability to edit competently, accurately, and in conformity with
our standards (NPOV, BLP, TDMTLAOMG, etc) is a totally orthogonal
matter with a persons interest in editing with good intentions.  Some
of the most harmful problem material which I've seen inserted into
Wikipedia was inserted with good intentions.

Recognizing the contributions of very new contributors as needing a
higher degree of vetting than contributions from known and established
members of community isn't a failure to assume good faith, it is
actually an honest acceptance of the real challenges which face our
projects.

The ideal form for this additional vetting is no where near as clear
as the need for it, of course.

Personally, I've always been in favor of changes which reduce the
exposure of completely unchecked material to the general public who is
generally unaware and disinterested in the internal operation of
Wikipedia.  There are a number of people who oppose this notion, but I
wonder if their tune will change after the first highly publicized
death which can be linked back to obviously incorrect information in
Wikipedia.

> It makes more sense to expand the protection model to allow for
> auto-expiry (as well as automatic labeling of protected pages).

Without seeing some data on the current distribution of semiprotection
lifetimes, I couldn't comment on the usefulness of automatic
de(semi-)protection.  I looked at protection lifetimes some time ago
(back when folks like Tony Sidaway were around and diligent with
removing old protections) and we looked like we were doing pretty
well.


subject: [Wikipedia-l] Semi-protection

body:
On 11/12/06, Luna <lunasantin at gmail.com> wrote:
> Auto-expiring protection sounds like a very interesting idea -- has anybody
> submitted this to  Bugzilla?

That would be a waste of developer time. If you want it on your
project it would be trivial to sysop a bot account and have a bot
perform it.  A bot would be far more flexible (i.e. it could leave a
note for the admin that protected it, etc).


from_name: Sebastian Moleski

subject: [Wikitech-l] On style sheets

body:
On 11/12/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
>
> On 11/12/06, Brion Vibber <brion at pobox.com> wrote:
> > I've reverted r17507 and r17518 after getting massive complaints
> > immediately after they went live in today's site update.
> >
> > I'd like to ask that people please try to refrain from changing core
> > styles like this without testing it against the actual site usage; for
> > instance the prominent main pages of English and German Wikipedia and
> > their site-specific CSS/JS.
> >
> > We've gone through this dance enough times in the last few weeks I think
> > we should all be able to realize that it's kind of disruptive and should
> > be avoided.
>
> Sorry, sorry . . . it's rather poor of me to constantly forget about
> custom styles when most of what I'm committing is UI stuff.
> Unfortunately some disruption is inevitable for this kind of stuff,
> which I suppose suggests it should be condensed and spaced out to the
> extent possible, with ample forewarning every time a batch is going to
> be committed.  Maybe I should make a branch where this kind of
> potentially disruptive stuff can be committed, and then we can let
> stuff accumulate there for a couple of months and until we announce
> all the changes and merge to trunk?  Does that sound like a good idea?
>

Changes to the layout should be proposed before they are made. They need to
be tested with current wiki dumps on the largest projects so the actual
effects of the changes can be determined. Once that is done, common and skin
custom stylesheets can be adapted. And only after all that's done, they
should be committed.

The current way of doing things is a nightmare from a customer service
position because users will notice that something's wrong, some of them will
ask at the VP or equivalents, and very few will even know what the problem
is or what caused it. So some of those few end up running to IRC to find a
developer who can help fix things by either reverting or explaining. All the
while, discussion continues, often at a level quite beyond what one would
expect based on the triviality of the actual issue. Then accusations are
made that somebody was arbitrarily deciding "major things" without process.

Unfortunately, I'm not making this up. This actually all happened when the
category trees were added and the way category pages were displayed changed.
Ridiculous? Absolutely. Yet ample reason to work so it doesn't happen again.

sebmol


from_name: Anthony

subject: [Commons-l] Commons != kindergarden

body:
On 11/12/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On 11/12/06, Anthony <wikilegal at inbox.org> wrote:
> > At the worst backups should require twice as much space as the images
> > themselves.  If Wikimedia's backups require much more Brion is doing
> > something really really wrong.
> >
> > Note that I didn't even say hard drive space was cheap.  I just said
> > it's cheaper than education.
>
> *sigh*.
> If only things were ever that simple.
>
> Simply having 2x disks in the same chassis isn't a backup, and the
> total costs for all complex things are non-linear.
>
Rotating tapes offsite is a backup.  Transferring everything to two
other data centers is a backup (put those data centers on different
continents and it's a local cache too).  Backup isn't a complex thing.
 And unless you're doing something dumb the cost of backup is most
certainly linear (compared to the cost of the initial storage).

Put the image dumps in gigabyte chunks on a superseeding bittorrent
server, and you could probably get backups nearly free (just the cost
of transferring the images once if you can convince enough others to
act as seeds, which you probably could).  Of course, now I'm talking
introducing a bit of design into things.  Really stupid easy backups
like the ones in my first message are still linear.

> > > More importantly: categorization, verification, search, etc are not
> > > cheap. Nor is the time of the users we serve.  We'd do a great
> > > disservice by allowing commons to become a disordered dumping ground.
> >
> > You contradict yourself.  Being a disordered dumping ground doesn't
> > require categorization, verification, or search.
>
> No I don't.
> I suspect you've been confused by my befuddled English.
>
> The avoidance of being a disordered dumping ground requires
> non-trivial *per image* work for categorization, verification, etc.
> "Upload all your trash" doesn't scale and will ensure that we are
> never able to become well ordered... which is an outcome which would
> diminish our value to the public.

I'd say that "explain[ing to] people that not every ''shitty image''
they produce
is worth publishing on Wikimedia projects" doesn't scale either, and
that an image repository with some parts which are organized and some
parts which aren't has an equal or even higher value than an image
repository without those disorganized parts.

Of course, space *is* a consideration, and it wouldn't make sense to
outright advertise "dump all your trash here".  By all means rules
should be in place that say that useless crap will be deleted.  And
sure, if space gets tight that rule might need to be enforced to a
greater extent than when it isn't.  But trying to explain to people
what should be obvious, that I'd say is a waste of resources.

Anthony


list: wikien-l

from_name: Bryan Derksen

subject: [WikiEN-l] An observation

body:
Alphax (Wikipedia email) wrote:
> Yes, there are already too many teenagers here. Suggest we ban anyone
> not of legal drinking age (which for the more progressive countries,
> allows younger editors). Require all editors to drink while editing can
> come later...

And, of course:
http://meta.wikimedia.org/wiki/Friends_of_gays_should_not_be_allowed_to_edit_articles

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


from_name: geni

subject: [Commons-l] Commons != kindergarden

body:
On 11/12/06, David Gerard <dgerard at gmail.com> wrote:
> For the same reason anyone can edit. Our usual practice is to get the
> maximal contribution input then clean it up afterward, rather than try
> to limit it before the fact.

And as a result we still have a load of stuff in [[en:Category:Images
used with permission]] and my talk page is filling up with people
complaining that I keep deleting their images.

We also have issues such as trying to dig figure out when a copyvio
entered an article and according to certian message board posts people
getting threatening letters for useing wikipedia images in good faith.

For once it would be nice not to have to try and play catch up.

--
geni


subject: [Commons-l] Deleting images

body:
On 11/12/06, Lennert B?hm <lennert.boehm at gmx.de> wrote:
> While we are on the topic of too much work and not enough people to do it:
> Tonight I felt particularly motivated and decided to make myself useful
> deleting superseded images. Trusting the people who had posted those
> images there I made my way through the first dozen or so of the list, when
> I suddenly decided it might be a good idea, just to be on the safe side,
> to perform a check-usage on those images. Turns out some of those images
> weren't only used on one or two Wikipedias, but more than a dozen. So I
> ended up undeleting most of the images, because I really got better things
> to do than first check all those images if they're still in use somewhere,
> and then making I don't know how many edits in as many Wikipedias changing
> the links.
> So I think if we ever won't to work off the backlog we have accumulated we
> either "train" the normal users to fix the links when they add the images
> there or we find some possibility to do it automatically using bots
> running parallely on all WPs or something.
> I don't know if that's possible to implement, but I for myself have better
> things to do than do all of this by hand.
>
> Lennert B

You need orphanbot or a version of it.

--
geni


from_name: David Gerard

subject: [WikiEN-l] An observation

body:
On 12/11/06, Ryan Wetherell <renardius at gmail.com> wrote:
> On 11/12/06, Phil Sandifer <Snowspinner at gmail.com> wrote:

> > None of these involve establishing quotas - they involve considering
> > issues of gender (or race, or sexuality, or anything else you're
> > invested in here) in making choices.

> That's all fine and good, but it just seems irrelevant and
> out-of-touch with Wikipedia's open nature.  I see it as inherently
> unfair to evaluate somebody based on what they are-and-can't-change.

It's more a recognition of systemic bias and that this is probably not
a good thing.

- d.


from_name: Lennert Böhm

subject: [Commons-l] Deleting images

body:
While we are on the topic of too much work and not enough people to do it:
Tonight I felt particularly motivated and decided to make myself useful
deleting superseded images. Trusting the people who had posted those
images there I made my way through the first dozen or so of the list, when
I suddenly decided it might be a good idea, just to be on the safe side,
to perform a check-usage on those images. Turns out some of those images
weren't only used on one or two Wikipedias, but more than a dozen. So I
ended up undeleting most of the images, because I really got better things
to do than first check all those images if they're still in use somewhere,
and then making I don't know how many edits in as many Wikipedias changing
the links.
So I think if we ever won't to work off the backlog we have accumulated we
either "train" the normal users to fix the links when they add the images
there or we find some possibility to do it automatically using bots
running parallely on all WPs or something.
I don't know if that's possible to implement, but I for myself have better
things to do than do all of this by hand.

Lennert B


from_name: Phil Sandifer

subject: [WikiEN-l] An observation

body:
On Nov 12, 2006, at 9:46 PM, Alphax (Wikipedia email) wrote:

>
> Yes, there are already too many teenagers here. Suggest we ban anyone
> not of legal drinking age (which for the more progressive countries,
> allows younger editors). Require all editors to drink while editing
> can
> come later...

I figured we'd implemented mandatory drinking ages ago. I mean, how
else to explain RFA?

-Phil


from_name: Siebrand Mazeland

subject:
[Commons-l] Orphaning/placing Commons images on wikis (was:
	Deleting images)

body:
Lennart, geni,

This bot is already there and also appears to have full community support,
at least as long as removing images is the topic (mainly copyvio deletions).
AFAIK there is no full time bot process for image replacement (superseded,
duplicate, e.a.), although that sounds trivial.

Links:
- http://meta.wikimedia.org/wiki/User:CommonsDelinker (bot page)
- http://meta.wikimedia.org/wiki/Requests_for_permissions/CommonsDelinker
(request for permission)
- http://commons.wikimedia.org/wiki/User:Orgullomoore (bot operator)

Sadly, though, the bot operator got overtaken by real life and has been idle
for over a month. I guess any experienced bot operator willing to take a
sh*tload of crap whenever the bot does not do a good job can contact
Orgullomoore and see if he can maybe take over the project.

Cheers!

Siebrand

-----Oorspronkelijk bericht-----
Van: commons-l-bounces at wikimedia.org
[mailto:commons-l-bounces at wikimedia.org] Namens geni
Verzonden: zondag 12 november 2006 23:01
Aan: Wikimedia Commons Discussion List
Onderwerp: Re: [Commons-l] Deleting images

On 11/12/06, Lennert B?hm <lennert.boehm at gmx.de> wrote:
> While we are on the topic of too much work and not enough people to do it:
> Tonight I felt particularly motivated and decided to make myself
> useful deleting superseded images. Trusting the people who had posted
> those images there I made my way through the first dozen or so of the
> list, when I suddenly decided it might be a good idea, just to be on
> the safe side, to perform a check-usage on those images. Turns out
> some of those images weren't only used on one or two Wikipedias, but
> more than a dozen. So I ended up undeleting most of the images,
> because I really got better things to do than first check all those
> images if they're still in use somewhere, and then making I don't know
> how many edits in as many Wikipedias changing the links.
> So I think if we ever won't to work off the backlog we have
> accumulated we either "train" the normal users to fix the links when
> they add the images there or we find some possibility to do it
> automatically using bots running parallely on all WPs or something.
> I don't know if that's possible to implement, but I for myself have
> better things to do than do all of this by hand.
>
> Lennert B

You need orphanbot or a version of it.

--
geni
_______________________________________________
Commons-l mailing list
Commons-l at wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/commons-l


from_name: Oldak Quill

subject: [Wikipedia-l] Google's experimental/feedback search engine

body:
Just reading a slashdot article
(http://slashdot.org/articles/06/11/12/1425219.shtml) about an
unbranded test search engine (http://www.searchmash.com/) created by
Google to "test innovative user interfaces in order to continually
improve the overall search experience for our users".

Upon searching it asks the user for feedback:
> Were these results useful to you?
> Web Pages Yes / No
> Images Yes / No
> Wikipedia Yes / No

I suppose Google is trying to see whether users actually like getting
Wikipedia results so much. The outcome of this feedback could have an
impact upon us.

--
Oldak Quill (oldakquill at gmail.com)


subject: [WikiEN-l] An observation

body:
On 12/11/06, Ryan Wetherell <renardius at gmail.com> wrote:

> Oh, "systematic bias", that's exactly the term I was looking for.

Not quite ;-) "systematic bias" implies it's deliberate; "systemic
bias" implies it isn't, and is a symptom of something about the system
itself.

[[Wikipedia:WikiProject Countering systemic bias]]

- d.


subject: [WikiEN-l] Kill CSD A7!

body:
On 11/12/06, Brian Salter-Duke <b_duke at bigpond.net.au> wrote:
> Killing with a stick is top-down admin activity that prevents others
> from actually knowing what it was that was killed.

They are free to ask.

> I would prefer
> killing by consensus after the community has at least had an opportunity
> to see it.

I've deleted over 400 items to far this month. how much time were you
planning to spend reviewing them?

>How much good stuff is going down the gurgler because of
> speedy deletion by admins who know nothing about what the article was
> about and that it needed help and TLC not killing?
>

We have no shortage of articles in need of TLC. The cleanup backlogs
seem to be as long as ever.
--
geni


subject: [WikiEN-l] An observation

body:
On 11/12/06, Phil Sandifer <Snowspinner at gmail.com> wrote:
> In other words, systemic bias is when our administrator and
> arbitrator pools are disproportionately white American males.
> Systematic bias is when I went and banned all of the black Australian
> women on Wikipedia last night.
>
> -Phil

we appear to have more europeans than you would expect.

--
geni


subject: [WikiEN-l] Fiction and Wikia

body:
It occurs to me that many fictional worlds have superb wikis devoted
to them over in Wikia. These Wikis are often doing exactly what we're
trying to avoid doing in Wikipedia - providing large amounts of in-
universe information.

May I humbly suggest that articles on topics that are covered by such
Wikia should have boxes at the bottom similar to the Wikiquote boxes
that direct users to these wikis for an in-universe perspective. That
is to say, clear, featured links to other projects that host the
information we've decided isn't suitable for Wikipedia. (Noting that
the reason for its unsuitability has nothing to do with its
reliability, and everything to do with our focus.)

Obviously this involves a bit of a paradigm shift, in that we would
be linking to projects that are not, strictly speaking, sister
projects. But if we're serious about moving this stuff out of
Wikipedia (And I sincerely believe we should be serious about it if
we want to have high-quality out-of-universe articles on Wikipedia,
since to date nobody has managed to write an article that does both)
we need to provide the people who use Wikipedia for this sort of
information a clear alternative - not "go away and find somewhere
else," but "go to this project over here."

Are there any reasons someone with a good knowledge of template-fu
shouldn't whip something like this up?

-Phil


from_name: brion at pobox.com

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

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

Reading tests from "/home/brion/src/wiki/phase3/maintenance/parserTests.txt"...
Running test TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test TODO: Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test TODO: Template with thumb image (with link in description)... FAILED!
Running test TODO: message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test TODO: 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 TODO: HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test TODO: HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test Fuzz testing: image with bogus manual thumbnail... FAILED!
Running test TODO: Parsing optional HTML elements (Bug 6171)... FAILED!
Running test TODO: Inline HTML vs wiki block nesting... FAILED!
Running test TODO: Mixing markup for italics and bold... FAILED!
Running test TODO: 5 quotes, code coverage +1 line... FAILED!
Running test TODO: HTML Hex character encoding.... FAILED!
Running test TODO: dt/dd/dl test... FAILED!

Reading tests from "/home/brion/src/wiki/phase3/extensions/Cite/citeParserTests.txt"...

Passed 435 of 452 tests (96.24%)... FAILED!


from_name: Neil Harris

subject: [Wikitech-l] AntiSpoof issues

body:
Steve Summit wrote:
> Tim Starling wrote:
>
>> If we merge all these pairs into a set, following the relations, we obtain
>> the result that latin n is the same as latin H. This is incorrect, and is
>> the cause of most of the bizarre false positives that we see with AntiSpoof.
>>
>> The problem is that merging sets is fairly fundamental to the way AntiSpoof
>> works....
>>
>
> Clearly a more flexible/sophisticated approach, rather than
> calling all these characters "equivalent", would be to assign
> some quantitative visual difference between them, and when
> traversing a chain such as n -> eta -> Eta -> H, to sum the
> numbers (or something) rather than considering the equivalences
> to be a purely transitive relationship.
>
> But obviously that's much more expensive than computing, storing,
> and indexing a single canonical representation for each string.
>
> A hybrid approach I've contemplated (but not implemented, so I
> can't prove it works) is to use the canonical representations to
> generate expansive sets of candidate collisions, but then to do
> a more sophisticated (perhaps distance-based) comparison of just
> those candidates, to weed out the false positives.
>
>
I have already discussed something exactly like the above in E-mail.

As you have suggested above, the idea was to use the big dumb
equivalence set table as a first hack to spot possible spoof candidates,
and then to apply more sophisticaed processing using, among other
things, the UTR#39 confusables.txt tables on up to N of the spoof
candidates, falling back to the dumb algorithm if the number of
candidates exceeds N, where N is perhaps 20. (This limit is needed to
avoid denial of service attacks via the antispoof algorithm.)

Indeed, if this is implemented, the canonicalization function could be
made even more of a catch-all, allow ing the catching of even more
nasties than the existing code, since the second, more sophisticated,
pass would then be able to clean up the larger number of false positives
that would be generated by a more aggressive first pass.

I'd be happy to code this up in Python, for translation into PHP.
> Anyone interested in this issue should consult Unicode Technical
> Standard #39, "Unicode Security Mechanisms", at <http://www.unicode.org/
> reports/tr39/>.  In particular, its discussion of "confusables"
> is basically the same issue we're talking about here.  See also
> the Unicode data file "confusables.txt".
>
>

I'm actively working on this label-spoofing problem for another project,
so I'm well aware of UTR #39. As Tim has observed, the current
equivalence sets are the transitive closure of the equivalence relations
in UTR #39's confusables.txt file (plus some extra nasties), the Unicode
uppercasing relationships, and the relationships created by discarding
combining marks to uncover the base character. The script-mixing
constraints are also taken directly from UTR#39.

I've also got some suggestions that could be added to tighten up the
existing integration into MediaWiki, by dealing with a couple of edge
cases that are currently less than optimal.

-- Neil


subject: [Wikitech-l] AntiSpoof issues

references:
<ej7f1l$9l7$1@sea.gmane.org> <4557C162.3060807@tonal.clara.co.uk>
	<ej8rfq$vrt$1@sea.gmane.org>

body:
On 11/12/06, Tim Starling <tstarling at wikimedia.org> wrote:
[snip]
> There is a need for judgement, regardless of the software in use. Trolls
> will go on trolling regardless of what anti-spoofing restrictions we have in
> place. Our aim should be to minimise their impact, and heuristic systems
> with a high false positive rate do quite the opposite.

This note brings to mind an interesting homework assignment for the list...

Can we think of a good way to impliment "interactive intervention" in
mediawiki which neither adds weird backend requirements (works with
the nonpersistantness of php) or odd client requirements (no java or
the like).

The idea is that we have hundreds of people in IRC.. many people RC
patrolling.   There are *many* sorts of activities which software can
mark as suspect but which require judgement.  Is there a reasonable
way for us to get that judgement in real-time?


from_name: Steve Summit

subject: [WikiEN-l] Overuse of {{fact}}, redux

body:
Alphax wrote:
> http://en.wikipedia.org/wiki/List_of_faux_pas

Tags aside, I got a laugh out of

	India

	* It is advisable for men and women to avoid wearing
	  revealing and/or clothes in public.


subject: [Wikitech-l] AntiSpoof issues

body:
Tim Starling wrote:
> We've been having quite a few complaints about false positives from the
> AntiSpoof extension -- an extension which attempts to prevent registration
> of names which are confusingly similar to names already registered. Brion
> responded to these complaints with "get a sysop to make the account for
> you", but I don't think that's a very good solution. So I've been working on
> the AntiSpoof extension today, attempting to make it a bit more relaxed.
>
> The most fundamental problem is the problem of merging sets. Say if we want
> to treat visually similar characters as part of a set, and we also want to
> treat letters which are the same except for their case as part of a set. So,
> for example, say if we have the following pairs:
>
> ? (capital eta) = H (latin)
> ? (capital eta) = ? (lowercase eta)
> ? (lowercase eta) = n (latin)
>
> If we merge all these pairs into a set, following the relations, we obtain
> the result that latin n is the same as latin H. This is incorrect, and is
> the cause of most of the bizarre false positives that we see with AntiSpoof.
>
> The problem is that merging sets is fairly fundamental to the way AntiSpoof
> works -- i.e. by calculating a canonical representation of the username,
> storing it and indexing it. So it's not going to change any time soon unless
> we get really clever. But there are some things we can do to minimise its
> effects.
>
> The first and most obvious thing to do was to remove the transliteration
> pairs. These are pairs of characters where one member of the pair is a
> common phonetic transliteration of the other, e.g. cyrillic en "?" = latin
> E. This was the cause of most of the spurious conflations between latin
> characters. This should now be done.
>
> There are now three remaining categories of conflated character pairs: case
> folding, visual similarity and chinese traditional/simplified conversion.
>
> The second thing to do is to minimise cross-script pairs. Since cross-script
> usernames are disallowed, cross-script pairs are mostly redundant. You could
> make a case to leave some of them in, for example some latin usernames can
> be spoofed entirely using cyrillic characters. And some communities may have
> a special need for allowing a certain pair of scripts in a username (e.g.
> latin and hiragana). It's best if we can just keep the pairs which are
> visually very similar, and consciously avoid including cross-script pairs
> which will cause false conflations within scripts.
>
> I've done some work on this, but I think it's time to hand over the job to
> the community, if the community wants it. I've created a page with a big
> list of pairs, at:
>
> http://www.mediawiki.org/wiki/AntiSpoof/Equivalence_sets
>
> You can edit this page. I will update the live copy on request.
>
> Really clever ideas on how to avoid merging sets while maintaining good
> performance would be appreciated.
>
> Another misfeature in AntiSpoof which was causing false positives was the
> fact that it merged sequences of repeated characters. For example, Yuma was
> considered to be equal to Uma, because Y=U (from a transliteration pair),
> and UUma = Uma. I've removed this behaviour.
>
> I should really get a blog...
>
> -- Tim Starling
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Hi Tim;

I've already thought of this (see my recent E-mail on the Wikitech list
-- for some reason, I can't find the lengthy E-mail I thought I'd sent
earlier that I refer to there).

Fortunately, not much "real cleverness" is needed.

The basic idea is the one suggested by multiple posters on the list:
* an aggressive canonicalization process (which must still have the
transitivity requirement above)
* looking up candidates with matching canonical forms (up to some limit,
perhaps 20, to stop denial-of-service attacks)
* if #(candidates) > limit, treat as a spoof, to fail-safe
* then a second pass to do the checking _much_ more carefully, without
any need for transitivity or over-compression

I'd be happy to E-mail you an implementation in Python of the very
simple but more careful second-pass code, as a function
are_confusable_strings() that takes two Python strings as input, and
returns a boolean value. This can then be called from the PHP pass.

If we do this, we should be able to make the first pass even more
aggressive than it is currently, to catch more possible spoof
candidates, whilst still eliminating false positives in the second pass,
thus improving both the false-positive and false-negative rates to a
fraction of their current levels.

We should _not_ remove the cross-script pairs from the list, as there
are still whole-script confusables, eg "caxap", "soccer" --
surprisingly, 3% of English dictionary words have matching Cyrillic
spoofs, and 1% have Greek spoofs -- however, the second pass should
completely eliminate any problems caused by the transitivity in the
first pass.

-- Neil


body:
On 12/11/06, Oldak Quill <oldakquill at gmail.com> wrote:
> Just reading a slashdot article
> (http://slashdot.org/articles/06/11/12/1425219.shtml) about an
> unbranded test search engine (http://www.searchmash.com/) created by
> Google to "test innovative user interfaces in order to continually
> improve the overall search experience for our users".
>
> Upon searching it asks the user for feedback:
> > Were these results useful to you?
> > Web Pages Yes / No
> > Images Yes / No
> > Wikipedia Yes / No
>
> I suppose Google is trying to see whether users actually like getting
> Wikipedia results so much. The outcome of this feedback could have an
> impact upon us.

I don't think I quite made it clear that Wikipedia results are
displayed in a seperate box to the right of the main results.
Wikipedia results are still shown among the main results as well. See
eg.: http://www.searchmash.com/search/Stalin

--
Oldak Quill (oldakquill at gmail.com)


subject: [WikiEN-l] Overuse of {{fact}}, redux

body:
Alphax (Wikipedia email) wrote:
> http://en.wikipedia.org/wiki/List_of_faux_pas
>
> Highlighting specific examples is left as an exercise to the reader.

I don't see the problem, myself. There are lots and lots of statements
in this list that do need citations, if anything we're _missing_
{{fact}} on a lot of them (though the current crop is good enough for
starters so I didn't bother adding any more as I did a little reference
cleanup there just now).

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


subject: [WikiEN-l] Fiction and Wikia

body:
Phil Sandifer wrote:
> Obviously this involves a bit of a paradigm shift, in that we would
> be linking to projects that are not, strictly speaking, sister
> projects.

I'm not sure it'd be a good idea to use "official-looking" link
templates like the ones for Wikisource etc. to link to projects that
don't operate under the fundamental policies of Wikipedia like that. I
suspect it'll blur the line between
NPOV/Verifiable/non-original-research Wikipedia content and whatever
content standards they've got over there.

A set of templates with a different look-and-feel and perhaps an
appropriate disclaimer, on the other hand, might be better. We often
already have plain old external links anyway, though, so I'm not sure
it's needed.

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


from_name: Simetrical

subject: [Wikitech-l] On style sheets

body:
On 11/13/06, Nick Jenkins <nickpj at gmail.com> wrote:
> > What I'm thinking is that a beta.en.wikipedia.org instance wouldn't be
> > so bad, if it had the same data on the back end.
>
> Along a similar vein, would it help to have a public test wiki that always ran the absolute bleeding edge? (As opposed to
> test.wikipedia.org which runs an NFS checkout before the sync, and as such usually differs little from most of the Wikipedia sites).
> Example hostname: http://dogfood.wikipedia.org/ . That way keen people could try new stuff out earlier, and maybe we might get some
> feedback sooner, before changes impact the whole userbase, thus possibly resulting in greater harmony?

It would definitely be really spiffy if we had a public test wiki for
code, but I'm not sure running from trunk would be a good idea.  It
would encourage people to commit to trunk for testing, which is kind
of a Bad Idea.  Maybe a branch that's auto-synced with trunk every so
often or something, but the logistics could be tricky (how would it
resolve conflicts? would it clog up the SVN list?).


subject: [WikiEN-l] Overuse of {{fact}}, redux

body:
Angela wrote:
> Wouldn't it make more sense to move every unsourced statement to the
> talk page or elsewhere and add them back when they're sourced? I don't
> see how having {{fact}} on almost every line is helpful to readers of
> the article.

That'd be a tremendous amount of extra work and a nearly-empty article
with most of the content hidden away on talk isn't especially useful
either. Since most of the statements requiring citations don't appear to
be controversial, just unsupported, what's the harm of leaving them in
place in the meantime?

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


from_name: Tim Starling

subject: [Wikitech-l] AntiSpoof issues

body:
We've been having quite a few complaints about false positives from the
AntiSpoof extension -- an extension which attempts to prevent registration
of names which are confusingly similar to names already registered. Brion
responded to these complaints with "get a sysop to make the account for
you", but I don't think that's a very good solution. So I've been working on
the AntiSpoof extension today, attempting to make it a bit more relaxed.

The most fundamental problem is the problem of merging sets. Say if we want
to treat visually similar characters as part of a set, and we also want to
treat letters which are the same except for their case as part of a set. So,
for example, say if we have the following pairs:

? (capital eta) = H (latin)
? (capital eta) = ? (lowercase eta)
? (lowercase eta) = n (latin)

If we merge all these pairs into a set, following the relations, we obtain
the result that latin n is the same as latin H. This is incorrect, and is
the cause of most of the bizarre false positives that we see with AntiSpoof.

The problem is that merging sets is fairly fundamental to the way AntiSpoof
works -- i.e. by calculating a canonical representation of the username,
storing it and indexing it. So it's not going to change any time soon unless
we get really clever. But there are some things we can do to minimise its
effects.

The first and most obvious thing to do was to remove the transliteration
pairs. These are pairs of characters where one member of the pair is a
common phonetic transliteration of the other, e.g. cyrillic en "?" = latin
E. This was the cause of most of the spurious conflations between latin
characters. This should now be done.

There are now three remaining categories of conflated character pairs: case
folding, visual similarity and chinese traditional/simplified conversion.

The second thing to do is to minimise cross-script pairs. Since cross-script
usernames are disallowed, cross-script pairs are mostly redundant. You could
make a case to leave some of them in, for example some latin usernames can
be spoofed entirely using cyrillic characters. And some communities may have
a special need for allowing a certain pair of scripts in a username (e.g.
latin and hiragana). It's best if we can just keep the pairs which are
visually very similar, and consciously avoid including cross-script pairs
which will cause false conflations within scripts.

I've done some work on this, but I think it's time to hand over the job to
the community, if the community wants it. I've created a page with a big
list of pairs, at:

http://www.mediawiki.org/wiki/AntiSpoof/Equivalence_sets

You can edit this page. I will update the live copy on request.

Really clever ideas on how to avoid merging sets while maintaining good
performance would be appreciated.

Another misfeature in AntiSpoof which was causing false positives was the
fact that it merged sequences of repeated characters. For example, Yuma was
considered to be equal to Uma, because Y=U (from a transliteration pair),
and UUma = Uma. I've removed this behaviour.

I should really get a blog...

-- Tim Starling


from_name: Erik Moeller

subject: [Wikipedia-l] Semi-protection

body:
On 11/13/06, James Hare <messedrocker at gmail.com> wrote:
> I believe it's been brought up to use an edit-approval program where new
> accounts would have to get their edits approved if they're new -- this would
> be in place of semiprotection.

I oppose this. It undermines the assumption of good faith, whereas S-P
is specifically used on pages that have a record of vandalism.

It makes more sense to expand the protection model to allow for
auto-expiry (as well as automatic labeling of protected pages).
--
Peace & Love,
Erik

Member, Wikimedia Foundation Board of Trustees

DISCLAIMER: Unless otherwise stated, all views or opinions expressed
in this message are solely my own and do not represent an official
position of the Wikimedia Foundation or its Board of Trustees.


from_name: Dovi Jacobs

subject:
[Wikitech-l] Labeled Section Transclusion (need feedback on current
	status!)

body:
Over the past weeks and months, User:Sanbeg has quietly and modestly put a lot of work into "Labeled Section Transclusion" as an extension feature to the Wikimedia Software. This includes code for the extension, test cases, and a new page at the Mediawiki software website describing his extension, which may be found here:

http://www.mediawiki.org/wiki/Labeled_Section_Transclusion

While I knew that something was going on (I "subscribe" to the updates on the bug), I still wasn't fully aware of the extent of his work and of the amazing flexibility and numerous features that User:Sanbeg put into this new tool. It incorporates every single feature that I personally requested, all those that others requested, and even some new ones that none of us at Wikisource previously even thought of but look very useful. It looks so useful, in fact, that I have no doubt it will be put to a great many unforseen uses that even go beyond Wikisource.

To my mind, this is no longer really just a Wikisource extension (though Wikisource certainly could use it), but is already something global: a tool that expands the basic flexibility of transclusion within the Mediawiki environment.

The last time this was brought up by Birgitte, Brion responded (as best I remember) that it was best to hold back for the meantime because there was still not full Wikisource agreement (on the talk page) about how such a tool should function. That was probably true then, but it is certainly no longer the case, because this tool, once again, addresses every possible need that has been expressed by anyone (at least as far as I can tell).

So what we really need now is some developer feedback!

Dovi

---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.


from_name: Mark Williamson

subject:
[Wikipedia-l] Policy draft: Wikimedia projects are not the
	place for national constitution

body:
Well, I didn't read the page, but the way I read the _subject_, it's
absolutely incorrect.

True, a constitution does not belong at Wikipedia (or at least its
text doesn't). But it most certainly _does_ belong at Wikisource, so
long as it is free (and I don't believe a constitution can be
copyrighted, but I may be wrong there). We have a few different
constitutions at various Wikisources, and they should not be deleted.

Mark

On 13/11/06, Milos Rancic <millosh at gmail.com> wrote:
> Please, look at
> http://meta.wikimedia.org/wiki/Wikimedia_projects_are_not_the_place_for_national_constitution
>
> ... and give your ideas there.
>
> I think that the policy may be more exact.
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
Refije dirije lanm? yo paske nou posede pw?p bato.


body:
Ahh, I did read it now and I believe that "constitution" is not the
word you're aiming for. Yes, it does have the intended meaning, but in
the phrase "national constitution" it is usually referring to a
document by which a nation was founded and upon which all of its laws
are based.

I don't agree with the page because it seems like it was crafted
specifically by you with the idea to support the existance of separate
BCS Wikipedias (which is opposed by Jimbo, but will probably continue
for a long time), but to oppose the existance of Zlatiborian and
Montenegrin Wikipedias.

As has been noted in the past many, many, many times, Wikipedias are
for _languages_ not _countries_.

In Europe, the concept of language is very much tied to the concept of
the modern nation-state. But in many places this is not so. Take for
example Aromanian -- there is no nation-state. Or Romani. It is very
much an international language.

In fact, the majority of the world's languages (by which I mean
"legitimate" "established" "non-dialects" as given in the Ethnologue),
a total of nearly 7000, are not synonymous with a nation-state (there
are less than 300 of those, and many of them chose English, French, or
Spanish as their language anyways).

Besides that, who is to judge what differences are "significant"? We
would need objective measurements for each criterium.

Also, I don't see what the reason for this page is. Maybe you are
worried about whether or not the various Balkan Wikipedias should or
should not be separate, but nobody outside of that region is. The
issue is well behind us. Nobody is planning on closing sr.wp or bs.wp,
they have too many articles, and Zlatiborian and Montenegrin were
voted against in the proposals for new Wikis.

Also, your views disagree with the democratic majority in several places.

Mark

On 13/11/06, Mark Williamson <node.ue at gmail.com> wrote:
> Well, I didn't read the page, but the way I read the _subject_, it's
> absolutely incorrect.
>
> True, a constitution does not belong at Wikipedia (or at least its
> text doesn't). But it most certainly _does_ belong at Wikisource, so
> long as it is free (and I don't believe a constitution can be
> copyrighted, but I may be wrong there). We have a few different
> constitutions at various Wikisources, and they should not be deleted.
>
> Mark
>
> On 13/11/06, Milos Rancic <millosh at gmail.com> wrote:
> > Please, look at
> > http://meta.wikimedia.org/wiki/Wikimedia_projects_are_not_the_place_for_national_constitution
> >
> > ... and give your ideas there.
> >
> > I think that the policy may be more exact.
> > _______________________________________________
> > Wikipedia-l mailing list
> > Wikipedia-l at Wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> >
>
>
> --
> Refije dirije lanm? yo paske nou posede pw?p bato.
>

--
Refije dirije lanm? yo paske nou posede pw?p bato.


from_name: James Hare

subject: [WikiEN-l] Fiction and Wikia

body:
/me is trying not to think about how Erik just promoted his own website

In any case, I thought a while back that if Wikia had all these wikis, then
all the unsourced highly specific details could be exiled to these wikis. It
sounded like a good idea.

On 11/13/06, Erik Moeller <erik at wikimedia.org> wrote:
>
> On 11/13/06, Phil Sandifer <Snowspinner at gmail.com> wrote:
> > It occurs to me that many fictional worlds have superb wikis devoted
> > to them over in Wikia. These Wikis are often doing exactly what we're
> > trying to avoid doing in Wikipedia - providing large amounts of in-
> > universe information.
>
> True. Wikimedia is also strongly committed to free content, and so is
> Wikia. But so are other wikis which are not hosted on Wikia, such as
> Wikitravel. It would be unfair to prefer Wikia specifically. However,
> it would make sense, in my opinion, to build a network of free content
> websites. Fortunately there's already a definition we can use to
> identify those:
>
> http://freecontentdefinition.org/Definition
>
> Essentially, we could make a policy that any relevant external
> resource that meets the Free Content Definition may be linked in a
> more visible place than non-free resource. Going a bit beyond free
> licensing, we could also require that the site at least make complete
> dumps available on a regular basis, to enable community migration.
>
> --
> Peace & Love,
> Erik
>
> Member, Wikimedia Foundation Board of Trustees
>
> DISCLAIMER: Unless otherwise stated, all views or opinions expressed
> in this message are solely my own and do not represent an official
> position of the Wikimedia Foundation or its Board of Trustees.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [WikiEN-l] Overuse of {{fact}}, redux

body:
To mix two threads together, we can move it over to a Faux Pas Wikia. ;)

On 11/13/06, Angela <beesley at gmail.com> wrote:
>
> Wouldn't it make more sense to move every unsourced statement to the
> talk page or elsewhere and add them back when they're sourced? I don't
> see how having {{fact}} on almost every line is helpful to readers of
> the article.
>
> Angela.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Daniel P. B. Smith

subject: [WikiEN-l] Overuse of {{fact}}, redux

body:
> From: "Alphax (Wikipedia email)" <alphasigmax at gmail.com>
>
> http://en.wikipedia.org/wiki/List_of_faux_pas
>
> Highlighting specific examples is left as an exercise to the reader.

The only problem I see here is the longstanding problem that the
"citation needed" tag is overly conspicuous and intrusive. I'd like
to see this fixed somehow.

It's my belief that lists are especially prone to attract "drive-by"
additions of shoot-from-the-hip, hearsay material. The temptation to
say "Oooh! Oooh! I know one that they missed" is just so great.

Why, exactly, do you feel that there is no need to cite a published
source for a statement such as that "[in Switzerland] when clinking
glasses, it is an obligation to look into the eyes of the person
holding the other glass?"


body:
On 13/11/06, Milos Rancic <millosh at gmail.com> wrote:
> On 11/13/06, Mark Williamson <node.ue at gmail.com> wrote:
> BTW, what Ethnologue says for Zlatiborian and Zlatiborians? ;)

I'd totally forgotten about how oblivious you were. Responding to all
my points as if I were serious. Everyone else, even most of the
Serbians, were able to tell I was kidding. I was actually expressing
somewhat of a Pan-Yugoslav position through use of extreme sarcasm,
basically, that "now everybody tries to break off from the unitary
South Slavic nation". The intention wasn't specifically that but to
highlight how ridiculous it is that we have languages in 3 versions of
what can't even be called different _dialects_ of the same language
(maybe if you had one in Cakavian instead of "Croatian").

When you didn't get it at first, I decided to intensify the terms to
the point that it could _only_ be taken as humour ("shed the shackles
of ... oppression and slavery", "glorious illustrious wonderful
Zlatiborian language ... repressed by evil Serbians"). Your response
was not laughter but rather concern, and an assertion that "people
like me" should be "sentenced to death" (!), but that I could be
forgiven because of my age.

In the end, you were the one who came out looking like a fool, and the
"great worthy cause of the illustrious Zlatiborian culture oppressed
by the evil Serbian overlords" has become somewhat of an in-joke and I
have seen it used on several tech webpages.

People may have been incensed at first, but after a couple of my
e-mails pretty much everybody besides you reacted with good humour,
although the issue got kind of old after a while.

> You are completely missing the point. The intention of the document is
> to explain that Wikipedia should not be involved in constituing of new
> nations. And this is not the only condition for making Wikipedia.
> Including that there may be a general rule which says that very close
> languages shouldn't have separate Wikipedias (BCS, Lusatian, and so
> on).

But it is _completely irrelevant_. As I said, we do not have
Wikipedias for nations, but for languages. It is simply impossible to
use Wikipedia to build a new nation. To form a language where nothing
existed before, perhaps, but to build a new nation, no. It's not
possible, because _we do not create Wikipedias for nations!_.

> The main reason is discussion about Siberian Wikipedia. As you are

Siberian seems to be a bit more credible than Zlatiborian. Also,
Siberian got more supporters from disinterested 3rd parties. While the
existence of Siberian as a language is debatable, it is clear from
viewing any text in it that the words they are using are very
different from Russian.

Besides, although nation creation is mentioned often in the discussion
it is truly not relevant. What _is_ relevant are the merits of the
language itself. How many people speak it? How many people are willing
to edit its Wiki? etc.

> famous as someone who is supporting hoaxes, you have to me a good

I see you used the plural there. The only "hoax" I have supported is
Zlatiborian, and everybody but you knew I wasn't serious.

> lesson to be very sceptic about new languages. In the case of

Well, as a general rule this should be true. But not to the extent
that your rules have laid out.

> Siberian, it is very unclear how much people talk that artificial
> language. Besides that, there are also laughing in Novosibirsk about
> Siberian as a hoax, such on Zlatibor was a year ago about Zlatiborian

Well, I have yet to see anybody _in Siberia_ actually standing out
against the language. One Siberian person supported it, it seems, in
the initial voting. But other than that it seems the "real Siberians"
have remained silent.

Mark

--
Refije dirije lanm? yo paske nou posede pw?p bato.


subject: [WikiEN-l] Overuse of {{fact}}, redux

body:
Generally because everything in every article should be based on a published
source. That allows the article to be verified by third parties.

On 11/13/06, Daniel P. B. Smith <wikipedia2006 at dpbsmith.com> wrote:
>
> > From: "Alphax (Wikipedia email)" <alphasigmax at gmail.com>
> >
> > http://en.wikipedia.org/wiki/List_of_faux_pas
> >
> > Highlighting specific examples is left as an exercise to the reader.
>
> The only problem I see here is the longstanding problem that the
> "citation needed" tag is overly conspicuous and intrusive. I'd like
> to see this fixed somehow.
>
> It's my belief that lists are especially prone to attract "drive-by"
> additions of shoot-from-the-hip, hearsay material. The temptation to
> say "Oooh! Oooh! I know one that they missed" is just so great.
>
> Why, exactly, do you feel that there is no need to cite a published
> source for a statement such as that "[in Switzerland] when clinking
> glasses, it is an obligation to look into the eyes of the person
> holding the other glass?"
> _______________________________________________
> 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: Sean Barrett

subject: [WikiEN-l] Overuse of {{fact}}, redux

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

Angela stated for the record:
> Wouldn't it make more sense to move every unsourced statement to the
> talk page or elsewhere and add them back when they're sourced? I don't
> see how having {{fact}} on almost every line is helpful to readers of
> the article.

It serves the purpose of warning our readers that a large fraction of
that article is composed of [[Wikipedia:Complete bollocks]].

- --
 Sean Barrett     | Today's robots are very primitive, capable
 sean at epoptic.com | of understanding only a few simple
                  | instructions such as "go left," "go
                  | right," and "build car." --John Sladek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFWJBJ/SVOiq2uhHMRAr1JAJ46tI0fccjGEm18s8SMQHyqyRsp8wCfQGkl
NP4zGyvnfud3UtormYd26Kc=
=zQZE
-----END PGP SIGNATURE-----


from_name: Anthony

subject: [Commons-l] Principles of organisation - who do we serve?

body:
On 11/13/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
> Brion Vibber wrote:
> > Brianna Laugher wrote:
> >> On 12/11/06, Florian Straub <flominator at gmx.net> wrote:
> >>> Awesome! Is there any chance to activate it directly for new
> >>> registrations
> >>> on commons or do they people have to confirm their adresses first?
> >>
> >> Thanks, Brion. Specifically, could we require that new registered
> >> users must have a confirmed email address before uploading? With talk
> >> page email notifications as default setting.
> >
> > That's a complete about-face from Wikimedia's traditional policy of
> > allowing anonymous contributions, so before I set that up I'd need to
> > know this is acceptable to Wikimedia.
> >
>
> Anonymous text with the release "I wrote this" is one thing. Anonymous
> images are another.
>
Umm, why?

I never understood putting unnecessary barriers into place before
people are allowed to voluntarily contribute something.  It's one of
the reasons I haven't yet participated in the Citizendium project.

By the way, I've uploaded maybe around 100 images to commons, some of
which are used on multiple projects, and just about all of which are
anonymous.  Better get to work deleting them all.  Here's a link:
http://tools.wikimedia.de/~daniel/WikiSense/Gallery.php?wikifam=commons.wikimedia.org&wikilang=en&order=-img_timestamp&img_user_text=Anthony&ofs=0&max=250

Anthony


subject: [WikiEN-l] Fiction and Wikia

body:
On 11/13/06, Phil Sandifer <Snowspinner at gmail.com> wrote:
> It occurs to me that many fictional worlds have superb wikis devoted
> to them over in Wikia. These Wikis are often doing exactly what we're
> trying to avoid doing in Wikipedia - providing large amounts of in-
> universe information.

True. Wikimedia is also strongly committed to free content, and so is
Wikia. But so are other wikis which are not hosted on Wikia, such as
Wikitravel. It would be unfair to prefer Wikia specifically. However,
it would make sense, in my opinion, to build a network of free content
websites. Fortunately there's already a definition we can use to
identify those:

http://freecontentdefinition.org/Definition

Essentially, we could make a policy that any relevant external
resource that meets the Free Content Definition may be linked in a
more visible place than non-free resource. Going a bit beyond free
licensing, we could also require that the site at least make complete
dumps available on a regular basis, to enable community migration.

--
Peace & Love,
Erik

Member, Wikimedia Foundation Board of Trustees

DISCLAIMER: Unless otherwise stated, all views or opinions expressed
in this message are solely my own and do not represent an official
position of the Wikimedia Foundation or its Board of Trustees.


from_name: Brian Salter-Duke

subject: [WikiEN-l] Kill CSD A7!

body:
On Sun, Nov 12, 2006 at 02:22:30PM -0500, Phil Sandifer wrote:
>
>
> On Nov 12, 2006, at 2:06 PM, geni wrote:
>
> >On 11/12/06, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
> >>Isn't this pretty much exactly the reason we introduced PROD? If we
> >>can get more admins to patrol it, and get people to use it
> >>effectively, it might very well serve as a replacement for A7
> >>
> >>--Oskar
> >
> >Authors remove prods. Then what?
>
> I've long supported authors not being allowed to remove PRODs, as
> with CSDs.

I think this is a really bad idea. PRODs get put on articles that are
very new, so few people have probably seen them or got them on their
watchlist other than the author. It will just make many authors, who have
their work deleted with no opportunity to debate it, to go ballistic. I
have yet to have any of my creations PRODed, but if it happened I would
want to argue why I created it.

I would also suggest that articles that are put to AfD should not be
speedy deleted. Once thay are there give people a chance to see them and
comment. Maybe only cut short the closure if there are 20 delete "votes"
and no keep "votes". I often see a speedy closure of a AfD debate and
are curious about what was in it.

Brian.

> Best,
> Phil Sandifer
> sandifer at english.ufl.edu
>
> You are standing in an open field west of a white house, with a
> boarded front door. There is a small mailbox here.
>
> >
>
> ------------------------------

--
          Brian Salter-Duke            b_duke at bigpond.net.au
               [[User:Bduke]]  mainly on en:Wikipedia.
 Also on fr: Wikipedia, Meta-Wiki, WikiNews, WikiBooks and Commons


from_name: Magnus Manske

subject: [Wikitech-l] Geohack

body:
(sending this message again, as I somehow was unsubscribed from
wikitech-l for a while. Damn computers;-)

Hi all,

a long time ago, en:User:Egil wrote a great MediaWiki extension to
handle geographic coordinates, like ISBNs are handled by
Special:Booksources, and ran it off his server. When said server broke
down, and Egil was unreachable, I wrote a workaround [1] to run it as
a standalone script, and put it on the toolsever as a temporary
measure.

As it is tradition for temporary fixes, this one seems to have become
permanent ;-) with ~640000 hits in October, making up >8% of
toolserver traffic.

I wonder if this would be the time to add Egils extension to the
standard Wikipedia extension set. This would not only look more
seamless, and offer localized pages, but also take advantage of the
usual caching mechanisms. AFAIK, all that needs to be done is adding
the extension, copying the wikisource to a local page, and fix the geo
templates. This could be done gradually; unless the templates are
adapted, the default behaviour (using toolserver) won't change, even
if the extension is activated.

Magnus

[1] http://tools.wikimedia.de/~magnus/geo/geohack.php


from_name: Phil Sandifer

subject: [WikiEN-l] Fiction and Wikia

body:
On Nov 13, 2006, at 8:31 AM, Andrew Gray wrote:

>
> Out of interest, do we do anything like this for Memory Alpha?

Currently, no. This would make a bit of an exception to my
exceptions, though - normally I would not be inclined to link to
something that we can't transclude the in-universe information into.
But Memory Alpha is so established and of such quality that I'm
tempted to advocate linking to them anyway. But they pose additional
problems.

-Phil


subject: [WikiEN-l] Fiction and Wikia

body:
On Nov 13, 2006, at 7:47 AM, geni wrote:

> On 11/13/06, Erik Moeller <erik at wikimedia.org> wrote:
>> Essentially, we could make a policy that any relevant external
>> resource that meets the Free Content Definition may be linked in a
>> more visible place than non-free resource. Going a bit beyond free
>> licensing, we could also require that the site at least make complete
>> dumps available on a regular basis, to enable community migration.
>>
>
> Would could but we have enough spam already from free content
> projects.

What if we had a sentence like "links are not appropriate to articles
that do not add substantial and quality information about the subject
that is outside the purview of Wikipedia."

-Phil


subject: [WikiEN-l] Fiction and Wikia

body:
On Nov 13, 2006, at 6:35 AM, James Hare wrote:

> /me is trying not to think about how Erik just promoted his own
> website
>
> In any case, I thought a while back that if Wikia had all these
> wikis, then
> all the unsourced highly specific details could be exiled to these
> wikis. It
> sounded like a good idea.

Well, or better yet, the sourced ones - most of the stuff we're
talking about is pulled from the episodes or novels, and is totally
accurate.

Best,
Phil Sandifer
sandifer at english.ufl.edu

You are standing in an open field west of a white house, with a
boarded front door. There is a small mailbox here.

 >


from_name: Liz Kim

subject: [Wikitech-l] safari problem

body:
Thanks that works our perfectly..

On 11/10/06, Brion Vibber <brion at pobox.com> wrote:
>
> Liz Kim wrote:
> > I am having problems with Safari.
> >
> > In my localsettings, $wgUrlProtocols has been set to
> > 'http:|http:\/\/|https:\/\/|ftp:\/\/|irc:\/\/|gopher:\/\/|mailto:'.
> > In order to get relative external links to work. (for example:
> > [http:../../mypage/ MyHTML Page])
> >
> > I just discovered that this does not work on safari...
>
> Yes, that's not actually a legal URL. While some browsers happen to
> allow it to work, others don't, so you shouldn't rely on it.
>
> Note that you can use the {{SERVER}} variable to make full URLs with
> whatever the local server is.
>
> -- 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] Fiction and Wikia

body:
On Nov 13, 2006, at 9:45 AM, geni wrote:

> On 11/13/06, Phil Sandifer <Snowspinner at gmail.com> wrote:
>> What if we had a sentence like "links are not appropriate to articles
>> that do not add substantial and quality information about the subject
>> that is outside the purview of Wikipedia."
>>
>> -Phil
>
> Doesn't help much. As soon as you have a template people are going to
> start slapping it all over the place. Remember last.fm?

Well, yes - but when it's slapped places that suck, it gets removed.
I  can't imagine that the end situation for the pop culture articles
will be worse than the starting situation.

-Phil


subject: [WikiEN-l] Fiction and Wikia

body:
On Nov 13, 2006, at 3:03 AM, Bryan Derksen wrote:

>
> A set of templates with a different look-and-feel and perhaps an
> appropriate disclaimer, on the other hand, might be better. We often
> already have plain old external links anyway, though, so I'm not sure
> it's needed.

I think there's an important line to be drawn between an external
link and those boxes, though. The external link clearly demarcates
its contents as something that isn't in Wikipedia. Something like a
Wikiquote link, on the other hand, serves as a sort of extension of
the article.

I want to treat the fan-centric links as extensions, because it's
clear that many editors and many readers expect that material to be
in Wikipedia. And so we shouldn't just say "Go away." Or even "Go
somewhere else." We should say "Look, here's where we've found that
gives you this sort of information." And we should make that easy and
well-integrated into our overall organization and navigation, because
there's clearly demand for it.

I don't see the issue of those sites not having NPOV or V - neither
Wikiquote nor Wikinews have similar verification standards in
practical place to Wikipedia, for instance. I think we shouldn't link
to articles that suck or don't add anything. That seems to me to be a
case-by-case decision, though.

-Phil


subject: [WikiEN-l] Kill CSD A7!

body:
On Sun, Nov 12, 2006 at 05:15:16PM -0500, Phil Sandifer wrote:
>
>
> On Nov 12, 2006, at 5:07 PM, Brian Salter-Duke wrote:
>
> >
> >I think this is a really bad idea. PRODs get put on articles that are
> >very new, so few people have probably seen them or got them on their
> >watchlist other than the author. It will just make many authors,
> >who have
> >their work deleted with no opportunity to debate it, to go
> >ballistic. I
> >have yet to have any of my creations PRODed, but if it happened I
> >would
> >want to argue why I created it.
> >
>
> So use the {{hangon}} template on the PROD, and trust the admin who
> looks at it to make a judgment call. Or just ask nicely for it to be
> undeleted, and someone probably will. You only need to persuade one
> person in a five-day period to block a PROD.

OK, fair enough. If it happened to me I would ask the relevent Project,
to which I would probably belong, to have a look at it.

> >I would also suggest that articles that are put to AfD should not be
> >speedy deleted. Once thay are there give people a chance to see
> >them and
> >comment. Maybe only cut short the closure if there are 20 delete
> >"votes"
> >and no keep "votes". I often see a speedy closure of a AfD debate and
> >are curious about what was in it.
>
> The fulfillment of curiosity does not seem to me to outweigh the
> value of minimizing the number of AfD debates running at any given
> moment. Furthermore, it is often beneficial to establish a precedent
> of "kill it with a stick" instead of "debate it a whole lot."

Killing with a stick is top-down admin activity that prevents others
from actually knowing what it was that was killed. I would prefer
killing by consensus after the community has at least had an opportunity
to see it. How much good stuff is going down the gurgler because of
speedy deletion by admins who know nothing about what the article was
about and that it needed help and TLC not killing?

Brian.

> -Phil
>
> ------------------------------
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
>
> End of WikiEN-l Digest, Vol 40, Issue 40
> ****************************************

--
          Brian Salter-Duke            b_duke at bigpond.net.au
               [[User:Bduke]]  mainly on en:Wikipedia.
 Also on fr: Wikipedia, Meta-Wiki, WikiNews, WikiBooks and Commons


from_name: dmehkeri at swi.com

subject: [WikiEN-l] WP:COI Idol

body:
> Is there a rule against ranting about how evil Wikipedia is?
>

What if the rant is sung well, and released under a free content license?

This reality show idea is Not For Stealing, incidentally.

Cheers,
Dan
(who actually meant to object to prohibiting authors removing {{prod}}, but got
distracted by this other thread, and can't remember his point, but let's face
it, it probably didn't add anything anyway.)


from_name: Brion Vibber

subject: [Wikitech-l] AntiSpoof issues

body:
Gregory Maxwell wrote:
> On 11/12/06, Tim Starling <tstarling at wikimedia.org> wrote:
>> We've been having quite a few complaints about false positives from the
>> AntiSpoof extension -- an extension which attempts to prevent registration
>
> Sorry to post again, another thought on this:
>
> It would probably be useful to reduce the comparison to the set of
> users with no non-deleted edits. Who care if someone spoofs a deleted
> user?

We can expect that, say, [[User:Jimbo Wales]] won't actually have any
edits on the majority of our wikis. Does that mean there's no need to
check for spoofs of that username?

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] On style sheets

body:
Luiz Augusto wrote:
> Not related to this specific change, but since some weeks ago someone
> changed something and now every table displayed in some namespaces in some
> wikis is... white.

That's how the style sheets have been for the last couple years, with
the exception of a period of a few weeks this summer.

They were briefly changed in July, then switched back to the original in
August or September following many complaints about the side-effects.

-- brion vibber (brion @ pobox.com)


subject: [WikiEN-l] Fiction and Wikia

body:
On 11/13/06, Phil Sandifer <Snowspinner at gmail.com> wrote:
> On Nov 13, 2006, at 3:03 AM, Bryan Derksen wrote:
> > A set of templates with a different look-and-feel and perhaps an
> > appropriate disclaimer, on the other hand, might be better. We often
> > already have plain old external links anyway, though, so I'm not sure
> > it's needed.
>
> I think there's an important line to be drawn between an external
> link and those boxes, though. The external link clearly demarcates
> its contents as something that isn't in Wikipedia. Something like a
> Wikiquote link, on the other hand, serves as a sort of extension of
> the article.
>
> I want to treat the fan-centric links as extensions, because it's
> clear that many editors and many readers expect that material to be
> in Wikipedia. And so we shouldn't just say "Go away." Or even "Go
> somewhere else." We should say "Look, here's where we've found that
> gives you this sort of information." And we should make that easy and
> well-integrated into our overall organization and navigation, because
> there's clearly demand for it.
>
Seems to me the natural solution is to start up a Wikimedia project
for free information on fictional universes.

Anthony


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

body:
Nick Jenkins wrote:
> There is something kind of satisfying about the simplicity of having
> one test per file, similar to how PHP's .phpt "make test" system
> works.
[snip]
> It also makes it easier for people to add tests and send them in (a
> whole new small file is easier for most folks to work with than a
> diff), and it's easy to disable tests (just move them into another
> directory), and it's easy to get a quick overview of what the current
> tests are (just do an "ls").
>
> Basically in this system $wgParserTestFiles would probably become
> $wgParserTestDirs, and it would be a directory name rather than a
> test .txt filename that was added to the global, and every file in a
> directory would be a set of parserTest tests to be run, and
> parserTests.txt would probably be split up into 400+ files in
> maintenance/parserTests/*.txt, and the testitem table would maybe get
>  an extra field (ti_dir) and ti_name might be renamed ti_filename.
>
> Thoughts? Sounds good, or sounds sucky?

Subdirectories might be nice, so those files can be found by the poor
sods who have to edit them. ;)

-- brion vibber (brion @ pobox.com)


from_name: charles.r.matthews at ntlworld.com

subject: [WikiEN-l] Kill CSD A7!

body:
"Dan Collins" wrote

> well, make prods stricter. say prods cannot be removed by author or
> substantive contributor

Not at all a good idea. But I'm not convinced that authors always do remove PROD notices. When they don't, something is achieved, in the sense that AfD is relieved of the burden.

Charles

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software
Visit www.ntlworld.com/security for more information


subject: [WikiEN-l] An observation

body:
"Ryan Wetherell" wrote

> I think that nothing
> can be done, people will and should come and go as they please,
> regardless of gender.

It's an atmosphere thing. Creating a good atmosphere and working environment is mission-critical, and not just for the participation of women. Everyone should bear this in mind, at all times. It is just not easy to explain, to those who don't find it natural. 'Civility' in the broadest sense is the key.

Charles

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software
Visit www.ntlworld.com/security for more information


from_name: Derek Gottfrid

subject: [WikiEN-l] Using search to explore and find issues w/ articles

body:
I have been developing a small search engine for the last 12 months and have
been using  Wikipedia as sample data. I made this available via
futef.com. Recently, I did further parsing and merging of the wikipedia
data and now merge all the titles together ie "Jimmy Wales" and "Jimbo
Wales" that
are attached to the same article and not connected just  via #REDIRECT.
In doing this, along w/ some relevancy tuning I uncovered some interesting
things about the dataset. A search for "jimbo wales" returns as a top
article "exploding whale" since somebody has included a redirect for
"exploding jimbo wales" as well as "king jimbo wales". I can fix my
search since nobody links to "exploding jimbo wales" - I can assume it
is a junk link and exclude it. But I wanted to know if this community
would be interested in using the search
facilities to verify and explore some of the data. If there is some interested,
I would be happy to create a richer interface into the search engine that would
allow for more data anomalies to be exposed.

A Few More Examples:

Better than france -> Italy
Better than germany -> Italy
Cheese Eating Surrender Monkies -> France

Then there are more subtle issues like

Educational background of George W. Bush -> Yale

I haven't absorbed  enough of the wikipedia ethos to offer a strong position
on all of the things I have found but it would be great if people that
are interested have a better set of tools to work w/ the data. What do
your think?

BTW, I have been lurking here for sometime and watched a conversation appear
about the relevancy of FUTEF and I took the criticism to heart. It was not
as good as it should be - it still isn't but I have worked to make it better.
The several cases that were mention on the mailing list in particular have
been fixed and in general the overall relevancy has greatly improved. If
anyone has issues please let me know - the previous comments were very helpful.

thanks,
derek

--
http://futef.com
derek at futef.com
dgottfrid at gmail.com


subject: [WikiEN-l] An observation

body:
"Ryan Wetherell" wrote

> Oh, "systematic bias", that's exactly the term I was looking for.

I think you were looking for 'systemic bias', which is different.

Charles

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software
Visit www.ntlworld.com/security for more information


subject: [WikiEN-l] Kill CSD A7!

body:
Brian Salter-Duke write

> How much good stuff is going down the gurgler because of
> speedy deletion by admins who know nothing about what the article was
> about and that it needed help and TLC not killing?

That seems to be not quite the key point. As far as I can see, the issue with A7 here is that those with a deletionist tendency probably also read 'assertion of notability' in their own way. Because 'notability' is a vexed issue. [[Matt Long]] was later restored, but was speedied with 50 edits and an IMDB page link with 'only' three film roles and an American TV series. The admin in question was not applying A7 properly, but applying summary justice (one-vote AfD).

Charles

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software
Visit www.ntlworld.com/security for more information


subject: [WikiEN-l] Kill CSD A7!

body:
Phil Sandifer wrote

> The rush of crap in many areas (fanfic, corporate vanity, garage
> bands, and other such major problems ) far outstrips the capacity for
> AfD. None of these things survive AfD, and ought never even go there.

OK, those areas should have, presumably do have, adequate guidelines to work from. Rather a different case from the PROD I had on [[cultural pessimism]].

Charles

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software
Visit www.ntlworld.com/security for more information


list: foundation-l

from_name: Sean Whitton

subject: [Foundation-l] More stewards...

body:
Although I agree that we should reconfirm stewards, do we really need
to do so the the board members?

There is no easy solution here as board members are not automatically
stewards or anything, the point I'm making is that reconfirming Jimbo
seems a little strange.

S

On 13/11/06, Anthere <Anthere9 at yahoo.com> wrote:
> Last steward election was nearly a year ago. Since then, some stewards
> resigned, some were removed, some became inactive. We need more stewards.
>
> Please see here:
> http://meta.wikimedia.org/wiki/Stewards/elections_2006-2
>
> The rules are basically the same than last year but for one thing.
> Previous stewards will have to be reconfirmed. Inactive stewards will be
> removed.
>
> The rules for election are not yet fully finalized. Please comment on
> them in the next few days. Currently, some people think dates may not be
> best. Others are not certain previous stewards should be reconfirmed.
>
> Ant
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

--
	?Xyrael / Sean Whitton ~ Knowledge is power, but only wisdom is liberty
		sean at silentflame.com (PGP: 0x25F4EAB7) | xyrael.net


list: wikimedia-l

subject: [Foundation-l] More stewards...


from_name: Steve

body:
Take this pride fest to private, eh?

-S

On 11/13/06, Milos Rancic <millosh at gmail.com> wrote:
>
> On 11/13/06, Mark Williamson <node.ue at gmail.com> wrote:
> > On 13/11/06, Milos Rancic <millosh at gmail.com> wrote:
> > I'd totally forgotten about how oblivious you were. Responding to all
> > my points as if I were serious. Everyone else, even most of the
> > Serbians, were able to tell I was kidding. I was actually expressing
> > somewhat of a Pan-Yugoslav position through use of extreme sarcasm,
> > basically, that "now everybody tries to break off from the unitary
> > South Slavic nation". The intention wasn't specifically that but to
> > highlight how ridiculous it is that we have languages in 3 versions of
> > what can't even be called different _dialects_ of the same language
> > (maybe if you had one in Cakavian instead of "Croatian").
>
> You showed extremely high level of irresponsibility. As well as all
> people from the community forgot to say me that you are a kid.
> However, I see that it seems that you became mature now... And this is
> good for you. Because your relevancy in talk with other people will
> increase.
>
> > But it is _completely irrelevant_. As I said, we do not have
> > Wikipedias for nations, but for languages. It is simply impossible to
> > use Wikipedia to build a new nation. To form a language where nothing
> > existed before, perhaps, but to build a new nation, no. It's not
> > possible, because _we do not create Wikipedias for nations!_.
>
> Mark, just read. Some people may want to use Wikipedia in the process
> of nation building. At least, two times people tried that. Zlatiborian
> didn't pass, Siberian passed. However, wish to build a nation is a
> legitimate (I hope this is the right word) wish and people were doing
> that in the past, are doing that now and will be doing that in the
> future.
>
> One of the importan part of a nation is a national language (of
> course, there are exceptions). And one who wants to make it's own
> nation will try to make a language, too; and, then, to make Wikipedia
> edition in that language.
>
> So, we came to language.
>
> Language may be constructed/artificial or it can be formalized
> dialect. In both cases 5-10 people are enough to force opening
> Wikipedia in such language (cf. Siberian Wikipedia). And their only
> intention was to make national identity around the language and
> Wikipedia in such language.
>
> I hope that it is more clear now or you will continue to pretend that
> you are not understand that?
>
> > Besides, although nation creation is mentioned often in the discussion
> > it is truly not relevant. What _is_ relevant are the merits of the
> > language itself. How many people speak it? How many people are willing
> > to edit its Wiki? etc.
>
> Mark, Wikimedia Foundation as well as local chapters, including
> Wikimedia Serbia, are involved as a party in Russian internal politics
> as it supports a group of self-proclaimed separatists because there
> were 10 people who wanted to work on Siberian Wikipedia. Maybe there
> are some principles for which we should fight, but this one is very
> foolish.
>
> So, there are some other things then number of speakers, too.
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


from_name: Lane, Ryan

subject: [Wikitech-l] where are mediawiki extensions?

body:
> On Sat, Nov 11, 2006 at 06:42:38PM +0100, Mike O wrote:
> > Where are the Mediawiki extension hidden at ? Pages in meta have the
> wrong links, to cvs at sourceforge.
> >
> Hello,
>
> The extensions can be found in our SVN repository at
>
> 	http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/
>
> Regards,
>
> 	jens

Not all extensions/plugins are available via SVN (mine for instance). Is
this the suggested place for them? If so, should I request SVN access?

V/r,

Ryan Lane


from_name: Walter Vermeir

subject: [Wikitech-l] On style sheets

body:
Simetrical <Simetrical+wikitech at ...> writes:
> Sorry, sorry . . . it's rather poor of me to constantly forget about
> custom styles when most of what I'm committing is UI stuff.
> Unfortunately some disruption is inevitable for this kind of stuff,
> which I suppose suggests it should be condensed and spaced out to the
> extent possible, with ample forewarning every time a batch is going to
> be committed.  Maybe I should make a branch where this kind of
> potentially disruptive stuff can be committed, and then we can let
> stuff accumulate there for a couple of months and until we announce
> all the changes and merge to trunk?  Does that sound like a good idea?

If changes that can give trouble for wikis need to be announced please inform
the internal news media.

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

Especially Wikizine is highly interested to carry this type of news. But it
need to be announced on time. On time is a bit more the one week in advance
depending when the last edition was send out. And if it is not submitted
directly to wikizine it need to discovered. So it can be that the notification
is not noticed.

[[meta:user:Walter]]


from_name: Anthere

subject: [Foundation-l] More stewards...

body:
Last steward election was nearly a year ago. Since then, some stewards
resigned, some were removed, some became inactive. We need more stewards.

Please see here:
http://meta.wikimedia.org/wiki/Stewards/elections_2006-2

The rules are basically the same than last year but for one thing.
Previous stewards will have to be reconfirmed. Inactive stewards will be
removed.

The rules for election are not yet fully finalized. Please comment on
them in the next few days. Currently, some people think dates may not be
best. Others are not certain previous stewards should be reconfirmed.

Ant


subject: [Foundation-l] More stewards...


from_name: Jimmy Wales

subject: [WikiEN-l] something to look into


from_name: Kirill Lokshin

subject: [WikiEN-l] Fiction and Wikia

body:
On 11/13/06, Phil Sandifer <Snowspinner at gmail.com> wrote:
> I think there's an important line to be drawn between an external
> link and those boxes, though. The external link clearly demarcates
> its contents as something that isn't in Wikipedia. Something like a
> Wikiquote link, on the other hand, serves as a sort of extension of
> the article.

Well, the Wikiquote link is to a Wikimedia project, while the Wikia
links would obviously not be; giving links to sister projects more
prominent placement is uncontroversial at least partially *because*
they're sister projects.

--
Kirill Lokshin


subject: [Wikitech-l] AntiSpoof issues

body:
Alphax (Wikipedia email) wrote:
> Brion Vibber wrote:
>> Gregory Maxwell wrote:
>>> On 11/12/06, Tim Starling <tstarling at wikimedia.org> wrote:
>>>> We've been having quite a few complaints about false positives from the
>>>> AntiSpoof extension -- an extension which attempts to prevent registration
>>> Sorry to post again, another thought on this:
>>>
>>> It would probably be useful to reduce the comparison to the set of
>>> users with no non-deleted edits. Who care if someone spoofs a deleted
>>> user?
>> We can expect that, say, [[User:Jimbo Wales]] won't actually have any
>> edits on the majority of our wikis. Does that mean there's no need to
>> check for spoofs of that username?
>>
>
> Yet Another Reason why SUL is needed yesterday...

I'll be putting up the merging UI for localization & testing tomorrow.

-- brion vibber (brion @ pobox.com)


body:
Brianna Laugher wrote:
> On 12/11/06, Florian Straub <flominator at gmx.net> wrote:
>> Awesome! Is there any chance to activate it directly for new
>> registrations
>> on commons or do they people have to confirm their adresses first?
>
>
> Thanks, Brion. Specifically, could we require that new registered
> users must have a confirmed email address before uploading? With talk
> page email notifications as default setting.

That's a complete about-face from Wikimedia's traditional policy of
allowing anonymous contributions, so before I set that up I'd need to
know this is acceptable to Wikimedia.

-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)


subject: [WikiEN-l] something to look into

body:
geni wrote:
> On 11/13/06, Jimmy Wales <jwales at wikia.com> wrote:
>> http://www.opinioneditorials.com/guestcontributors/rcurry_20061113.html
>
>
> Why? Wikipedia appears to have taken the facts and ignored the
> opinions so I don't see a problem.

If that is the case, then fine.  That's why I wanted people to look into it.

Perhaps you are not familiar with the history of this topic and Rex
Curry.  My concern is that he has managed somehow to push his POV and
original research agenda into Wikipedia, and that he is using his
success in doing so to bolster his own cause.


from_name: Earle Martin

subject: [WikiEN-l] Avoidance, was Re: WP:COI violation

body:
On 12/11/06, Ray Saintonge <saintonge at telus.net> wrote:
> Daniel R. Tobias wrote:
> >The Internet RFCs have a very specifically defined set of terms for
> >use in such contexts; they define what SHOULD means versus MUST, and
> >similarly SHOULD NOT vs. MUST NOT.  (The all-caps words are used to
> >emphasize that they have specific meanings when used in RFCs.)
> >
>
> Link please?

http://www.ietf.org/rfc/rfc2119.txt

--
Earle Martin
            http://downlode.org/
http://purl.org/net/earlemartin/


body:
Brion Vibber wrote:
> Brianna Laugher wrote:
>> On 12/11/06, Florian Straub <flominator at gmx.net> wrote:
>>> Awesome! Is there any chance to activate it directly for new
>>> registrations
>>> on commons or do they people have to confirm their adresses first?
>>
>> Thanks, Brion. Specifically, could we require that new registered
>> users must have a confirmed email address before uploading? With talk
>> page email notifications as default setting.
>
> That's a complete about-face from Wikimedia's traditional policy of
> allowing anonymous contributions, so before I set that up I'd need to
> know this is acceptable to Wikimedia.

(I should clarify that I think it's a good idea, personally. But I would
not feel comfortable implementing that policy without both community
agreement and approval from upstairs for the ground rules changing
dramatically.)

-- brion vibber (brion @ pobox.com)


from_name: Milos Rancic

subject:
[Foundation-l] Policy draft: Wikimedia projects are not the place
	for national constitution

body:
Please, look at
http://meta.wikimedia.org/wiki/Wikimedia_projects_are_not_the_place_for_national_constitution

... and give your ideas there.

I think that the policy may be more exact.


subject:
[Foundation-l] [Wikipedia-l] Policy draft: Wikimedia projects are
	not the place	for national constitution

body:
Please, look at
http://meta.wikimedia.org/wiki/Wikimedia_projects_are_not_the_place_for_national_constitution

... and give your ideas there.

I think that the policy may be more exact.
_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


subject:
[Wikipedia-l] Policy draft: Wikimedia projects are not the place
	for national constitution