from_name: Jean-Christophe Chazalette

subject: [Foundation-l] Re: French domain lost

body:
This is certainly something that needed clarification, especially regarding current trademark license deals like the one with MandrakeSoft. Thanks God I didn't mention "Wikipedia" was a patented trademark in the draft though I was sur it was ... Anyhow, any kind of trademark license will be clearer and safer with a patented trademark.
villy

> For clarification, I believe the current situation is that we have
> submitted the application to register Wikipedia as a trademark in the
> US. The application was filed last month, but I don't believe it is
> approved yet, as it still needs to be reviewed by the Patent and
> Trademark Office and published to see if anyone objects to registration.
> Actual registration can take up to a year or longer. We certainly
> consider Wikipedia a trademark, whether registered or not, but I
> recommend that people be careful not to claim that it is registered at
> this point.
>
> Once we have the initial registration in place, this should help us
> expedite other registrations that may be necessary, such as the EU.
> Based on international agreements, I believe that once the trademark is
> recognized, additional registrations can be backdated to the earliest
> registration date.
>
> As far as I know, trademark registration is not necessary in order to
> register domain names anywhere. However, it may be helpful in recovering
> squatted domain names.
>
> --Michael Snow
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l

Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ;
3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn)


list: wikimedia-l

source: pipermail-mbox

subject: [Foundation-l] Re: French domain lost


list: wikien-l

from_name: Andreas Hoerstemeier

subject: [WikiEN-l] Re: Trigger-happy New Pages patrol

body:
Mark Richards wrote:
> Yes, rapid fire drive-by-deletion is out of control.
Just because rapid-fire nonsense substub creation is out of control. And
way to many of real speedy-deletions survive the new page patrol, and
only get noticed by sheer lucky later - e.g. if an Image:Example.jpg is
used, or someone checks the short articles or orphaned articles later
on. Of course there is some collateral damage sometimes - yesterday I
rescued to stubs of [[Elder Edda]] poems which were already marked by
{{delete}} - but as they were just one-liners the loss wouldn't have
been that big.

>>As far as I'm concerned, Wikipedia still needs stubs
>>to grow, precisely in
>>areas where it is currently weak.
That's the old discussion if a stub makes a topic grow better than a
non-existiting article, and if a stub look better/worse than a
non-existing article. IMHO everything below three sentences isn't worth
it, but I know that's currently not the consensus.

Bye,
    [[User:Ahoerstemeier]]


from_name: Ray Saintonge

body:
Jens Ropers wrote:

> On 21 Oct 2004, at 14:56, Rebecca wrote:
>
>>> MHO everything below three sentences isn't worth
>>> it, but I know that's currently not the consensus.
>>
>> I'm not so sure. A vocal minority decided this, and to my knowledge it
>> was never voted upon. A nice coup d'etat, indeed.
>> -- ambi
>
> With respect, that's a bunch of Mullarkey.
>
> There may have been little turnout on related decisionmaking, but
> abstentions are a common occurrence in democratic processes. (They
> actually are a quite normal, even vital part of said processes.) Just
> because your side didn't succeed in turning out more supporters of
> your POV, that doesn't entitle you to claim that you represented any
> kind of majority.
>
> [[If and only if]] you successfully mobilize more supporters than the
> opposing side, THEN you can lay claim to representing majority opinion.

She did not claim that she represented the majority, only that a
decision was made by a vocal minority.  Going strictly on the basis of
what she said in those comments, I could not be sure of which side she
supported.

Votes are always being generated by somebody around here.  Vocal
minorities are often involved in using them to subvert democratic
processes.  That a person may have been a part of the majority on a
given occasion is meningless.  I really have better things to do with my
time than responding to constant attempts to martial opinions for issues
that keep repeating themselves.  Such vote gathering exercises only
serve to divide the community and keep it divided.

Your intimation that those who don't vote are exercising an abstention
is misleading.  Many were probably not even properly notified.  This is
the first time that this particular flavour of the issue has been raised
on the mailing list, and even now you don't say where I could go to vote
if I wanted.

In the past I have made it abundantly clear that I am in the
inclusionist camp.  Why should I constantly need to repeat myself?  One
thing that is certain is that the entire community has a major division
over this.  Seeking new majorities on minor variations is not going to
solve anything.  Listening to each other, and respecting the efforts of
a stub's contributor will.

Ec


from_name: JAY JG

subject: [WikiEN-l] Caching issues

body:
>From: "csherlock at ljh.com.au" <csherlock at ljh.com.au>
>Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
>To: wikien-l at wikipedia.org
>Subject: [WikiEN-l] Caching issues
>Date: Thu, 21 Oct 2004 12:45:41 +1000
>
>Hi all,
>
>I find that I'm updating articles and the changes are not always being
>reflected straight away. Has anyone else been having this problem?
>
>TBSDY

Yes, all the time.  Also, I'll notice a page updated on my watchilist, but
when I look for the changes they are not apparent.  Going to the history and
doing a compare usually reveals the differences, but it can take up to an
hour for them to appear on the actual page, even when flushing my cache.
And also I find I'm being regularly logged out many times during a session,
sometimes within seconds of logging in.

Jay.


subject: [WikiEN-l] Trigger-happy New Pages patrol

body:
Anthony DiPierro wrote:

>>>Yes, rapid fire drive-by-deletion is out of control.
>>>
>>>
>>Just because rapid-fire nonsense substub creation is out of control.
>>
>>
>Like [[Geno's_Steaks]]?  Was that a substub?  It was marked with
>{{deletebecause|it lacks encyclopedic content}}, speedy deleted, listed on
>VfU, undeleted, and received a unanimous vote to keep on VfD.  Speedy
>deletion has gotten completely out of hand.
>
>Yes, our deletion system needs to be fixed, and I think the number of people
>who agree with me that VfD is broken is rising, but letting admins
>unilaterally decide what gets deleted is not the solution.
>
>
Perhaps a pre-condition to adminhood should be a proven ability to deal
fairly with others.

Ec


from_name: Cyril Thomas

subject: [WikiEN-l] GWB Picture vandalism

body:
If click on the Hitler pic...the linked page will show the right
picture...Oh...okay, now it?s getting fine even here in Kerala, India :)

-----Original Message-----
From: wikien-l-bounces at Wikipedia.org
[mailto:wikien-l-bounces at Wikipedia.org] On Behalf Of Allan Crossman
Sent: Wednesday, October 20, 2004 7:48 AM
To: wikien-l at wikipedia.org
Subject: [WikiEN-l] GWB Picture vandalism

 > On http://en.wikipedia.org/wiki/George_W._Bush somehow the thumb of
 > GWB in National Guard gear has been replaced by a pic of Hitler.

This seems to be some sort of caching problem - the pic was fixed and
protected on the 18th, but strangely some people still seem to get the
Hitler pic (though I see it's been de-linked from the article now...)

--
Allan Crossman - a.crossman at blueyonder.co.uk
The Moon is Waxing Crescent (41% of Full)
_______________________________________________
WikiEN-l mailing list
WikiEN-l at Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikien-l

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.779 / Virus Database: 526 - Release Date: 10/19/04

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.779 / Virus Database: 526 - Release Date: 10/19/04


from_name: Fred Bauder

subject:
[WikiEN-l] Charging per edit (was Re: Hateful ban shows that
	Wikipedia is flawed almost beyond hope)

body:
The amount would have to be tailored to reflect the financial circumstances
of the user. The charge for Microsoft would be far in excess of $1,000 an
edit.

Fred

> From: Sean Barrett <sean at epoptic.org>
> Organization: Boskonia
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Thu, 21 Oct 2004 07:44:47 -0700
> To: English Wikipedia <wikien-l at Wikipedia.org>
> Subject: [WikiEN-l] Charging per edit (was Re: Hateful ban shows that
> Wikipedia is flawed almost beyond hope)
>
> Fred Bauder stated for the record:
>
>> I don't know if this idea will ever be used. But I can imagine some
>> circumstance might exist. For example sockpuppets from Microsoft could be
>> restrained in this way should they try to edit.
>>
>> Fred
>>
>>
>>> From: Sheldon Rampton <sheldon at prwatch.org>
>>> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
>>> Date: Thu, 21 Oct 2004 09:01:39 -0700
>>> To: wikien-l at wikipedia.org
>>> Subject: [WikiEN-l] Re: Hateful ban shows that Wikipedia is flawed almost
>>> beyond hope
>>>
>>> TBSDY wrote:
>>>
>>>
>>>> Terrible idea. They pay a donation and then think this gives them
>>>> permission to do what they like on the 'pedia. I cannot agree with this
>>>> idea.
>>>
>>> That wasn't my idea at all. What I described was a system whereby
>>> problematic posters would be required to pay a small amount of money
>>> for every edit they make. Right now they ALREADY have "permission to
>>> do what they like on the 'pedia," for free. My payment system idea
>>> isn't something I'm proposing IN PLACE OF existing mechanisms for
>>> arbiting and restricting vandalism. It would be something IN ADDITION
>>> TO.
>>>
>>> --Sheldon Rampton
>
> Sockpuppets, from Microsoft or any other large corporation, would love
> this plan.  Microsoft buys entire governments -- we're not going to slow
> them down by charging them money.  At a US$1000 per edit, they could
> make a tens of thousands of edits before the expense would show up in
> their bottom line.  (See [[milliard]].)
>
> --
> Sean Barrett     | The politician was gone but unnoticed, like
> sean at epoptic.com | the period after the Dr on a Dr Pepper can.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Poor, Edmund W

subject: [WikiEN-l] Caching issues

body:
> From: csherlock at ljh.com.au [mailto:csherlock at ljh.com.au]
> Sent: Wednesday, October 20, 2004 10:46 PM
> I find that I'm updating articles and the changes are not
> always being
> reflected straight away. Has anyone else been having this problem?

Yes, quite a lot. It makes me think about developing my own off-line
editing software, just so I can see my changes.

Has anyone written or tried anything along these lines, that's good for
when the lag becomes annoying?

Ed Poor
(A software developer in another life)


subject: [WikiEN-l] Re: Caching issues

body:
Sherlock,

Please refrain from making personal remarks to other list participants.
ESPECIALLY when the 'other guy' seems to have started it.

Ed Poor
List Admin Emeritus

> don't let the door hit you on the way out.


from_name: Delirium

subject: [WikiEN-l] Caching issues

body:
Poor, Edmund W wrote:

>>I find that I'm updating articles and the changes are not
>>always being
>>reflected straight away. Has anyone else been having this problem?
>>
>>
>
>Yes, quite a lot. It makes me think about developing my own off-line
>editing software, just so I can see my changes.
>
>
Odd, I've never noticed this.  A shift-reload always gets me the latest
version every time I've tried...

-Mark


from_name: Mark Richards

body:
I thought we were running a concensus, rather than
first-past-the-post system. Perhaps I'm very
old-fasioned.
Mark

--- Jens Ropers <ropers at ropersonline.com> wrote:

> On 21 Oct 2004, at 14:56, Rebecca wrote:
>
> >> MHO everything below three sentences isn't worth
> >> it, but I know that's currently not the
> consensus.
> >
> > I'm not so sure. A vocal minority decided this,
> and to my knowledge it
> > was never voted upon. A nice coup d'etat, indeed.
> >
> > -- ambi
>
> With respect, that's a bunch of Mullarkey.
>
> There may have been little turnout on related
> decisionmaking, but
> abstentions are a common occurrence in democratic
> processes. (They
> actually are a quite normal, even vital part of said
> processes.) Just
> because your side didn't succeed in turning out more
> supporters of your
> POV, that doesn't entitle you to claim that you
> represented any kind of
> majority.
>
> [[If and only if]] you successfully mobilize more
> supporters than the
> opposing side, THEN you can lay claim to
> representing majority opinion.
>
> -- ropers [[en:User:Ropers]]
>      www.ropersonline.com
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

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


from_name: Anthony DiPierro

body:
>> Yes, rapid fire drive-by-deletion is out of control.
> Just because rapid-fire nonsense substub creation is out of control.

Like [[Geno's_Steaks]]?  Was that a substub?  It was marked with
{{deletebecause|it lacks encyclopedic content}}, speedy deleted, listed on
VfU, undeleted, and received a unanimous vote to keep on VfD.  Speedy
deletion has gotten completely out of hand.

Yes, our deletion system needs to be fixed, and I think the number of people
who agree with me that VfD is broken is rising, but letting admins
unilaterally decide what gets deleted is not the solution.


from_name: dpbsmith at verizon.net

subject: [WikiEN-l] Re: WikiEN-l Digest, Vol 15, Issue 48

body:
Others noted:
> >>I find that I'm updating articles and the changes are not
> >>always being
> >>reflected straight away. Has anyone else been having this problem?
> >>
> Odd, I've never noticed this.  A shift-reload always gets me the latest
> version every time I've tried...

I've noticed this problem, rather suddenly, beginning several days ago. For
time, I've noticed a significant lag between updating VfD discussions and the
update being reflected on the main VfD page, but assumed that had something
to do with the complex interrelationships between all the template stuff.

The characteristics are different from other caching issues in the past. The
chief symptom is I edit a page, press "Save this page", and do not see my
updates. For a while I thought I was previewing and then failing to save, or
accidentally hitting cancel, but that's not it.

Shift-reload does NOT work for me.

The chief characteristics are: the history IS updated; a diff on the update
DOES show the page; and an "edit this page" does show the updates in the edit
box. But simply viewing the page does not show them.


list: wikipedia-l

from_name: Tim Starling

subject: [Wikipedia-l] Re: pi-eyed

body:
Ray Saintonge wrote:
> When at Wikisources [[Pi to 1,000,000 places]] an anonymous user changes
> the first 10 digits of line 14320 from "0628419546" to "1516171819" how
> is anyone possible able to know which is correct? :-) :'(

The obvious thing to do would be to revert it. The chances that the
anonymous user knew pi to 1,000,000 decimal places and noticed the error
are pretty small. The regularity of the sequence "1516171819" should be
a giveaway, just like the sequence inserted in the same edit on the
previous line "1234567890".

That said, a google search turned up a site apparently made for
precisely this problem:

http://www.angio.net/pi/bigpi.cgi?UsrQuery=6014280388

Not that it matters, you only need tens of digits to solve any
conceivable physical problem. What a waste of disk space.

-- Tim Starling


from_name: csherlock at ljh.com.au

subject: [WikiEN-l] Caching issues

body:
Hi all,

I find that I'm updating articles and the changes are not always being
reflected straight away. Has anyone else been having this problem?

TBSDY


subject:
[WikiEN-l] Re: [jhyang-Bku6BsYElwheoWH0uzbU5w@public.gmane.org:
 Cooperation Request from the   KoreanOverseas Information Service]

body:
Matt R wrote:
>  --- "Jimmy (Jimbo) Wales" <jwales at wikia.com> wrote:
>
>>To me, it is quite interesting in an abstract way that people are
>>dying in (for example) Sudan this morning, and other people have a
>>paid job which involves writing to me to complain about the name of a
>>body of water.  One should think that there might be more important
>>things to do in the world.
>
>
> Of course, a lot of Wikipedia editing disputes could be analysed in a similar
> manner. I'm sometimes appalled at the way I will get disproportionately annoyed
> about, say, a minor WP spelling issue, but remain coldly indifferent to
> suffering around the world. I'm not suggesting for a minute that attending to
> the minutiae of Wikipedia articles isn't worthwhile [1]. Rather, I merely
> conjecture that that when we find ourselves experiencing WikiStress, one
> approach might be to ponder the serious problems that affect the majority of
> the world who can't access Wikipedia even if they wanted to.
>
> -- Matt (User:Matt Crypto)
>
> [1] I reserve judgment on Pokemon ;-)

Perhaps you get annoyed about this minor matter because it has some
effect on you directly, while the suffering in the world is not YOUR
personal suffering. This is a perfectly normal human condition, IMHO. I
suffer from this affliction also.

TBSDY


from_name: Rick

subject: [WikiEN-l] Caching issues

body:
A problem with this, especially if you use a word processing program instead of a text editor, is that special characters, especially quotation marks, come up garbled when they get pasted back.

RickK

"Poor, Edmund W" <Edmund.W.Poor at abc.com> wrote:
> From: csherlock at ljh.com.au [mailto:csherlock at ljh.com.au]
> Sent: Wednesday, October 20, 2004 10:46 PM
> I find that I'm updating articles and the changes are not
> always being
> reflected straight away. Has anyone else been having this problem?

Yes, quite a lot. It makes me think about developing my own off-line
editing software, just so I can see my changes.

Has anyone written or tried anything along these lines, that's good for
when the lag becomes annoying?

Ed Poor
(A software developer in another life)
_______________________________________________
WikiEN-l mailing list
WikiEN-l at Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.


subject: [Wikipedia-l] Re: pi-eyed

body:
Ray Saintonge wrote:
> When at Wikisources [[Pi to 1,000,000 places]] an anonymous user changes
> the first 10 digits of line 14320 from "0628419546" to "1516171819" how
> is anyone possible able to know which is correct? :-) :'(

I just thought I should add that the need to constantly clean up
vandalism on pi pages is a waste of time. You should just protect the
page or delete it.

-- Tim Starling


subject: [WikiEN-l] Caching issues

body:
I have a problem in that I never know which version of the Main Page I'm going to get.  And it isn't always the most recent version I've seen -- sometimes it's the Main Page from two or three days ago, and I've seen more recent versions than that.  It makes no sense at all.

Another problem I've had only a couple of times is that I'll click on a link to bring up a page and only half of the page will show up.  I have to edit the page, which then shows the entire content in the edit window, and save it without making a change -- then I'll get the full page.

RickK

sannse <sannse at tiscali.co.uk> wrote:

Delirium wrote:

> Poor, Edmund W wrote:
>
>>> I find that I'm updating articles and the changes are not always
>>> being reflected straight away. Has anyone else been having this
>>> problem?
>>
>> Yes, quite a lot. It makes me think about developing my own off-line
>> editing software, just so I can see my changes.
>>
>
> Odd, I've never noticed this. A shift-reload always gets me the
> latest version every time I've tried...
>
> -Mark

This has happened to me three or four times over the last week or so.
It's also been mentioned a few times on IRC over the same period. It's
not something I've seen before - but it seems to be an increasing
problem at the moment. As others have said, forcing a refresh or
clearing my cache doesn't help. But using &action=purge does (not a
solution in general of course)

I've copied this to the tech list - it seems more their area than the en
list.

--sannse

_______________________________________________
WikiEN-l mailing list
WikiEN-l at Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikien-l

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


list: wikitech-l

from_name: Alan Wessman

subject: [Wikitech-l] WikiData: A rant

body:
Perhaps a way to address this dilemma is with a manual pull system.  A
page that incorporates WikiData would display a message indicating
that the page uses data that was last refreshed *for this page* at
such-and-such a date/time.  (This information can be cached with the
page, since it doesn't make a statement about the freshness of the
underlying data.)  The display would also give the user the ability to
force a refresh if desired.  (A DoS attack could be avoided by not
allowing refresh before x amount of time has passed since the last
refresh.)

Wouldn't be quite as automatic as the pull system described in the
original message, but it could avoid the severe performance penalty.
Just a thought.

Alan

On Thu, 21 Oct 2004 21:07:45 +0200, Magnus Manske <magnus.manske at web.de> wrote:
[...]
> As good "wiki-fiddlers" (thanks so much, Register!) we would like to see
> every change in WikiData on the wikipedia pages real soon. Like, now.
> So the information that something changes, and what changed, has to pass
> from the data site to the display site. There are two ways to do that:
> push or pull.
>
> PUSH means the data site will notify the display site that something has
> changed, and the display needs to be updated. For that, the data site
> has to know which pages of the display site are affected by which
> change. Then, it has to notify the display site of this. Bad things:
> * Needs basically a cache of *all* queries *ever* asked of the data
> site, as well as their results
> * Has to recalculate *all* of these after *every* change to find which
> queries produce different results
> * Won't work if the display site is offline
> * Won't work well with non-wikipedias
>
> That can't be it.
>
> PULL means the display site asks the data site if anything has changed,
> which basically means rerunning a query. Which means, doing this for
> *every* pageview, even for anons. Which means, all caching variants,
> including squids, are going bye-bye. Additionally, for every page view,
> the display site has to wait for the data site to complete the query.
> Think wikipedia is slow today? Think again...
>
> That can't be it, either.
>
> Oh, sure, we can cache the queries with results on the display site, or
> only update the data once a day/week, but then we won't be wiki (=quick)
> anymore, no? Will this be the price to pay?
>


list: foundation-l

from_name: Anthere

subject: [Foundation-l] Re: French domain lost

body:
Michael Snow a ?crit:
> Anthere wrote:
>
>> I think that in this case, Foundation holding the US trademark and
>> european one will be sufficient.
>> Jimbo just told me that the US one was approved and the other underway.
>>
>>
> For clarification, I believe the current situation is that we have
> submitted the application to register Wikipedia as a trademark in the
> US. The application was filed last month, but I don't believe it is
> approved yet, as it still needs to be reviewed by the Patent and
> Trademark Office and published to see if anyone objects to registration.
> Actual registration can take up to a year or longer. We certainly
> consider Wikipedia a trademark, whether registered or not, but I
> recommend that people be careful not to claim that it is registered at
> this point.

Good point to mention. Since there is a tiny discrepancy between your
message and Jimbo comment, it might be best that Jimbo clarifies. But in
any cases, we need to be conservative on this point obviously.

One year :-(

> Once we have the initial registration in place, this should help us
> expedite other registrations that may be necessary, such as the EU.
> Based on international agreements, I believe that once the trademark is
> recognized, additional registrations can be backdated to the earliest
> registration date.
>
> As far as I know, trademark registration is not necessary in order to
> register domain names anywhere. However, it may be helpful in recovering
> squatted domain names.
>
> --Michael Snow

Yes. Well, we'll try the gentle way first


subject: [Foundation-l] Re: French domain lost


from_name: Brion Vibber

subject: [Wikitech-l] database question: oldid

body:
On Oct 21, 2004, at 8:23 AM, Thomas Gries wrote:
> Can some please explain, if
>
> oldid in combination with namespace:pagetitle
>
> is sufficient to describe *permanently* a certain revision (version)
> of a page, as long, as that revision of the page is kept in the
> database.
> Is it ?

Two caveats:
a) the namespace and title can change (page rename), don't use them for
unique identification
b) oldid does not currently survive a delete/undelete cycle.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20041021/78aef939/attachment.pgp>


subject: [WikiEN-l] Drive-by deletion

body:
Yes, the red links give away the deletion, but there
is no way to know WHAT was deleted. I do not agree
that the author of the article should be responsible
for explaining why it is relevant - I believe the
would be deletor should have to prove why it fits the
criteria for deletion.

I also think that one week is not enough. The problem
is that too many articles are listed inapropriately,
not the speed of the process.

Mark

--- "J.F. de Wolff" <jfdwolff at doctors.org.uk> wrote:

>
> Mark Richards wrote:
> >Yes, rapid fire drive-by-deletion is out of
> control.
> >People list articles within minutes of their
> creation,
> >without doing even basic due dilligence to see
> whether
> >they meet the criteria for deletion.
> >Mark
>
>
> The problem is that Vfd is presently very slow (one
> week is really very
> long). Also, if the math articles are legit, the
> author should aim to make
> as clear as possible how relevant it is! Sometimes a
> few words are enough
> to give some context.
>
> Btw the presence of many red links is a good
> predictor of an article's VfD
> death :-)
>
>
> JFW
> > _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com


from_name: Allan Crossman

subject: [Wikitech-l] Multiple image versions - why bother?

body:
 > > Someone on IRC, I forget who, suggested that we should end this
 > > ability to upload new revisions of images. I agree.
 >
 > Absolutely not. Images should be treated like regular wiki pages,
 > otherwise we will give up much of the collaboration potential that is
 > there.

Fair enough. However, it's absolutely imperative that whatever problems
that are causing people to see the wrong image when they look at the
image page be sorted out.

--
Allan Crossman - a.crossman at blueyonder.co.uk
The Moon is Waxing Gibbous (58% of Full)


from_name: Rebecca

body:
And Raul's solution solves both problems. So where's the issue?

-- ambi

On Wed, 20 Oct 2004 16:41:12 -0600, Fred Bauder <fredbaud at ctelco.net> wrote:
> I tried to enforce simplicity but they all got mad. They just keep adding
> and adding.
>
> Fred
>
> > From: Delirium <delirium at hackish.org>
> > Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> > Date: Wed, 20 Oct 2004 17:28:34 -0400
> > To: English Wikipedia <wikien-l at Wikipedia.org>
> > Subject: Re: [WikiEN-l] Requests for arbitration refactoring
>
>
> >
> > Rebecca wrote:
> >
> >> Perhaps if you make a unilateral change, and find numerous people
> >> disagreeing with it, and no one who backs you up, then it might
> >> suggest that the move wasn't wise to make in the first place.
> >>
> >> And IIRC, it was Raul who remerged the page.
> >>
> >>
> > Well, I certainly agree with The Cunctator's change to the page, and I'm
> > baffled as to how it got to the point where he had to fix it in the
> > first place.  The original instructions were to add material to subpages
> > only, but people kept adding stuff to the main arbitration page anyway
> > for some reason.
> >
> > -Mark
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikipedia-l] Re: pi-eyed

body:
Stirling Newberry wrote:
> On the contrary, it is merely that "neutral point of view" on such
> pages has a much narrower definition than on most pages.

In fact the definition is so narrow that one can easily get close enough
to it for all practical purposes in the first edit, obviating the need
for incremental improvement. When perfection has been attained, it's
likely that further edits will have to be reverted.

It's true that you could make minor changes to formatting, but those
changes do not provide enough benefit to counteract the waste of time
and resources caused by vandalism.

-- Tim Starling


from_name: Rowan Collins

subject: [Wikitech-l] Users and groups based security

body:
On Thu, 21 Oct 2004 07:11:58 +0000, Victor Fari?a <wickle at gmail.com> wrote:
> Hello ...
> I am wondering if there are any plans or discussions about enhanced
> the security of the wiki in a user/groups based, for example to let an
> editor protect his pages from view/modify other users that the ones he
> designate (with a special tag or something) ... I think that this is a
> feature not very useful at wikipedia sites, but yes on my wikis used
> mainly for projects development .

Yes, a proper user-rights system is among the most requested features
from non-wikimedia MediaWiki users, and there was recently some
progress towards implementing it. I'm not sure how far it got, but
certainly some code was checked in a few weeks ago based on the
concept of assigning users to groups, and associating rights for
different pages to different groups. You might want to glance through
these threads in the mailing list archives:

* http://mail.wikimedia.org/pipermail/wikitech-l/2004-September/024982.html
[quite old, fairly abstract discussion]
* http://mail.wikipedia.org/pipermail/wikitech-l/2004-September/025594.html
[the thread relating to the checked in user_groups code]

--
Rowan Collins BSc
[IMSoP]


from_name: Mark Williamson

subject: [Wikipedia-l] Re: pi-eyed

body:
Agreed. But then, at least according to *some* of us, since I am not a
Wikisourcian, my opinion does not matter.

--node

On Thu, 21 Oct 2004 02:52:46 -0700, Ray Saintonge <saintonge at telus.net> wrote:
> Magnus Manske wrote:
>
> > Angela wrote:
> >
> >> If such pages would need permanent protection, it only proves they are
> >> not suitable for a wiki, where pages are supposed to be edited.
> >
> > The point seems to be that pi is *not* supposed to be edited. An
> > article *about* pi is. Wikisource should make it easy to add a data
> > page, but then keep it stable, IMHO.
>
> Agreed.  I tend to look at Wikisource as a place where material is
> relatively much less editable than onWikipedia,  but not completely
> uneditable.  This mostly works.  But that could be because some of the
> texts are so long that they discourage editing.  There are features that
> I would love to have that would make translations and annotations more
> convenient, but I can be patient in waiting for them. 8-)
>
> Ec
>
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


from_name: Mark Pellegrini

subject: [WikiEN-l] Caching issues

body:
Rickk said "A problem with this, especially if you use a word processing program instead
of a text editor, is that special characters, especially quotation marks, come up garbled
when they get pasted back."

In the past, we have used a bot to fix these.

--Mark


subject: [WikiEN-l] Re: Caching issues

body:
Polytarp! wrote:
> That's it.
>
> Your message, Kerlock, is the straw that broke the camel's back.
>
> I'm unsubscribing from this nonsense list.
>
>
> On Thu, 21 Oct 2004 12:45:41 +1000, csherlock at ljh.com.au
> <csherlock at ljh.com.au> wrote:
>
>>Hi all,
>>
>>I find that I'm updating articles and the changes are not always being
>>reflected straight away. Has anyone else been having this problem?
>>
>>TBSDY

Please, and don't let the door hit you on the way out.


subject: [WikiEN-l] Stopping to speedy speedy deletions

body:
Great idea. Should be applied to listing on vfd too.
Mark

--- "Eric B. and Rakim" <eric_b_and_rakim at hotmail.com>
wrote:

> Let's make a policy. The policy goes like this:
>
> "If an administrator speedily deletes an article and
> it then turns out that
> the article in question was not a real candidate for
> speedy deletion, that
> administrator is awarded a point.
>
> If an administrator gets more than 3 points during a
> 3 months period, that
> administrator loses admin privilegies."
>
> Very easy. To many bad mistakes and you're out. The
> exact number of points
> and the number of months is not important. Maybe it
> should be 5 points in 12
> months or 2 points in 2 months or whatever. Then the
> policy need some more
> text:
>
> "Articles that are speedily deleted but then
> restored and kept in some way
> are not real candidates for speedy deletion."
>
> I.e. pretend I write a three-line article about some
> obscure math topic.
> Some admin thinks it is rubbish and deletes it. Then
> a math-guru admin comes
> around and restores it. What probably happens is
> that the admin who did the
> deletion realises his or hers mistake. So he or she
> gets one point.
> Borderline cases are put on VFD. In practice it is
> very easy to determine
> whether a speedy deletion was motivated or not.
> And then the policy need some important lines to not
> make anyone angry:
>
> "The intentions of the administrator does not play
> any role in how points
> are awarded. It should be assumed that the admin
> acted in good faith and
> didn't mean any harm to Wikipedia by deleting the
> article. However, good
> intentions affecting Wikipedia in a negative way
> cannot continue to go
> unchecked."
>
> Like noone is angry that newbie sysop deleted four
> articles about classical
> poetry because he or she thought it sounded like
> rubbish. Mistakes happen.
> But if you cannot learn from your mistakes you are
> not fit for the job.
>
> "The current score tally is kept on
> [[Wikipedia:Mistaken Speedy Deletions]]"
>
> Because the information has to be recorded some way.
>
> This is an awesome policy. I hope y'all understand
> what I mean even if it is
> late and writing legal sounding texts in English is
> hard. I'm not a newbie,
> I'm not being sarcastic/ironic and this proposal is
> serious. And I think it
> is good. But what do YOU think?
>
>
_________________________________________________________________
> FREE pop-up blocking with the new MSN Toolbar - get
> it now!
> http://toolbar.msn.com/
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com


from_name: William Mahan

subject: [Wikitech-l] Re: Support for shared image upload directory

body:
On Thu, 21 Oct 2004 18:05:30 +0100, Rowan Collins
<rowan.collins at gmail.com> wrote:
> On Thu, 21 Oct 2004 08:07:52 +0200, Jens Frank <jeluf at gmx.de> wrote:
> > The swap of replaceExternalLinks and replaceInternalLinks was done to
> > handle URLs in thumbnail captions, like in
> >
> > [[Image:TeX lion.png|thumb|right|100px|The [[TeX]] [[lion]]. http://www.ctan.org/]]
> >
> > Whoever did it probably forgot to update the comments...

I made that change to fix bug 2. Sorry I forgot to update the comment.

My reasoning for replacing internal links before external links was
that replaceExternalLinks() replaces anything that looks like a URL
with
a HTML link, which wasn't the right thing to do inside internal links.
My change made use of the fact that internal links are stripped out
and replaced by placeholders, so replaceExternalLinks() will not
disifigure the HTML generated by replaceInternalLinks().

Could [[Media:Bla.jpg]] be replaced by a placeholder and then
re-inserted later, as with other internal links? That's what I did to fix
interwiki links, which were also broken by replacing internal links
before external ones.


from_name: Jens Ropers

body:
On 21 Oct 2004, at 14:56, Rebecca wrote:

>> MHO everything below three sentences isn't worth
>> it, but I know that's currently not the consensus.
>
> I'm not so sure. A vocal minority decided this, and to my knowledge it
> was never voted upon. A nice coup d'etat, indeed.
>
> -- ambi

With respect, that's a bunch of Mullarkey.

There may have been little turnout on related decisionmaking, but
abstentions are a common occurrence in democratic processes. (They
actually are a quite normal, even vital part of said processes.) Just
because your side didn't succeed in turning out more supporters of your
POV, that doesn't entitle you to claim that you represented any kind of
majority.

[[If and only if]] you successfully mobilize more supporters than the
opposing side, THEN you can lay claim to representing majority opinion.

-- ropers [[en:User:Ropers]]
     www.ropersonline.com


subject:
[Wikitech-l] Quick-reference guide for distinguishing "Wiki",
	"Wikipedia", "Wikimedia", "MediaWiki", etc

body:
Coming upon yet another situation where it would be nice to reference
a quick guide to often-confused names, I've expanded Jens Ropers' list
(below) into a page on meta: explaining the difference between
different terms, and highlighting how they should and shouldn't be
used.

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

I've inserted some references to it at relevant points around meta:,
but please link to it from wherever you think would be appropriate.
[And, obviously, improve on anything non-optimal about it...] I've
called it "Names" rather than something like "Often-confused terms" so
that it's nice and easy to remember; my idea being that when somebody
misuses one of these terms, we can say "BTW, please see
http://meta.wikimedia.org/wiki/Names".

Thanks Jens for the idea, and the basis of the text. It may be cute
having names which are all puns on each other, but it sure is
confusing to the unitiated!

On Tue, 12 Oct 2004 20:12:50 +0200, Jens Ropers <ropers at ropersonline.com> wrote:
> '''Wikimedia''' is the name of the Wikimedia Foundation, the parent
> organization encompassing our various projects such as Wikipedia,
> Wiktionary, Wikispecies, Wikicommons, etc.
> '''MediaWiki''' is the wiki software that is developed for and used by
> these projects (and available for others to use for their wikis as
> well).
> '''Wikipedia''' -- the free encyclopedia -- is but ONE project of the
> Wikimedia Foundation.
> '''Wiki''' is a generic term to describe certain kinds of collaborative
> websites that can be user/visitor-edited (and most Wikimedia foundation
> websites are examples of wikis).
> '''Wiki software''' is any software that powers wiki websites at the
> backend. Such software is also called a '''wiki engine'''. There are
> MANY other wiki engines besides MediaWiki, big and small; good, bad and
> ugly ones; a list is here: http://c2.com/cgi/wiki?WikiEngines
>
> All --
> Anybody have a good idea where to post this info prominently? Or better
> yet, could whoever knows please go ahead and post this info
> prominently? Because these matters frequently seem to be a source of
> confusion.

--
Rowan Collins BSc
[IMSoP]


from_name: Thomas Gries

subject: [Wikitech-l] database question: oldid

body:
Can some please explain, if

oldid in combination with namespace:pagetitle

is sufficient to describe *permanently* a certain revision (version) of
a page, as long, as that revision of the page is kept in the database.
Is it ?
Please could you answer directly to me, thanks.

Background of my question:

the new Enotif patch -coming soon- will memorize (for each watching
user) the last version "oldid" the watching user has really seen. The
notification mail comprises two links, one to the current version of the
watched page and -new- a second link to
{{SERVER}}{{localurl:$PAGETITLE|diff=0&oldid=$OLDID}} , which directly
shows the differences between current version and the last visited one.

Such a feature has been proposed by some of you and is integrated in new
Enotif versions. Enotif is already available for MediaWiki 1.3.5 and
1.3.6, however, the both MediaWiki Versions are superseded by 1.3.7.
Please look forward to the next Enotif release for MW 1.3.7 and CVS 1.4,
coming soon. http://meta.wikipedia.org/Enotif


body:
> Perhaps a pre-condition to adminhood should be a proven ability to deal
> fairly with others.

But that wasn't the problem.  I don't blame the admin with not dealing
fairly with others.  I can't even say for sure whether the admin broke any
policies.

The problem isn't the admin.  The problem is that admins are given
discretion over such things in the first place.  Speedy deletions should be
reserved for indisputably bad articles - articles that no one would
seriously oppose the deletion of.

Of course, deletion was supposed to be reserved for such articles as well,
but it's devolved into a popularity contest which defines 2/3 as consensus.
Fortunately, it's usually possible to export an article before it's deleted
via VfD.  Unfortunately, it's rarely possible to export a speedy deletion
before it's been deemed unworthy.  It has been proposed on the pump (one of
them) that deleted articles be available for editors to view, but as one of
our members of the Board of Directors opposes it it's unlikely to happen.

Anthony


subject: [WikiEN-l] Re: Caching issues

body:
I'm still comprehensively mystified by Polytarp's email though.
I mean, WHAT was he getting cranked up about? What was he on about? As
far as I could tell, TBSDY's email was a perfectly valid post raising a
real problem. Can anyone see how Polytarp could have found fault with
that? Because, egads, I can't.

-- ropers [[en:User:Ropers]]
     www.ropersonline.com

On 21 Oct 2004, at 17:20, Poor, Edmund W wrote:

> Sherlock,
>
> Please refrain from making personal remarks to other list participants.
> ESPECIALLY when the 'other guy' seems to have started it.
>
> Ed Poor
> List Admin Emeritus
>
> On 21 Oct 2004, at 08:10, csherlock at ljh.com.au wrote:
>
>> Please, and don't let the door hit you on the way out.
>>
>> Polytarp! wrote:
>>
>>> That's it.
>>> Your message, Kerlock, is the straw that broke the camel's back.
>>> I'm unsubscribing from this nonsense list.
>>>
>>> On Thu, 21 Oct 2004 12:45:41 +1000, csherlock at ljh.com.au
>>> <csherlock at ljh.com.au> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I find that I'm updating articles and the changes are not always
>>>> being
>>>> reflected straight away. Has anyone else been having this problem?
>>>>
>>>> TBSDY


body:
> On Thu, Oct 21, 2004 at 05:04:17AM +0000, Erik Moeller wrote:
>
> > Note: I changed
> >                 $text = $this->replaceInternalLinks ( $text );
> >                 $text = $this->replaceExternalLinks( $text );
> > to
> >                 $text = $this->replaceExternalLinks( $text );
> >                 $text = $this->replaceInternalLinks ( $text );
> >
> > in Parser.php. Otherwise [[Media:Bla.jpg]] to an absolute URL would be
> > incorrectly parsed as external links.  [...] I did some
> > tests and nothing seems to be broken, but I have some problems executing
> > parserTests.php so I couldn't test it systematically.

Erk! Please make doubly and trebly sure your change doesn't break the
parserTests - see http://bugzilla.wikimedia.org/2 and
http://bugzilla.wikimedia.org/637 for some of the "fixes" which have
previously broken each other, and the reason why things are how they
are, regardless of out-of-date comments.

Anyway, your statement seems to me to be self-contradictory: if you
have [[Media:http://example.net/Foo.jpeg]], you need
replaceInternalLinks() to come *first*, so that it will have become a
placeholder before replaceExternalLinks() comes along and messes it
up. As far as I can see, you've actually created the behaviour you
claim to be fixing/avoiding: replaceInternalLinks() is now going to
find "[[Media:http://example.net/Foo.jpeg]]" and just ignore it.

Have I misunderstood your intention? I'm not entirely sure why you'd
*want* this to work, unless it's as a hacky way of manually choosing
between a commons and a local image with the same name.

On Thu, 21 Oct 2004 08:07:52 +0200, Jens Frank <jeluf at gmx.de> wrote:
> The swap of replaceExternalLinks and replaceInternalLinks was done to
> handle URLs in thumbnail captions, like in
>
> [[Image:TeX lion.png|thumb|right|100px|The [[TeX]] [[lion]]. http://www.ctan.org/]]
>
> Whoever did it probably forgot to update the comments...

Actually, I think it was the opposite: the original order was to
achieve that, and the swap to fix bug 2 broke it, leading to bug 637
and about half a dozen rewrites of replaceInternalLinks() to handle
images sensibly. I still have an even slightly cleaner version of that
planned and yet to implement.

[I guess comments in the header of replaceExternalLinks() weren't
changed, because the change was nowhere near there so no-one thought
to look for them.]

--
Rowan Collins BSc
[IMSoP]


from_name: Charles Podles

subject: [WikiEN-l] Technical help urgently needed

body:
Today I moved the deletion log to [[Wikipedia:Deletion log
archive/October 2004 (2)]]
(as it had reached nearly a megabyte) and accidentally moved its talk
page along with it.
I moved the talk page back while leaving the archive in place, but
that archive is a reflexive redirect whose only history entry is:

21:26, 21 Oct 2004 Mirv (Wikipedia:Deletion log moved to
Wikipedia:Deletion log archive/October 2004 (2))

which means I've effectively destroyed all entries in the deletion log
between October 11
(the time of its last archiving) and today. How did I do this? Where
did the archive go?
Can it be fixed or recovered?

--A red-faced [[User:Mirv]]


from_name: sannse

subject: [WikiEN-l] Caching issues

body:
Delirium wrote:

> Poor, Edmund W wrote:
>
>>> I find that I'm updating articles and the changes are not always
>>> being reflected straight away. Has anyone else been having this
>>> problem?
>>
>> Yes, quite a lot. It makes me think about developing my own off-line
>> editing software, just so I can see my changes.
>>
>
> Odd, I've never noticed this.  A shift-reload always gets me the
> latest version every time I've tried...
>
> -Mark

This has happened to me three or four times over the last week or so.
It's also been mentioned a few times on IRC over the same period.  It's
not something I've  seen before - but it seems to be an increasing
problem at the moment.  As others have said, forcing a refresh or
clearing my cache doesn't help.  But using &action=purge does (not a
solution in general of course)

I've copied this to the tech list - it seems more their area than the en
list.

--sannse


subject: [Wikitech-l] Re: [WikiEN-l] Caching issues


from_name: J.F. de Wolff

subject: [WikiEN-l] Drive-by deletion

body:
Mark Richards wrote:
>Yes, rapid fire drive-by-deletion is out of control.
>People list articles within minutes of their creation,
>without doing even basic due dilligence to see whether
>they meet the criteria for deletion.
>Mark

The problem is that Vfd is presently very slow (one week is really very
long). Also, if the math articles are legit, the author should aim to make
as clear as possible how relevant it is! Sometimes a few words are enough
to give some context.

Btw the presence of many red links is a good predictor of an article's VfD
death :-)

JFW


from_name: Joel Wiesmann

subject: [Wikitech-l] Re: Detailled documentation for special pages

body:
Hi Brion

First of all, thanks for your answer. Now, let's go on ;)

Brion Vibber wrote:
> The first and foremost documentation is the source code. The code of the
> functions, the comments in and around them, and their usage elsewhere in
> the code should, ideally, be relatively clear. In practice it's not
> always as clear as we'd like. :)

Of course - but maybe you notices.. mediawiki is pretty big ;)! Yet, I'm
not used to work myself into big projects (or even be a part of it) but
it's a challenge and I'll try to do my best.

> In 1.4 we've been adding more comments to produce internal API
> documentation via phpdoc. A probably not current copy is at
> http://wikipedia.sourceforge.net/mwdoc/ (select the 'MediaWiki' package
> to see anything of any note). Note that 1.4 isn't quite the same as 1.3
> if you're working with 1.3; some things have changed.

Great! At least it explains some stuff I wasn't aware of! Will be very
helpfull! The google-search gives kinda lot of answers! I'll try to life
with that ;).

Hopefully nobody already asked this.. is there a way to do a own namespace
like "special" where I can put php-sides in it AND use the {{include}}
functions on the other wikipages to include this side? This would allow me
to do a calendar and lot of other cool features for dynamic pages.

Now when I try to include a special page I only get a wikilink. Of course I
could do a hack to meet my wishes, but that's not really what I want to do.

I don't know if it would be a security-issue.. I mean you have to activate
each special page in SpecialPages.php so it would maybe be a good way to
make a support for plugins?

Regards,
Joel


from_name: Magnus Manske

subject: [Wikitech-l] WikiData: A rant

body:
Warning: Long and depressing text follows. Don't read it at home, save
it for work instead. Better spend a nice evening with your girlfriend.
(Then again, this list is probably like slashdot, so forget about the
imaginary girlfriend and continue reading ;-)

I thought I had it all figured out.

I created a demo version for data entry in a wiki-like fashion. It uses
a "one-table-fits-all" SQL schema, which some of you had worries about.
No problem. If someone else write a better data entry mechanism, I'm all
for it. As far as it concerns me, the WikiData site should be like a
black box to the outside, serving data to wikipedias and everyone else
who wants it. What's going on inside is only for those who enter the data.

Today, I finished creating a rough draft for the query (the wikipedia)
side of the bargain. Istead of creating Yet Another Wikimarkup [{(like
this)}] I figured out that we should separate the query and the display
part, and hide the query part within the template system. Goes like this:

{{speciesdata:Foobus Barus}}

in the article; [[Template:Speciesdata]] looks like this:

<data>
<query database="wikispecies" result="r1">Some sort of XQuery or SQL
query for wikispecies for {{{1}}}</query>
Some species data table using <r1>latin_name</r1>, <r1>name_en</r1>,
<r1>family</r1> etc.
</data>

For creating lists (like "all species within the family 'Foobus'"), a
<foreach> element could be used.
The <data> thingy would be a plugin ("plugins GOOD!"), but one that
returns wikitext to be parsed further. It would handle the <query> and
<foreach> tags etc.

So, we'd have *one* ugly m..........r of a <data><query> kind template,
which would, once created, not be edited again a lot. All the powerful,
functional uglyness that could scare newbies away would be hidden
through the template.
Yes, I got it all figured out.

Then it hit me.

As good "wiki-fiddlers" (thanks so much, Register!) we would like to see
every change in WikiData on the wikipedia pages real soon. Like, now.
So the information that something changes, and what changed, has to pass
from the data site to the display site. There are two ways to do that:
push or pull.

PUSH means the data site will notify the display site that something has
changed, and the display needs to be updated. For that, the data site
has to know which pages of the display site are affected by which
change. Then, it has to notify the display site of this. Bad things:
* Needs basically a cache of *all* queries *ever* asked of the data
site, as well as their results
* Has to recalculate *all* of these after *every* change to find which
queries produce different results
* Won't work if the display site is offline
* Won't work well with non-wikipedias

That can't be it.

PULL means the display site asks the data site if anything has changed,
which basically means rerunning a query. Which means, doing this for
*every* pageview, even for anons. Which means, all caching variants,
including squids, are going bye-bye. Additionally, for every page view,
the display site has to wait for the data site to complete the query.
Think wikipedia is slow today? Think again...

That can't be it, either.

Oh, sure, we can cache the queries with results on the display site, or
only update the data once a day/week, but then we won't be wiki (=quick)
anymore, no? Will this be the price to pay?

I think I'll have that autumn-depression now, please...

Magnus


body:
"Paid advertising with a Robin Hood twist".

On 21 Oct 2004, at 19:16, Fred Bauder wrote:

> The amount would have to be tailored to reflect the financial
> circumstances
> of the user. The charge for Microsoft would be far in excess of $1,000
> an
> edit.
>
> Fred
>
>> From: Sean Barrett <sean at epoptic.org>
>> Organization: Boskonia
>> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
>> Date: Thu, 21 Oct 2004 07:44:47 -0700
>> To: English Wikipedia <wikien-l at Wikipedia.org>
>> Subject: [WikiEN-l] Charging per edit (was Re: Hateful ban shows that
>> Wikipedia is flawed almost beyond hope)
>>
>> Fred Bauder stated for the record:
>>
>>> I don't know if this idea will ever be used. But I can imagine some
>>> circumstance might exist. For example sockpuppets from Microsoft
>>> could be
>>> restrained in this way should they try to edit.
>>>
>>> Fred
>>>
>>>
>>>> From: Sheldon Rampton <sheldon at prwatch.org>
>>>> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
>>>> Date: Thu, 21 Oct 2004 09:01:39 -0700
>>>> To: wikien-l at wikipedia.org
>>>> Subject: [WikiEN-l] Re: Hateful ban shows that Wikipedia is flawed
>>>> almost
>>>> beyond hope
>>>>
>>>> TBSDY wrote:
>>>>
>>>>
>>>>> Terrible idea. They pay a donation and then think this gives them
>>>>> permission to do what they like on the 'pedia. I cannot agree with
>>>>> this
>>>>> idea.
>>>>
>>>> That wasn't my idea at all. What I described was a system whereby
>>>> problematic posters would be required to pay a small amount of money
>>>> for every edit they make. Right now they ALREADY have "permission to
>>>> do what they like on the 'pedia," for free. My payment system idea
>>>> isn't something I'm proposing IN PLACE OF existing mechanisms for
>>>> arbiting and restricting vandalism. It would be something IN
>>>> ADDITION
>>>> TO.
>>>>
>>>> --Sheldon Rampton
>>
>> Sockpuppets, from Microsoft or any other large corporation, would love
>> this plan.  Microsoft buys entire governments -- we're not going to
>> slow
>> them down by charging them money.  At a US$1000 per edit, they could
>> make a tens of thousands of edits before the expense would show up in
>> their bottom line.  (See [[milliard]].)
>>
>> --
>> Sean Barrett     | The politician was gone but unnoticed, like
>> sean at epoptic.com | the period after the Dr on a Dr Pepper can.
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at Wikipedia.org
>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] WikiData: A rant

body:
Good acumen Magnus. A very incisive "rant".

Anyway, just musing and mulling:
Could the PULL method be implemented w/ a checksum?
Say, generate a fairly short checksum (we're talking versioning here,
not security) for every article revision.
Then, with each request hitting an Intarweb-facing (caching) webserver,
have that cache box look if there's a version stored in its cache for
said article (if not, fetch the article from the actual DB , etc.). IF
however there is a cached version, ask the DB server for its current
checksum on its current version. If this matches the checksum the cache
has for its version, just don't bother the DB any further and serve the
page from the cache. If the checksums differ, then again fetch the
article from the DB and serve that (and cache the new article and
checksum for potential subsequent requests). This entire checksum thing
will NOT be required for any cached non-current revisions, because they
won't change. So, yes, for each request hitting the cache server,
there'd be a short checksum PULL with the actual DB server, but other
than that (and provided the article hasn't changed) it can just be
served from the cache.

Does that make sense to people?
Or am I reinventing the wheel or something?
I'm just brainstorming, I'm not even a real programmer. (Translation:
The above may be--or may not be--rubbish.)

-- ropers [[en:User:Ropers]]
     www.ropersonline.com

On 21 Oct 2004, at 21:07, Magnus Manske wrote:

> Warning: Long and depressing text follows. Don't read it at home, save
> it for work instead. Better spend a nice evening with your girlfriend.
> (Then again, this list is probably like slashdot, so forget about the
> imaginary girlfriend and continue reading ;-)
>
> I thought I had it all figured out.
>
> I created a demo version for data entry in a wiki-like fashion. It
> uses a "one-table-fits-all" SQL schema, which some of you had worries
> about. No problem. If someone else write a better data entry
> mechanism, I'm all for it. As far as it concerns me, the WikiData site
> should be like a black box to the outside, serving data to wikipedias
> and everyone else who wants it. What's going on inside is only for
> those who enter the data.
>
> Today, I finished creating a rough draft for the query (the wikipedia)
> side of the bargain. Istead of creating Yet Another Wikimarkup [{(like
> this)}] I figured out that we should separate the query and the
> display part, and hide the query part within the template system. Goes
> like this:
>
> {{speciesdata:Foobus Barus}}
>
> in the article; [[Template:Speciesdata]] looks like this:
>
> <data>
> <query database="wikispecies" result="r1">Some sort of XQuery or SQL
> query for wikispecies for {{{1}}}</query>
> Some species data table using <r1>latin_name</r1>, <r1>name_en</r1>,
> <r1>family</r1> etc.
> </data>
>
> For creating lists (like "all species within the family 'Foobus'"), a
> <foreach> element could be used.
> The <data> thingy would be a plugin ("plugins GOOD!"), but one that
> returns wikitext to be parsed further. It would handle the <query> and
> <foreach> tags etc.
>
> So, we'd have *one* ugly m..........r of a <data><query> kind
> template, which would, once created, not be edited again a lot. All
> the powerful, functional uglyness that could scare newbies away would
> be hidden through the template.
> Yes, I got it all figured out.
>
> Then it hit me.
>
> As good "wiki-fiddlers" (thanks so much, Register!) we would like to
> see every change in WikiData on the wikipedia pages real soon. Like,
> now.
> So the information that something changes, and what changed, has to
> pass from the data site to the display site. There are two ways to do
> that: push or pull.
>
> PUSH means the data site will notify the display site that something
> has changed, and the display needs to be updated. For that, the data
> site has to know which pages of the display site are affected by which
> change. Then, it has to notify the display site of this. Bad things:
> * Needs basically a cache of *all* queries *ever* asked of the data
> site, as well as their results
> * Has to recalculate *all* of these after *every* change to find which
> queries produce different results
> * Won't work if the display site is offline
> * Won't work well with non-wikipedias
>
> That can't be it.
>
> PULL means the display site asks the data site if anything has
> changed, which basically means rerunning a query. Which means, doing
> this for *every* pageview, even for anons. Which means, all caching
> variants, including squids, are going bye-bye. Additionally, for every
> page view, the display site has to wait for the data site to complete
> the query.
> Think wikipedia is slow today? Think again...
>
> That can't be it, either.
>
> Oh, sure, we can cache the queries with results on the display site,
> or only update the data once a day/week, but then we won't be wiki
> (=quick) anymore, no? Will this be the price to pay?
>
> I think I'll have that autumn-depression now, please...
>
> Magnus
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Peter Gervai

subject:
[Wikipedia-l] Could a developer kindly update the MediaWiki
	namespace on some projects?

body:
Hello,

I realised that lots of new projects in my language (hungarian) started
recently, which is great.

My problem is that they use a very old version of interface texts (either
LanguageHU.php or MediaWiki, I cannot tell which is used).

I would like to request two things:

1) Is it possible to update them by using hu.wikipedia.org's MediaWiki
texts? (They would need a search&replace on "wikipedia" to the project name
like "wikibooks", "wikiquote", etc., but in that case I would like to
request more differences, so please contact me before the _replace_. Copy
is appreciated though no matter whether s&r possible.)

2) What can I do to make new appearing projects to use the current interface
texts in the future?

thanks,
Peter
[[user:grin]] everywhere around en, hu, meta.


from_name: David Gerard

subject:
[Wikipedia-l] Re: [Free-sklyarov-uk] Dutch Parliament public domain
 images and public broadcasters

body:
Seen on UK-CDR. Could our Dutch readers please advise us on
how and when this wonderful thing will eventuate?

- d.

Andrew A. Adams wrote:
>>From BNA's Internet Law News:
>
>
> DUTCH PARLIAMENTARIANS TO PUSH FOR INCREASED PUBLIC DOMAIN
> Parliamentarians from Dutch ruling and opposition parties
> unanimously agreed that most images currently owned by Dutch
> public broadcasters should be released into the public
> domain and allowed to be distributed online.
> <http://www.dmeurope.com/default.asp?ArticleID=3911>
>
>


from_name: Daniel P.B.Smith

subject: [WikiEN-l] Re: VfD: one week is probably about right

body:
 >From: "J.F. de Wolff" <jfdwolff at doctors.org.uk>

 >The problem is that Vfd is presently very slow (one week is really very
 >long). Also, if the math articles are legit, the author should aim to
make
 >as clear as possible how relevant it is! Sometimes a few words are
enough
 >to give some context.

No, I think the week is needed, for several reasons.

First: at the moment I have a bit of a Wiki-habit. Just as I check my
email several times a day, I check my watchlist several times a day.
And I'm ashamed to say I follow VfD a lot more closely than is good for
me. But, believe it or not, there are many people who do _not_ log in
several times a day, or every day. People take weekends off. They go on
trips. They don't stop in Internet cafes to check their watchlist. A
week is necessary to extend a fair opportunity for participation to
people who are not glued to their Web browser.

Second, articles are frequently posted on VfD because, to the person
posting them, they _look_ like something non-notable, or vanity--but
are actually notable to people with subject-area expertise. Well, it
has happened several times recently that people have made _perfectly
reasonable_ postings to VfD. And, after a couple of days, people that
_do_ recognize the topic as notable come in and say "wait, I know who
that is." They explain, and not infrequently other people in the
discussion, including people who originally voted delete, _including
the original poster,_ will say "Oh, I guess I was wrong" and change
their votes to "keep." Really! And that's a happy outcome.

Third, less pleasant but equally relevant. Many VfD discussions are
really power struggles assessing the strength of factions. OK, let's
say, "determining consensus."  It takes about a week to give enough
people a chance to get their word in and see what the vote really is.
If the period were much shorter than a week, it would give an unfair
advantage to the people who spend more time online in general, and more
time in VfD in particular. The outcomes of these VfD discussions are
never happy outcomes, but at least they are _reasonably_ fair outcomes.

Fourth, good or bad, quite a few articles get significantly improved as
a direct result of being listed in VfD. I think we do want this to
happen, and it's more likely to happen if there's enough time for it to
happen. "Keep in present form," "keep as improved," "keep new
article"--these are happy outcomes.

But... you're right about writing clear articles... I think 90% of the
listings on VfD could be avoided if people would not yield to the
instant-gratification urge of creating an article the instant they
think about it. I think very few articles would get listed on VfD if
people waited until they had put three decent paragraphs together
before creating the article. Not necessarily a finished, polished,
encyclopedia-quality article, just three decent paragraphs.

--
Daniel P. B. Smith, dpbsmith at verizon.net
"Elinor Goulding Smith's Great Big Messy Book" is now back in print!
Sample chapter at http://world.std.com/~dpbsmith/messy.html
Buy it at http://www.amazon.com/exec/obidos/ASIN/1403314063/


from_name: Rick

body:
By your definition, that would be zero articles.  You have opposed deletion of every article ever brought up for deletion, and then demand the undeletion of those which have gone through the appropriate deletion process.  Even though you have been blocked from editing in the past by the arbcom due to your trolling of VfD, you continue to do so.

RickK

Anthony DiPierro <anthonydipierro at hotmail.com> wrote:
The problem isn't the admin. The problem is that admins are given
discretion over such things in the first place. Speedy deletions should be
reserved for indisputably bad articles - articles that no one would
seriously oppose the deletion of.

---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.


from_name: Eric B. and Rakim

body:
Let's make a policy. The policy goes like this:

"If an administrator speedily deletes an article and it then turns out that
the article in question was not a real candidate for speedy deletion, that
administrator is awarded a point.

If an administrator gets more than 3 points during a 3 months period, that
administrator loses admin privilegies."

Very easy. To many bad mistakes and you're out. The exact number of points
and the number of months is not important. Maybe it should be 5 points in 12
months or 2 points in 2 months or whatever. Then the policy need some more
text:

"Articles that are speedily deleted but then restored and kept in some way
are not real candidates for speedy deletion."

I.e. pretend I write a three-line article about some obscure math topic.
Some admin thinks it is rubbish and deletes it. Then a math-guru admin comes
around and restores it. What probably happens is that the admin who did the
deletion realises his or hers mistake. So he or she gets one point.
Borderline cases are put on VFD. In practice it is very easy to determine
whether a speedy deletion was motivated or not.
And then the policy need some important lines to not make anyone angry:

"The intentions of the administrator does not play any role in how points
are awarded. It should be assumed that the admin acted in good faith and
didn't mean any harm to Wikipedia by deleting the article. However, good
intentions affecting Wikipedia in a negative way cannot continue to go
unchecked."

Like noone is angry that newbie sysop deleted four articles about classical
poetry because he or she thought it sounded like rubbish. Mistakes happen.
But if you cannot learn from your mistakes you are not fit for the job.

"The current score tally is kept on [[Wikipedia:Mistaken Speedy Deletions]]"

Because the information has to be recorded some way.

This is an awesome policy. I hope y'all understand what I mean even if it is
late and writing legal sounding texts in English is hard. I'm not a newbie,
I'm not being sarcastic/ironic and this proposal is serious. And I think it
is good. But what do YOU think?

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.com/


from_name: Rebecca

body:
> MHO everything below three sentences isn't worth
> it, but I know that's currently not the consensus.

I'm not so sure. A vocal minority decided this, and to my knowledge it
was never voted upon. A nice coup d'etat, indeed.

-- ambi


subject: [Wikitech-l] WikiData: A rant

body:
Jens Ropers wrote:

> Good acumen Magnus. A very incisive "rant".

Thanks.

>
> Anyway, just musing and mulling:
> Could the PULL method be implemented w/ a checksum?
> Say, generate a fairly short checksum (we're talking versioning here,
> not security) for every article revision.
> Then, with each request hitting an Intarweb-facing (caching)
> webserver, have that cache box look if there's a version stored in its
> cache for said article (if not, fetch the article from the actual DB ,
> etc.). IF however there is a cached version, ask the DB server for its
> current checksum on its current version. If this matches the checksum
> the cache has for its version, just don't bother the DB any further
> and serve the page from the cache. If the checksums differ, then again
> fetch the article from the DB and serve that (and cache the new
> article and checksum for potential subsequent requests). This entire
> checksum thing will NOT be required for any cached non-current
> revisions, because they won't change. So, yes, for each request
> hitting the cache server, there'd be a short checksum PULL with the
> actual DB server, but other than that (and provided the article hasn't
> changed) it can just be served from the cache.

So, the DB server keeps a list with a checksum (or a version number;
this is supposed to be wiki-like) for each data entry, and likewise does
the article, right?
What if it more than a single data entry in that article? Like the list
of species I mentioned.Say, a new species was added at wikidata; how to
handle that one?
What if there are multiple queries in one article?
What if (in my example) the actual query is in a template?
What if that template includes other templates that contain queries?

Yes, I think that it could be done. But, and I say that as someone who
started programming with "spaghetti code", it looks like a mess to me. A
dependency nightmare. We are already suffering from such effects (think
categories in templates) without wikidata to look out for.
Also, you will have to query the DB server and wait for its answer on
*every* page view, including cached/anons, to deliver the checksum(s).
And, this will work only with the most rudimentary database structure,
like "SELECT * from specieslist where name='Foo'". If wikidata is to
become more complex than that (and I don't say it should, just
speculating), if wikidata tables can be interlinked, then there will be
no "simple" dependency on a single data entry anymore.

> Does that make sense to people?
> Or am I reinventing the wheel or something?
> I'm just brainstorming, I'm not even a real programmer. (Translation:
> The above may be--or may not be--rubbish.)

Definitely not rubbish. But a lot more complicated than it looks at
first glance, IMHO.

Magnus


from_name: Ray Saintonge

body:
Anthony DiPierro wrote:

>>Perhaps a pre-condition to adminhood should be a proven ability to deal
>>fairly with others.
>>
>>
>But that wasn't the problem.  I don't blame the admin with not dealing
>fairly with others.  I can't even say for sure whether the admin broke any
>policies.
>
You make it sound there as though it's just one admin.  This is a
recurrent issue, and strictly speaking may not involve the breach of any
policies.  The person's Wikiquette, however, may be lacking.

>The problem isn't the admin.  The problem is that admins are given
>discretion over such things in the first place.  Speedy deletions should be
>reserved for indisputably bad articles - articles that no one would
>seriously oppose the deletion of.
>
Giving them the benefit of the doubt, I'm sure that they believe that
they are deleting "indisputably bad articles".

>Of course, deletion was supposed to be reserved for such articles as well,
>but it's devolved into a popularity contest which defines 2/3 as consensus.
>Fortunately, it's usually possible to export an article before it's deleted
>via VfD.  Unfortunately, it's rarely possible to export a speedy deletion
>before it's been deemed unworthy.  It has been proposed on the pump (one of
>them) that deleted articles be available for editors to view, but as one of
>our members of the Board of Directors opposes it it's unlikely to happen.
>
>
Any number based definition of consensus is flawed, and probably
inconsistent with any normal concept of consensus.  Achieving consensus
includes making an effort to accomodate what a person is trying to
communicat.  Keeping the deleted articles may help in a crisis, but it
is not a long term solution.

Ec


subject: [WikiEN-l] Drive-by deletion

body:
Rebecca wrote:

>If there are articles listed appropriately, then you, just like any
>other Wikipedian, have to right to vote "keep".
>
>
You are certainly correct if you are referring to a right as outlined in
some set of rules.  It's just not a practical right, because it would
require people to spend a great deal of their precious Wikipedia doing
nothing but considering deletion requests.

Ec


subject: [WikiEN-l] Drive-by deletion

body:
NSK wrote:

>On Friday 22 October 2004 04:54, Carson, David wrote:
>
>
>>It's pretty clear that we can't EXPECT anyone to read any policy.
>>
>>
>Perhaps WP could disallow anonymous edits and require by people who open an
>account to read a short policy and agree to it, for example with an "I Agree"
>checkbox.
>
Let's hope not!!  It sounds too much like the bafflegab that we
supposedly agree to when we instal another software package.  Most
people haven't got a clue about what they are agreeing to.  They just
know that if they don't agree the software won't work.  Much of what is
in these agreements involves the abandonment of legal protections that
are normally provided by law.

>Anons that create useful content *will* create an account if they are serious
>in their wikiwork.
>
They do eventually, so why pressure them before they are ready.

Ec


body:
NSK wrote:

>You need to ensure that all WP participants want to help WP, instead of
>pushing POV or exercising power. WP's shortcomings is a problem of motives:
>People join WP for their own benefit instead of WP's benefit. This needs to
>be corrected, otherwise WP will become a battleground and not a useful
>resource.
>
And who is qualified to impute such motives?

>I think you need to make account creation a bit more difficult:
>0. Anons aren't needed; disable anon editing.
>1. People will be required to validate their account through an e-mail
>address.
>2. New account holders will be denied editing until after 1-2 days.
>3. To make anons open an account you could make some pages readable only by
>account holders, et cetera.
>
Imposing this set of rules would be just another form of POV pushing

Ec


body:
NSK wrote:

>On Friday 22 October 2004 05:13, Andrew Lih wrote:
>
>
>>1) This is quite contrary to Wikipedia's policy to "be bold"
>>
>>
>If "be bold" means anarchy without organisation and process then I think
>that's a bad policy that should be repealled ASAP.
>
The wiki thrives on a diet of anarchy.  It didn't become what it is by
borrowing editorial policies from Britannica.

Ec


subject: [Wikitech-l] WikiData: A rant

body:
On 21 Oct 2004, at 23:31, Magnus Manske wrote:

> Jens Ropers wrote:
>
>> Anyway, just musing and mulling:
>> Could the PULL method be implemented w/ a checksum?
>> Say, generate a fairly short checksum (we're talking versioning here,
>> not security) for every article revision.
>> Then, with each request hitting an Intarweb-facing (caching)
>> webserver, have that cache box look if there's a version stored in
>> its cache for said article (if not, fetch the article from the actual
>> DB , etc.). IF however there is a cached version, ask the DB server
>> for its current checksum on its current version. If this matches the
>> checksum the cache has for its version, just don't bother the DB any
>> further and serve the page from the cache. If the checksums differ,
>> then again fetch the article from the DB and serve that (and cache
>> the new article and checksum for potential subsequent requests). This
>> entire checksum thing will NOT be required for any cached non-current
>> revisions, because they won't change. So, yes, for each request
>> hitting the cache server, there'd be a short checksum PULL with the
>> actual DB server, but other than that (and provided the article
>> hasn't changed) it can just be served from the cache.
>
> So, the DB server keeps a list with a checksum (or a version number;
> this is supposed to be wiki-like) for each data entry, and likewise
> does the article, right?

Yup.

> What if it more than a single data entry in that article? Like the
> list of species I mentioned.Say, a new species was added at wikidata;
> how to handle that one?
> What if there are multiple queries in one article?
> What if (in my example) the actual query is in a template?
> What if that template includes other templates that contain queries?

I wouldn't have a clue to be honest. I would, in my non-coder and
possibly naive imagination reckon that maybe a "one article-one
checksum" principle should work with most pages. As regards Wikidata et
alia, well, I dunno -- counting templates (and possibly single data
sets; but I don't really know a lot about what you're building/you've
built there) as articles may work as well. Then again, just having
(only) ordinary articles intelligently cached as per the above proposal
might solve the biggest part of our problem.
>
> Yes, I think that it could be done. But, and I say that as someone who
> started programming with "spaghetti code", it looks like a mess to me.
> A dependency nightmare. We are already suffering from such effects
> (think categories in templates) without wikidata to look out for.
> Also, you will have to query the DB server and wait for its answer on
> *every* page view, including cached/anons, to deliver the checksum(s).

True.
I'm really not trying to deliberately complicate things , but "we"
could also make the DB servers report all checksums to a group of
separate dedicated checksum cache servers (which would replicate
between each other like there's no tomorrow, to make damn sure that all
checksum cache servers would ALWAYS have the identical set of
checksums). One of these redundant checksum servers would then be
checked (which should spread the load) and if there's so much as a
delay with querying one of them, then the checksum query could
fail-over (round robin) to the next checksum cache box. There prolly
should also remain a last resort fail-over option of querying the DB
server direct and doing away with the entire checksum thing (which,
after all is only there to save time and shield the DB server from
excessive queries).

> And, this will work only with the most rudimentary database structure,
> like "SELECT * from specieslist where name='Foo'". If wikidata is to
> become more complex than that (and I don't say it should, just
> speculating), if wikidata tables can be interlinked, then there will
> be no "simple" dependency on a single data entry anymore.
>
>> Does that make sense to people?
>> Or am I reinventing the wheel or something?
>> I'm just brainstorming, I'm not even a real programmer. (Translation:
>> The above may be--or may not be--rubbish.)
>
> Definitely not rubbish. But a lot more complicated than it looks at
> first glance, IMHO.

Yea, that's probably true. All the worse as I won't be the one coding
it, because I, uh, lack the requisite programming skills :-/

--ropers

> Magnus
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikitech-l] WikiData: A rant

body:
On 22 Oct 2004, at 00:32, Jens Ropers wrote:

>
> On 21 Oct 2004, at 23:31, Magnus Manske wrote:
>
>> Jens Ropers wrote:
>>
>>> Anyway, just musing and mulling:
>>> Could the PULL method be implemented w/ a checksum?
>>> Say, generate a fairly short checksum (we're talking versioning
>>> here, not security) for every article revision.
>>> Then, with each request hitting an Intarweb-facing (caching)
>>> webserver, have that cache box look if there's a version stored in
>>> its cache for said article (if not, fetch the article from the
>>> actual DB , etc.). IF however there is a cached version, ask the DB
>>> server for its current checksum on its current version. If this
>>> matches the checksum the cache has for its version, just don't
>>> bother the DB any further and serve the page from the cache. If the
>>> checksums differ, then again fetch the article from the DB and serve
>>> that (and cache the new article and checksum for potential
>>> subsequent requests). This entire checksum thing will NOT be
>>> required for any cached non-current revisions, because they won't
>>> change. So, yes, for each request hitting the cache server, there'd
>>> be a short checksum PULL with the actual DB server, but other than
>>> that (and provided the article hasn't changed) it can just be served
>>> from the cache.
>>
>> So, the DB server keeps a list with a checksum (or a version number;
>> this is supposed to be wiki-like) for each data entry, and likewise
>> does the article, right?
>
> Yup.

To add:

We shouldn't however confuse these "checksum version numbers" with
existent Wikipedia "article revision version numbers". Because past
revisions never change and the entire point in this "checksum version
number"-system is to determine whether the CURRENT version of the
article has changed without bothering the actual DB server.

Second thought, once there are version numbers for CURRENT articles
(see bug 181 -- http://bugzilla.wikipedia.org/show_bug.cgi?id=181),
then these could/should be used as our checksums: The Internet-facing
cache server would check if its article version number matches the
version number the DB presently knows as being the CURRENT one.

I hope this makes sense.

>
>> What if it more than a single data entry in that article? Like the
>> list of species I mentioned.Say, a new species was added at wikidata;
>> how to handle that one?
>> What if there are multiple queries in one article?
>> What if (in my example) the actual query is in a template?
>> What if that template includes other templates that contain queries?
>
> I wouldn't have a clue to be honest. I would, in my non-coder and
> possibly naive imagination reckon that maybe a "one article-one
> checksum" principle should work with most pages. As regards Wikidata
> et alia, well, I dunno -- counting templates (and possibly single data
> sets; but I don't really know a lot about what you're building/you've
> built there) as articles may work as well. Then again, just having
> (only) ordinary articles intelligently cached as per the above
> proposal might solve the biggest part of our problem.
>>
>> Yes, I think that it could be done. But, and I say that as someone
>> who started programming with "spaghetti code", it looks like a mess
>> to me. A dependency nightmare. We are already suffering from such
>> effects (think categories in templates) without wikidata to look out
>> for.
>> Also, you will have to query the DB server and wait for its answer on
>> *every* page view, including cached/anons, to deliver the
>> checksum(s).
>
> True.
> I'm really not trying to deliberately complicate things , but "we"
> could also make the DB servers report all checksums to a group of
> separate dedicated checksum cache servers (which would replicate
> between each other like there's no tomorrow, to make damn sure that
> all checksum cache servers would ALWAYS have the identical set of
> checksums). One of these redundant checksum servers would then be
> checked (which should spread the load) and if there's so much as a
> delay with querying one of them, then the checksum query could
> fail-over (round robin) to the next checksum cache box. There prolly
> should also remain a last resort fail-over option of querying the DB
> server direct and doing away with the entire checksum thing (which,
> after all is only there to save time and shield the DB server from
> excessive queries).
>
>> And, this will work only with the most rudimentary database
>> structure, like "SELECT * from specieslist where name='Foo'". If
>> wikidata is to become more complex than that (and I don't say it
>> should, just speculating), if wikidata tables can be interlinked,
>> then there will be no "simple" dependency on a single data entry
>> anymore.
>>
>>> Does that make sense to people?
>>> Or am I reinventing the wheel or something?
>>> I'm just brainstorming, I'm not even a real programmer.
>>> (Translation: The above may be--or may not be--rubbish.)
>>
>> Definitely not rubbish. But a lot more complicated than it looks at
>> first glance, IMHO.
>
> Yea, that's probably true. All the worse as I won't be the one coding
> it, because I, uh, lack the requisite programming skills :-/
>
> --ropers
>
>> Magnus
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l at wikimedia.org
>> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Andre Engels

subject:
[Wikipedia-l] Re: [Free-sklyarov-uk] Dutch Parliament public
	domain images and public broadcasters

body:
It's just a few parlementarians saying something on a forum
discussion, it's a long way from there to this actually existing, if
ever. Also, even though Creative Commons was prominently mentioned,
the Dutch version of the article makes me believe that "public domain"
here was meant as "available to the public" rather than "free of
copyright" (or copyleft). Which means that a website with extensive
possibilities of free downloading would also address their concerns.

Nevertheless, if I hear more of this, I will try to make that known.

Andre Engels

On Thu, 21 Oct 2004 21:49:31 +0000, David Gerard
<fun at thingy.apana.org.au> wrote:
> Seen on UK-CDR. Could our Dutch readers please advise us on
> how and when this wonderful thing will eventuate?


from_name: Brion Vibber

body:
On Oct 22, 2004, at 12:24 AM, Victor Fari?a wrote:
> I am currently working on a simple extension to add security features
> on "per page" schema.
> Its functional but has very flaws of security, it works in all pages
> and an editor must/can create a tag like :
> <security>
> user=coff,admin
> groups=sysadmin
> </security>
> and the users listed are the only ones that can read the page .
> The extension info and download are on
> http://www.wickle.com/wikis/index.php/Security_extension

Well, the first problem I see is that it doesn't work -- anyone can
simply click "edit" and remove the tags again. If it did work, then
anyone with general edit permissions could lock any page to be
inaccessible to other users just by putting in a random username/group,
creating a denial of service attack vector.

> I would like why mediawiki developers are closed to new ideas based on
> security, i think this kind of extensions are great for the wiki
> community (although its not useful for wikipedia sites) I dont want a
> CMS, i dont want to change the wiki, I like mediawiki, but some
> answers at the IRC about this implementation are very frustrating, and
> other answers are greats .

A parser extension is really the wrong place to be adding security
hooks. It won't even get called in the places where it matters, and
it's too easy to stuff in fake data or get around it.

You should probably be looking at Title::userCanEdit() and
Title::userCanRead(), and the protect/unprotect functions. Currently
these have a few hard-coded hacks instead of the general-purpose user
group system that could be done but that there's been no sufficient
interest in to write.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20041022/2dc4ff14/attachment.pgp>


from_name: Angela

subject: [Foundation-l] Meeting notes published

body:
The notes from the meeting of the Board last Saturday have now been
published on the Foundation wiki. Please see
http://wikimediafoundation.org/wiki/Meetings/October_16%2C_2004

Topic covered included
1 Grants
2 Webshop
3 Donations and Benefactors
4 Development related matters
5 French chapter feedback
6 Mandrake DVD
7 Legal issues and forks
8 Public relations
9 Miscellaneous

In addition, a meeting was held today to discuss the membership
sections of the bylaws. A summary of this meeting is at
http://wikimediafoundation.org/wiki/Meetings/October_22%2C_2004

If you would like to comment on either of these meetings or discuss
any of the points raised there, please do so at
http://meta.wikimedia.org/wiki/Talk:Wikimedia_Board_meetings

Angela Beesley


subject: [Foundation-l] Meeting notes published


from_name: NSK

body:
On Thursday 21 October 2004 20:16, Fred Bauder wrote:
> The amount would have to be tailored to reflect the financial circumstances
> of the user. The charge for Microsoft would be far in excess of $1,000 an
> edit.

But this is discrimination against the rich, isn't it? :-)

--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Project Manager of http://maatworks.wikinerds.org


subject: [WikiEN-l] Caching issues

body:
On Thursday 21 October 2004 22:59, Rick wrote:
> A problem with this, especially if you use a word processing program
> instead of a text editor, is that special characters, especially quotation
> marks, come up garbled when they get pasted back.

This happens quite a lot with M$-Word and other M$ software.

I am so happy I run KGX and my editor is Kate.

--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Project Manager of http://maatworks.wikinerds.org


subject: [WikiEN-l] Drive-by deletion

body:
On Friday 22 October 2004 00:16, Mark Richards wrote:
> I do not agree that the author of the article should be responsible
> for explaining why it is relevant - I believe the
> would be deletor should have to prove why it fits the
> criteria for deletion.

In my wiki I expect the maintainers/authors to prove the validity of their
writings preferably with external links, but this is different from WP
because anons are not allowed.

You cannot expect from an anon to explain why an article is relevant. Anons
usually don't even read the policy or they may have just found WP from
Altavista, Yahoo or Google.

If you could disallow anons, I think you could implement a policy to require
editors to explain why their edits are legit, otherwise they would be
reverted.

--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Project Manager of http://maatworks.wikinerds.org


from_name: Allan Crossman

subject: [WikiEN-l] Stopping too speedy speedy deletions

body:
 > Let's make a policy. The policy goes like this:
 >
 > "If an administrator speedily deletes an article and it then turns out
 > that the article in question was not a real candidate for speedy
 > deletion, that administrator is awarded a point.
 >
 > If an administrator gets more than 3 points during a 3 months period,
 > that administrator loses admin privilegies."

Unfair; sysops who do a lot of speedy deletions are more likely to be
awarded "points".

It's the ratio of mistakes to good actions that counts, not the number
of mistakes.

--
Allan Crossman - a.crossman at blueyonder.co.uk
The Moon is Waxing Gibbous (64% of Full)


body:
On Fri, 22 Oct 2004 05:47:57 +0300, NSK <nsk2 at wikinerds.org> wrote:
> What is VFU?

VFU is Votes for undeletion. See
http://en.wikipedia.org/wiki/Wikipedia:Votes_for_undeletion and the
undeletion policy at
http://en.wikipedia.org/wiki/Wikipedia:Undeletion_policy

Angela.


subject: [WikiEN-l] Drive-by deletion

body:
On Friday 22 October 2004 04:54, Carson, David wrote:
> It's pretty clear that we can't EXPECT anyone to read any policy.

Perhaps WP could disallow anonymous edits and require by people who open an
account to read a short policy and agree to it, for example with an "I Agree"
checkbox.

Anons that create useful content *will* create an account if they are serious
in their wikiwork.

--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Project Manager of http://maatworks.wikinerds.org


body:
On Friday 22 October 2004 04:52, Daniel P.B.Smith wrote:
> Many VfD discussions are really power struggles assessing the strength of
> factions.

I think this is a pretty bad thing and can only be stopped if you refrain from
using the broken VfD process.

You need to ensure that all WP participants want to help WP, instead of
pushing POV or exercising power. WP's shortcomings is a problem of motives:
People join WP for their own benefit instead of WP's benefit. This needs to
be corrected, otherwise WP will become a battleground and not a useful
resource.

I think you need to make account creation a bit more difficult:
0. Anons aren't needed; disable anon editing.
1. People will be required to validate their account through an e-mail
address.
2. New account holders will be denied editing until after 1-2 days.
3. To make anons open an account you could make some pages readable only by
account holders, et cetera.

--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Project Manager of http://maatworks.wikinerds.org


from_name: Jens Ropers

subject: [Wikitech-l] Slaves out of sync

body:
Shouldave, couldave.
Hindsight's 20/20, innit?

No offense, I'm ha ha only serious
(http://ha.ha.only.serious.word.sytes.org/).

On 22 Oct 2004, at 05:02, NSK wrote:

> On Friday 22 October 2004 05:19, Tim Starling wrote:
>> I've just heard that ariel, our master DB server, recently ran out of
>> disk space.
>
> You should implement some form of automatic checkup for empty disk
> space, or
> you should consider buying more disks. Disk space is cheap.
>
> --
> NSK
> Admin of http://portal.wikinerds.org
> Project Manager of http://www.nerdypc.org
> Project Manager of http://www.adapedia.org
> Project Manager of http://maatworks.wikinerds.org
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Foundation-l] servers

body:
I noticed you prefer Intel P4 for Apachies and AMD Opterons for database
servers.

Is there any reasoning behind this scheme, or is it just accidental? Do you
think P4 is better in web applications and Opteron is more suited for backend
work?

Wouldn't a dual Apache have more performance than a single one?

--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Project Manager of http://maatworks.wikinerds.org


subject: [Foundation-l] servers


body:
On Friday 22 October 2004 05:42, Rebecca wrote:
> deletionists?) who can't seem to gather consensus on VFD or VFU, and

What is VFU?

--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Project Manager of http://maatworks.wikinerds.org


body:
On Friday 22 October 2004 05:13, Andrew Lih wrote:
> 1) This is quite contrary to Wikipedia's policy to "be bold"

If "be bold" means anarchy without organisation and process then I think
that's a bad policy that should be repealled ASAP.

--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Project Manager of http://maatworks.wikinerds.org


subject: [Wikitech-l] Go

body:
Is the Go button really necessary?

I think it is highly confusing and cluttering. I would prefer to have just
Search. I have seen several MW newbies trying to figure out whether they
should click Go or Search.

If you think it should stay, it's label must change to something more
intuitive. But the best thing would be to get rid of it in 1.3.8 or 1.4.

--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Project Manager of http://maatworks.wikinerds.org