subject: [Wikitech-l] add node link

body:
Now that 1.3 has category support, perhaps you could add a "Add a new article
in this category" link in the category listing pages. Close to that link you
could have a text input box where the article title could be written.

Creating a wikilink or typing a URL in order to create a new wikinode is just
unintuitive, not only to newbies but to everyone.

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


list: wikitech-l

source: pipermail-mbox

from_name: NSK

subject: [Wikitech-l] Slaves out of sync

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


list: wikien-l

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

body:
On Friday 22 October 2004 06:50, Allan Crossman wrote:
> Unfair; sysops who do a lot of speedy deletions are more likely to be
> awarded "points".

And admins who refrain from acting as admins will never collect points, while
the others who do will inevitably get some of them (humans are error prone).
In the end, inactive and coward admins will be the only ones who will have an
excellent point record (i.e. 0). I don't think that inactivity and cowardness
should be encouraged among the admin population.

But, again, the suggestion isn't bad. Admins who create problems must be
punished. It just needs to be discussed how the system can encourage admins
to use their powers for the common good.

Perhaps negative points could be applied to admins who don't help with
administrivia and those who use their power in an evil or stupid manner.
Positive points should be given to those who provide exceptional service to
the community.

--
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: Erik Moeller

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

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

No, what you have is [[Media:Bla.jpg]], and this becomes
Media:Bla.jpg after
replaceInternalLinks, and replaceExternalLinks then doesn't reognize that
this is already HTML, and HTMLizes it again. It doesn't do this for non-
shared media links because they are rendered to , hence no absolute URL for replaceExternalLinks to grok, but we
can't do that if the shared directory is under a different URL.

Doing a placeholder substitution as suggested in this thread kinda works,
but isn't particularly elegant and likely to lead to future similar
problems. Whatever order we use, the code needs to be changed to
accommodate for special cases.

Regards,

Erik


subject: [Wikitech-l] Go

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

Then what should that button do? Are you saying you want to give up the
functionality of the Go button entirely? That would be stupid, since many
people rely on it every day, especially when the full text search is down.

I agree that the current system isn't intuitive. This bug

http://bugzilla.wikimedia.org/show_bug.cgi?id=577

proposes an alternative UI modeled somewhat after Everything2. But the two
buttons do different things, which are both useful, therefore both should
continue to be supported.

Regards,

Erik


from_name: Gerard Meijssen

subject: [Wikitech-l] [Fwd: Re: Wikizionario e-mail]

body:
Hoi,
Can someone please do something with this ??
    Thanks, GerardM

PS also asked as per standard on Commons:Non-development tasks for
developers

-------- Original Message --------
Subject: 	Re: Wikizionario e-mail
Date: 	Wed, 20 Oct 2004 12:53:07 +0000
From: 	rfrangi at coopetition.it <rfrangi at coopetition.it>
To: 	GerardM <gerardm at myrealbox.com>

Hi GerardM,
if you already know someone to contact and can arrange it would be nice. Otherwise can you direct me to someone to contact?

The name spaces should be as follows:
for it.wiktionary.org -> Wikizionario
for it.wikiquote.org -> Wikiquote
for it.wikibooks.org -> Wikibooks

Thanks,

Roberto (Snowdog)

 Da: GerardM <gerardm at myrealbox.com>
 Data: Wed, 20 Oct 2004 08:54:39 GMT
 A: Snowdog <rfrangi at coopetition.it>
 Oggetto: Wikizionario e-mail

Hoi,
Recently I have been working with Sabine to convet after the changeover from uppercase to lowercase first charactere. I have also added loads of lemma's with loads of translations.

My question,
The Namespace is still called Wikipedia, it should be either Wiktionary or Wikizionario. I think the last is best. Could you  ask the developpers to change that. If you cann't please reply and I will arrange it.

Thanks,
GerardM


from_name: Victor Fariña

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

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

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 .

regards

On Thu, 21 Oct 2004 15:18:48 +0100, Rowan Collins
<rowan.collins at gmail.com> wrote:
> 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]
>

--
Problems with Windows - Reboot.
Problems with Linux   - Be root.

Vic (aKa CoffMan)
vic at wickle.com
wickle at gmail.com


from_name: Eric B. and Rakim

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

body:
Andrew Lih:
>
>1) This is quite contrary to Wikipedia's policy to "be bold"
>
>2) Before instituting these hard metrics to de-admin someone, one
>should have hard metrics indicating this is truly a problem. It's not clear
>it is.

Wikipedia's policy to "be bold" only applies for non-admin actions.
Deletions, bannings and other admin privilegied actions aren't included. Not
even reversions part of "be bold" anymore I think. :)

Is this truly a problem? I don't know and it is impossible for someone
without adminship to ever find out. But considering the number of mailing
list posts that pop up it seem to be a problem.

>It isn't. It's yet another example of a small extremist group (why is
>it that our inclusionists are so much more extremist than our
>deletionists?) who can't seem to gather consensus on VFD or VFU, and
>so attempt to change the policies to get around this.

Behave.

Allan Crossman
>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.

When someone goes to a trial IRL, he or she can't say "But look! I gave the
children presents! Doesn't that make up for I robbed a bank?"

Or to put it in Wikipedia terms; A productive writer will be banned just as
fast as a non-productive one if both continue to personal attack their
peers.

Ideally, the system maybe should include good deeds too. But that would make
it way to complicated. Besides, the number of points needed for de-adminship
would have to be so sufficently large that it would only affect those admins
that repeatedly have failed and not learnt from their mistakes.

csherlock:
>Firstly, deleted articles are not permanently deleted. We can retrieve
>them. See [[Wikipedia:Undeletion policy]]. Secondly, if an admin is
>making consistent deletions and not listening to others, they can be
>de'sysoped after a request from other wikipedia editors. Just go talk to
>the [[Wikipedia:Arbitration Committee]]. See also
>[[Wikipedia:Administrators#Administrator_abuse]].

Ok. Lets talk about reality. :) Will something happen to the admin who
deleted http://en.wikipedia.org/wiki/Geno%27s_steaks that Anthony DiPierro
mentioned? A reprimand even? Or what about the unjust deletions that Charles
Matthews spotted? Does anyone even know which admins did the deletions?

I'm not bloodthirsty, just think that something has to be done. In this case
someone should tell the admins "You really shouldn't do that.". So that it
stops.

To those who realise too speedy deletions is a problem, but do not like my
proposal: Do you have a better idea?

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.com/


from_name: J.F. de Wolff

subject: [WikiEN-l] Re: Drive-by deletion

body:
 >Mark Richards wrote:
 >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

I meant something different. An article (especially by an anon) in which
many linked terms are not yet Wikipedia articles is bound to do poorly in
Vfd and probably get deleted. It has to do with an anon's understanding of
good linking.
Another good one is where all links are actually external links that have
been made to display as wikilinks (but the colour gives them away).
I believe that there should be an intermediate between speedy and Vfd, on
pages where the only question is whether they should be included _in their
present form_. This process can be reversed if the article grows. It also
means the RC patrol can request inclusion review shortly after a page's
creation.

JFW


from_name: David Iberri

subject: [Wikitech-l] Go

body:
--- NSK <nsk2 at wikinerds.org> wrote:
> Why not implement this:
> 1. User types nothing
> 2. User clicks Go
> 3. Random page code is executed

That's unintuitive, IMO. Besides, we already have a "Random page" link in the toolbar.

-- David Iberri

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


subject: [Wikitech-l] Error in page render

body:
--- Giovanni <gputignano at tiscali.it> wrote:
> Starting from today morning, on the status bar of my browser I get an error
> about the rendering of the page.
> You can try at http://www.programmiamo.it. Before today it was right, only
> today suddendly it has gone wrong.

There are a few errors in your [[Monobook.js]]
(http://www.programmiamo.it/wiki/index.php?title=MediaWiki:Monobook.js) that can be fixed by
properly escaping single quotes. E.g., change this line

  ta['ca-edit'] = new Array('e','Puoi modificare questa pagina. Usa l'anteprima prima di
salvare.');

to

  ta['ca-edit'] = new Array('e','Puoi modificare questa pagina. Usa l\'anteprima prima di
salvare.');
                                                                     ^^

-- David Iberri

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


from_name: Poor, Edmund W

subject: [WikiEN-l] Deleting vs. improving

body:
This topic has come up countless times in the 3 years I've been
contributing to Wikipedia. Everyone wants some sort of policy which will
automagically result in more great articles, but no one wants to do any
heavy lifting.

* When we had trouble with poor spelling, someone wanted to deploy
  spell-check software. But we soon realized that wouldn't work,
  because of pairs like THEIR and THERE which require artificial
  intelligence -- which is STILL too unreliable for this.

There is no substitute for good writing. Nothing else will improve a bad
article but good writing. Deleting stubs will not *cause* a good
replacement article to appear. Votes to determine "consensus" use up 3
to 10 times as much energy as it actually takes to fix a marginal
article.

About once a month, someone will VfD an article I've written. A power
struggle then ensues. In nearly every case, the outcome is that I
improve the article so much that it is not even CLOSE to the
originally-listed VfD item -- and the article "survives".

I'd rather people would contact me on my talk page and complain about my
poor writing than launch a campaign to condemn my work. Struggling
against condemnation is dreary and often discouraging.

My thanks go out to all those who have dropped me a line, saying, "Did
you know that the 200-word article you just wrote is on VfD, and the
vote is 7-1 for deletion?"

To sum up: I think VfD is a waste of time, and I prefer not to
participate in these votes. If an article is VfD'ed, and I think the
topic is important enough, I'll just revise it and remove the 'notice'
(with a comment in the edit summary or on the talk page explaining my
improvements).

Ed Poor, aka "Uncle Ed"
Stubborn Pioneer of Excellence in Writing


from_name: Ray Saintonge

subject: [Wikitech-l] Slaves out of sync

body:
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.
>
It seems that telling others what they should do is one of your favorite
passtimes.  I suspect that Tim considered your suggestions long before
you made them.

Ec


from_name: Bryan Derksen

subject: [WikiEN-l] Drive-by deletion

body:
At 04:35 PM 10/22/2004 +0300, NSK wrote:

>On Friday 22 October 2004 16:21, John Lee wrote:
> > The resolution is always the same: Forcing anons to
> > register before editing is not a tenable idea.
>
>Then, perhaps anon edits should be moderated.

They _are_ moderated, after-the-fact, by everyone else on Wikipedia.

It used to be easier when Wikipedia was smaller, but now RecentChanges
flies by so quickly I don't bother to monitor it any more. There have been
proposals for ways to ake it easier again, I guess we'll see how those turn
out in the long run.


subject: [Wikitech-l] Go

body:
--- Magnus Manske <magnus.manske at web.de> wrote:

> I propose to change the buttons from "Go", "Search" to "Go, "Chess"  ;-)

Can't find string terminator '"' anywhere before EOF at -e line 1. ;-)

-- David Iberri

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


from_name: Magnus Manske

subject: [Wikitech-l] Re: WikiData: A rant

body:
Tim Starling wrote:

> Magnus Manske wrote:
>
>> <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>
>
>
> My approach would be to not use SQL, or anything similar. Use a custom
> syntax with a greatly restricted feature set. Think in terms of
> applications. Only allow queries which can be cached and invalidated.
> Fetching single rows would be a good place to start, that's all I
> would have implemented if I followed my WikiDB idea.

Reducing the possible queries would simplify things. But, I was under
the impression that more is demanded from a WikiData system, and we
should probably get this right from the start.
But, I am not insisting on SQL or anything. It just seemed the natural
choice for me, besides XQueries.

> Cache invalidation or purging is the standard solution here. Make a
> list of every article which fetches a particular row, and update it on
> edit. Then when the row changes, invalidate all the articles in the list.

No problem here.

> Make a list of every article which contains a list of species in the
> Foobus family. Invalidate all articles in the list every time a
> species is added or removed from that family.

Now *that* requires that we keep
* the original query for each article, and its results
* rerun that query every time an (*any*) entry has changed or was added,
and compare it to the original results

Also, that works only if we have, for example, all the species data in
one table. Like, kingdom, phylum, class, order, family, genus.
If we, instead, decide to have one table for species which contains only
the genus, then another table for the genus which, apart from
information about the genus in general, contains the order, etc., then
this will become a problem. *Theoretically*, an order could be moved
from one subclass to another. Now all species in a genus in a family in
a suborder in that order needs to be updated. Good luck with that.

> It's disappointing to give up on some of the dream, but at some stage
> of the development process, you have to be realistic. My advice would
> be to set a short term goal (a few months or so), code something
> useful, admire your work, then go from there.

If there were consensus to limit WikiData to all but the most simple
queries ("... WHERE name='Foobus'"), and to give up on instant updates
and just clear the cache once in a while to update data in articles,
something can be done.
Otherwise, I'll stay clear on this one, unless it turns out there's
something obvious I missed.

Magnus


subject: [Wikitech-l] WikiData: A rant

body:
Alan Wessman wrote:

>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.
>
>
That would be a way, and actually easy to code ;-)

 From a usability standpoint, it would be a last resort, though.

Magnus


from_name: Andrew Lih

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

body:
Some thoughts:

1) This is quite contrary to Wikipedia's policy to "be bold"

2) Before instituting these hard metrics to de-admin someone, one
should have hard metrics indicating this is truly a problem. It's not clear
it is.

-Andrew (User:Fuzheado)

On Thu, 21 Oct 2004 16:20:52 -0700 (PDT), Mark Richards
<marich712000 at yahoo.com> wrote:
> 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
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
Andrew Lih
andrew.lih at gmail.com


subject: [Wikitech-l] Go

body:
--- NSK <nsk2 at wikinerds.org> wrote:

> On Friday 22 October 2004 18:43, David Iberri wrote:
> > That's unintuitive, IMO. Besides, we already have a "Random page" link in
> > the toolbar.
>
> You could remove that link and make space for something else.

Sure, but that doesn't make things any more clear for the casual user. The aptly-titled "Random
page" link is very intuitive. But it's not at all obvious to a newbie that they can fetch a random
page by clicking "Go".

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

> Search
> +---------------+  ____
> |               | (_Go_)
> +---------------+
>
>   Advanced_search
>   ---------------
>
> * Clicking Go after filling in the text box works as before.
> * Clicking Go without filling in the box produces a JavaScript message:
> "Please enter a search query before clicking Go."
>    (Don't use the current message, which unduly emphasizes the "error"
> aspect of it.)
> * Clicking on the "Advanced search" <u>link</u> will take you to the a
> advanced search feature (where you can modify the tick-boxes and so
> forth).

I like this approach. I agree that the current message (i.e. "Badly formed search query") should
be replaced with something better, and a bit more user-friendly.

-- David Iberri

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


subject: [Wikitech-l] Error in page render

body:
--- Giovanni <gputignano at tiscali.it> wrote:

> I've tried to reset [[Monobook.js]] page but the problem is the same.
> I've also checked other messages that I've modified yesterday but I've not
> resolved yet.

It's probably a caching issue. Try pressing CTRL-F5 in your browser to get a fresh copy of the
page. I did so, and I no longer receive the error message when viewing

  http://www.programmiamo.it/wiki/index.php?title=Main_Page

-- David Iberri

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


from_name: Rebecca

subject: [WikiEN-l] Drive-by deletion

body:
If there are articles listed appropriately, then you, just like any
other Wikipedian, have to right to vote "keep".

-- ambi

On Thu, 21 Oct 2004 14:16:09 -0700 (PDT), Mark Richards
<marich712000 at yahoo.com> wrote:
> 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
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


list: wikipedia-l

from_name: Mark Williamson

subject: [Wikipedia-l] slow hardware

body:
My guess is that you wrote this during last night's little incident.

Wikipedia is almost never quite that slow, we were having some
problems where all but one of the database servers were offline for a
bit, thus the really sluggishly slowness.

--node

On Fri, 22 Oct 2004 20:23:30 +0300, NSK <nsk2 at wikinerds.org> wrote:
> Sorry I forgot to include a link to Coral which is:
> http://www.scs.cs.nyu.edu/coral/
>
>
>
> --
> 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
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


from_name: dpbsmith at verizon.net

subject: [WikiEN-l] Re: Anthony does not vote "Keep" on everything

body:
>From: "Anthony DiPierro" <anthonydipierro at hotmail.com>

>Maybe I should put this on my talk page, because there are a few people out
>there ... who insist on incorrectly making the claim that I vote keep on
>everything, and some people apparently believe [them].

>Anthony

Just for the record: I personally have strong disagreements with Anthony
regarding what things should be deleted. But he does not vote "keep" on
everything, he can articulate a rationale for what he does (the phrase
"method in his madness" comes to mind) and, in fact, he recently supported a
speedy-deletion decision of mine in Votes for Undeletion.


from_name: Anthony DiPierro

subject: [WikiEN-l] Drive-by deletion

body:
> Although the arbitrators didn't
> condemn straight keep voting (in other words, they didn't take issue
> with him voting keep for every article proposed on VfD), they did make
> it clear that voting against the general consensus without providing a
> reason (the manner of voting, to use an arbitrator's phrase) is not
> condoned.

> So inclusionists who intend to sabotage such a process would have to be
> handled somehow. All this is based on how I understood Anthony's case;
> if I'm mistaken, please forgive and correct me.

No, it was actually more the opposite.  The arbitrators didn't have a
problem with the way I voted (and it wasn't keep for every article, it was
keep for a certain class of articles, mainly those about real people).  The
arbitrators had a problem with the reasons I gave (which were occassionally
sarcastic or hostile).  They also had a problem with the fact that on a few
occassions I added things to VfD which I didn't want deleted just to try to
prove a point.  Both were mistakes, and I fully admit that.

I agree with you that the arbitration ruling is extremely ambiguous on this,
though.  I even brought up the fact that saying that I shouldn't be
"provacative" is completely meaningless when the arbitration decision was
being voted on.  But, even as arbitration was ongoing I continued to vote
"Keep" on a large number of articles, and the arbitration committee passed a
ruling saying that I had ceased the improper behavior, so the improper
behavior certainly wasn't just the fact that I voted keep a lot.

All that said, I never voted keep for every article.  I think that pretty
much every article which has any information that is NPOV and verifiable (in
a respected source such as a government site or national non-tabloid
newspaper) should be kept or merged and redirected.  If the verifiability is
disputed, I support moving the information to the talk page where this can
be sorted out.  I support *massive* editing of many of the articles
submitted to VfD.  When something's listed as an ad, for instance, I support
cutting the article down to the basic NPOV facts.  Occassionally, especially
with articles which are doomed to never be more than dictionary definitions
(articles about adjectives, for instance), an appropriate redirect can't be
found (or too many can be found so a single one can't be chosen), and I
don't oppose transwiking and deleting.  I suppose there are some limited
exceptions to all these rules, but I rarely find them on VfD.

Maybe I should put this on my talk page, because there are a few people out
there (RickK, who votes delete more than I vote keep, comes to mind) who
insist on incorrectly making the claim that I vote keep on everything, and
some people apparently believe their lies.

Anthony


subject: [WikiEN-l] Drive-by deletion

body:
> The thing is, this has been tried directly on VFD before, and failed,
> because people (usually inclusionists) bitch about the early removal of
> debates/pages. Perhaps what is called for is an amendment to deletion
> policy. Heck, I don't know.

The best work I've seen was made by Erik M?ller.  Essentially, deletion
first passes through a consensus stage where reasons are given and if any
reason is left unanswered the page is deleted.  If there are objections
answering all the reasons for deletion then it is deleted.  Then, only if it
doesn't pass there does it move to VfD where 80% vote is needed to delete.

I opposed the proposal, mainly because the reasons for deletion didn't need
to be agreed upon in advance, so someone could list a bogus reason "Delete
because it is a US President" and no one could effectively counter the
reason.  But I think it could be worked on, and had a large majority
support.

See http://en.wikipedia.org/wiki/Wikipedia:Deletion_requests

Anthony


from_name: Stan Shebs

subject: [WikiEN-l] Drive-by deletion

body:
NSK wrote:

>
>Sites that claim to be serious and wish to compete with Britannica need
>motivated committed editors, proof readers, maintainers, sysops and policy
>makers, i.e. organisation and structure.
>
WP has all that already - try to mess up one of the articles
I maintain, I'm going to be all over you. A lot of the social
structure is not obvious to casual onlookers, so they think
it's not there.

Stan


subject: [Wikitech-l] Go

body:
--- NSK <nsk2 at wikinerds.org> wrote:

> 5. A "Random page" link under the link above.
> 6. The "Random page" link will be removed from the navigation box to make room
> for something else or to remove excessive cluttering

There's no need to couple the "random page" and "search" features as they're scarcely related.
Also, I don't consider the navigation box to be "excessively cluttered" as you say so I don't
think it should be removed.

-- David Iberri

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


subject: [WikiEN-l] Drive-by deletion

body:
> I thought that's what I was saying - after all, if people have a good
> reason for voting "keep" on every listed article, I don't see what's
> stopping them from doing so. If they just vote keep for the sake of
> being a bitchy inclusionist, then that's wrong. That's how I understood
> your case; as I said, the arbitrators didn't take issue with what you
> voted for, but how you voted for it.

I never voted keep for the sake of being a bitchy inclusionist, I just used
sarcasm in the reason I gave.  I still wanted the articles kept, that's why
I voted keep.  But some admins said they were going to throw out votes which
didn't have a reason, and yet they would count reasons which were completely
irrelevant to the decision.

For example, someone wrote for their deletion reason that the person works
for CNet.  So I wrote for my reason to keep that the person works for CNet,
because that's as much a reason to keep as it is one to delete.  Someone
else wrote "idiosyncratic" as the reason to delete, so I wrote
"idiosyncratic" as the reason to keep, because that's not a reason to delete
something.

Anthony


from_name: Greg Bildson

subject: [Wikitech-l] MediaWiki / PHP / SQL / Web Developer

body:
I checked with the last person that posted a similar request so apologies if
this email breaks the rules ...

Lime Wire is looking for an experienced web designer/developer with a mix of
strong PHP and web dev skills.  We are looking to extend MediaWiki in a
serious way amongst other  development work.

Required skills:
+ Bachelor?s Degree or above.
+ Experience developing PHP and SQL driven websites.
+ Good knowledge of HTML, DHTML, Javascript, and CSS.
+ Ability to code without the use of a WSIWIG editor.

Desired skills:
+ Experience with Wikis or MediaWiki a large plus.
+ Experience working on Linux servers with apache via ftp, sftp, a plus.
+ Experience interacting with payflow and paypal a large plus.
+ Illustrator and graphic artist experience a large plus.
+ Music, Movie or Digital Media enthusiast is a plus.

Lime Wire's flagship product, LimeWire, is one of the top p2p file-sharing
clients in the world. Check out www.limewire.com. We're located in lovely
TriBeCa (NYC) and want someone to join our office full-time. Salary/benefits
are competitive, not to mention a fantastic view from the roof and all the
foosball you can handle.

If you're interested, or know someone who is, email a cover letter and
resume (.doc, .pdf preferred) to webjob1(at)limewire.com.


from_name: Charles Matthews

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

body:
>Also, Charles Matthews
> has also not mentioned specifically what the article names were that
> were deleted.

That's not what I said - I said one inappropriate marking as a speedy
deletion.  I deliberately didn't identify the users, one of whom was quite
new.

Charles


from_name: Carson, David

subject: [WikiEN-l] Drive-by deletion

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

I don't see what difference it makes whether an editor is anonymous or
whether they created an account.

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

It's pretty clear that we can't EXPECT anyone to read any policy. It
would be nice - you can't get to the edit box on the edit page without
skipping over a bunch of links to things that you are asked to read
BEFORE creating your first article - but experience has shown that you
can never force anyone to RTFA before they jump in.

And given that fact, the only two solutions I can see are:

1. Delete a lot of crap that people were asked not to create
2. Alter our community standards so we don't mind having a lot of crap,
and stop asking people not to create it

Cheers!
David...

_____________________________________________________________________________________________________
This email and its attachments are for the sole use of the addressee and may contain information which is confidential and/or
legally privileged. This email and its attachments are subject to copyright and should not be partly or wholly reproduced without
the consent of the copyright owner. Any unauthorised use of disclosure of this email or its attachments is prohibited. If you receive
this email in error, please immediately delete it from your system and notify the sender by return email.


from_name: Erik Moeller

subject: [Wikitech-l] Re: mediawiki evaluation

body:
Jonah-
> I just lament the lack of a compenent architecture that allows for the
> inclusion of third party extras.  A drawing tool would be really nice,
>   a calendar widget would be very useful on intranets, etc etc.

MoinMoin and TWiki are definitely good choices when it comes to
modularity. MediaWiki has still some way to go in that department - we
only have a basic extension scheme. Our needs are driven primarily by the
large Wikimedia projects, rather than lots of people doing very different
things with wikis.

Personally, I tend to favor integrated solutions over plug-ins, so I
invest my time in trying to build good functionality into the software
proper. For example, a calendar is nice, but being able to work with the
time dimension everywhere is much more interesting: Show me all entries in
this category older than X, link to the version of this page from 3 weeks
ago, etc.

I have to reiterate my point, however, that most people overestimate the
value of these things, and underestimate issues like usability and
scalability. I can cite countless wikis which failed just because they
used CamelCase and failed to enforce sane link rules, for instance. My
advice to you would be to show your users multiple wikis, and let them
tell you which one they find the most pleasant to use.

> Still there will be text areas on your site, outside of your wiki where
> you might want to accept wiki syntax.  Does mediawiki have an api that
> lets you easily use its parser?

Easily - no. But the parser code is reasonably isolated to make that
feasible. The biggest problem is the lack of documentation in the code in
that particular area.

> Thanks for the references. If you have the link to the german version
> I'll babble it.

Not free, unfortunately:
http://www.heise.de/kiosk/archiv/ct/2003/25/202

Regards,

Erik


from_name: Mark Ramm

subject: [Wikitech-l] Re: Slaves out of sync

references:
<cl9qnu$si8$1@sea.gmane.org>
	<200410220602.21664.nsk2@wikinerds.org> <cl9v13$5rn$1@sea.gmane.org>

body:
> We have used a script to automatically move old binlogs in the past, but
> we haven't been using it recently. It takes some amount of effort to set
> up and maintain.

I am testing out Nagios and Zabbix to monitor our servers here at my
work.  It always a good idea monitoring, especially if you can
configure alerts when you get to 80% of disk space (or whatever) so
you have time to plan for and schedule the necessary upgrades.

Zabbix in particular allows you to get a good historical view with web
accessible charts, and all of that, of what resources are being used
on each of your servers.  Nagios is more popular, but harder to set
up, doesn't do historical trending in it's default configuration.

If it would be of use, I would be willing to try to help set with
setting up an open source monitoring solution for the wikipedia
servers.

--Mark Ramm-Christensen


from_name: Petr Kadlec

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

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

Yes, definitely, I have sent a similar report about cs: Wikipedia a
few days ago (http://mail.wikimedia.org/pipermail/wikitech-l/2004-October/025853.html),
and the problem still happens once in a while. Just now, it has
happened again -- compare
http://cs.wikipedia.org/w/wiki.phtml?title=Wikipedie:Pod_l%C3%ADpou&diff=0&oldid=19599
with http://cs.wikipedia.org/wiki/Wikipedie:Pod_l%C3%ADpou

Mormegil


from_name: Tim Starling

subject: [Wikitech-l] Slaves out of sync

body:
I've just heard that ariel, our master DB server, recently ran out of
disk space. Writes to the binlogs stopped but it kept committing to its
local disk, thereby putting all the slaves irreversibly out of sync.
This is a nasty failure mode that we previously weren't aware was possible.

To resync the slaves, we will have to put the site into read-only mode
for maybe 6-12 hours. I'm hoping this will be done as soon as possible,
because in the meantime, we will have poor performance. The slaves used
to share the read load. Also, if ariel dies, we'll be down to periodic
backups, meaning data loss and days of downtime.

Search will be disabled until the slaves are resynced, and other
emergency optimisation measures such as watchlist caching might also
need to be used.

-- Tim Starling


from_name: Brion Vibber

subject: [Wikitech-l] MediaWiki licensing

body:
On Oct 22, 2004, at 10:20 AM, NSK wrote:
> Would you be willing to sell MediaWiki 1.3.7 (the stable version as
> published
> in wikipedia.sf.net) or any next version, together with the MediaWiki
> Handbook (as available from meta.wikipedia.org) under a license
> similar to
> the modified BSD license? and for how much?

No. We put a lot of work into this and have benefited from code from
other people using the GPL; please either share it on the same terms or
write your own code.

-- 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/6f233df2/attachment.pgp>


body:
Well, I'm not sure if you are talking about a location in the mid-west
versus New York City but I suspect that you are referring to the USA versus
Germany/Europe.

I expect that for a serious MediaWiki developer, we would be willing to have
someone work remotely and perhaps help train a developer on this side of the
Atlantic as well.  I'll check into that a little more but I suspect that we
would be willing to work with a very well skilled person part-time in that
regard at a minimum.

While we're on the subject of Germany, perhaps someone can explain to me the
payment mechanism that Germans use for web purchases.  I've been told
repeatedly that there is a special form of Bank transfer used.  A link
pointing to a major payment processor in that regard would be appreciated.

Thanks
-greg

> -----Original Message-----
> From: wikitech-l-bounces at wikimedia.org
> [mailto:wikitech-l-bounces at wikimedia.org]On Behalf Of Thomas R. Koll
> Sent: Friday, October 22, 2004 11:54 AM
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] MediaWiki / PHP / SQL / Web Developer
>
>
> On Fri, Oct 22, 2004 at 11:21:39AM -0400, Greg Bildson wrote:
> > I checked with the last person that posted a similar request so
> apologies if
> > this email breaks the rules ...
>
> He didn't. I think it a good idea if jobs concering mediawiki are kept
> among the devs or almost devs like me (guess who got the last job...)
>
>
> But the point why no one might want the job is the location,
> but tell us if it's not a requirement anymore.
>
> ciao, tom
> --
> == Weblinks ==
> * http://shop.wikipedia.org - WikiReader Internet zu kaufen
> * http://de.wikipedia.org/wiki/Benutzer:TomK32
> * http://www.hammererlehen.de - Urlaub in Berchtesgaden
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>


from_name: tic at tictric.net

subject: [Wikitech-l] Go

body:
Am Fri, 22 Oct 2004 05:55:00 +0300 hat NSK <nsk2 at wikinerds.org>
geschrieben:

> Is the Go button really necessary?

Go should actually renamed to "Go to" if you ask me. It makes it's meaning
a lot clearer.
So I would rather abandon "Search" then "Go".

--tic

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

--
+--------------------------+
tic at tictric.net

|     ,__o
|   _-\_<,
|  (*)/'(*)


from_name: Mark Richards

subject: [WikiEN-l] Deleting vs. improving

body:
I could not agree more. I would like to limit vfd to
only things that pose a real liability, like slander,
copyvios etc, not simply articles that need
improvement.
It is a complete waste of everyone's time to have
people listing articles that they don't think are good
enough for deletion simply to try to provoke.
Mark

--- "Poor, Edmund W" <Edmund.W.Poor at abc.com> wrote:

> This topic has come up countless times in the 3
> years I've been
> contributing to Wikipedia. Everyone wants some sort
> of policy which will
> automagically result in more great articles, but no
> one wants to do any
> heavy lifting.
>
> * When we had trouble with poor spelling, someone
> wanted to deploy
>   spell-check software. But we soon realized that
> wouldn't work,
>   because of pairs like THEIR and THERE which
> require artificial
>   intelligence -- which is STILL too unreliable for
> this.
>
> There is no substitute for good writing. Nothing
> else will improve a bad
> article but good writing. Deleting stubs will not
> *cause* a good
> replacement article to appear. Votes to determine
> "consensus" use up 3
> to 10 times as much energy as it actually takes to
> fix a marginal
> article.
>
> About once a month, someone will VfD an article I've
> written. A power
> struggle then ensues. In nearly every case, the
> outcome is that I
> improve the article so much that it is not even
> CLOSE to the
> originally-listed VfD item -- and the article
> "survives".
>
> I'd rather people would contact me on my talk page
> and complain about my
> poor writing than launch a campaign to condemn my
> work. Struggling
> against condemnation is dreary and often
> discouraging.
>
> My thanks go out to all those who have dropped me a
> line, saying, "Did
> you know that the 200-word article you just wrote is
> on VfD, and the
> vote is 7-1 for deletion?"
>
> To sum up: I think VfD is a waste of time, and I
> prefer not to
> participate in these votes. If an article is VfD'ed,
> and I think the
> topic is important enough, I'll just revise it and
> remove the 'notice'
> (with a comment in the edit summary or on the talk
> page explaining my
> improvements).
>
> Ed Poor, aka "Uncle Ed"
> Stubborn Pioneer of Excellence in Writing
> _______________________________________________
> 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


subject: [WikiEN-l] Drive-by deletion

body:
They are, just like everyone elses.
Banning anons would only have the effect of reducing
contributions. Most problematic edits actually come
from logged in users.
Mark

--- NSK <nsk2 at wikinerds.org> wrote:

> On Friday 22 October 2004 16:21, John Lee wrote:
> > The resolution is always the same: Forcing anons
> to
> > register before editing is not a tenable idea.
>
> Then, perhaps anon edits should be moderated.
>
> --
> 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
> _______________________________________________
> 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


subject: [WikiEN-l] Drive-by deletion

body:
I resent the implication that voting to keep something
is somehow reprehensible.
Mark

--- Anthony DiPierro <anthonydipierro at hotmail.com>
wrote:

> > Although the arbitrators didn't
> > condemn straight keep voting (in other words, they
> didn't take issue
> > with him voting keep for every article proposed on
> VfD), they did make
> > it clear that voting against the general consensus
> without providing a
> > reason (the manner of voting, to use an
> arbitrator's phrase) is not
> > condoned.
>
> > So inclusionists who intend to sabotage such a
> process would have to be
> > handled somehow. All this is based on how I
> understood Anthony's case;
> > if I'm mistaken, please forgive and correct me.
>
> No, it was actually more the opposite.  The
> arbitrators didn't have a
> problem with the way I voted (and it wasn't keep for
> every article, it was
> keep for a certain class of articles, mainly those
> about real people).  The
> arbitrators had a problem with the reasons I gave
> (which were occassionally
> sarcastic or hostile).  They also had a problem with
> the fact that on a few
> occassions I added things to VfD which I didn't want
> deleted just to try to
> prove a point.  Both were mistakes, and I fully
> admit that.
>
> I agree with you that the arbitration ruling is
> extremely ambiguous on this,
> though.  I even brought up the fact that saying that
> I shouldn't be
> "provacative" is completely meaningless when the
> arbitration decision was
> being voted on.  But, even as arbitration was
> ongoing I continued to vote
> "Keep" on a large number of articles, and the
> arbitration committee passed a
> ruling saying that I had ceased the improper
> behavior, so the improper
> behavior certainly wasn't just the fact that I voted
> keep a lot.
>
> All that said, I never voted keep for every article.
>  I think that pretty
> much every article which has any information that is
> NPOV and verifiable (in
> a respected source such as a government site or
> national non-tabloid
> newspaper) should be kept or merged and redirected.
> If the verifiability is
> disputed, I support moving the information to the
> talk page where this can
> be sorted out.  I support *massive* editing of many
> of the articles
> submitted to VfD.  When something's listed as an ad,
> for instance, I support
> cutting the article down to the basic NPOV facts.
> Occassionally, especially
> with articles which are doomed to never be more than
> dictionary definitions
> (articles about adjectives, for instance), an
> appropriate redirect can't be
> found (or too many can be found so a single one
> can't be chosen), and I
> don't oppose transwiking and deleting.  I suppose
> there are some limited
> exceptions to all these rules, but I rarely find
> them on VfD.
>
> Maybe I should put this on my talk page, because
> there are a few people out
> there (RickK, who votes delete more than I vote
> keep, comes to mind) who
> insist on incorrectly making the claim that I vote
> keep on everything, and
> some people apparently believe their lies.
>
> Anthony
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
http://messenger.yahoo.com


body:
It isn't. It's yet another example of a small extremist group (why is
it that our inclusionists are so much more extremist than our
deletionists?) who can't seem to gather consensus on VFD or VFU, and
so attempt to change the policies to get around this.

-- ambi

On Fri, 22 Oct 2004 10:13:32 +0800, Andrew Lih <andrew.lih at gmail.com> wrote:
> Some thoughts:
>
> 1) This is quite contrary to Wikipedia's policy to "be bold"
>
> 2) Before instituting these hard metrics to de-admin someone, one
> should have hard metrics indicating this is truly a problem. It's not clear
> it is.
>
> -Andrew (User:Fuzheado)
>
> On Thu, 21 Oct 2004 16:20:52 -0700 (PDT), Mark Richards
>
>
> <marich712000 at yahoo.com> wrote:
> > 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
> >
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
>
>
> --
> Andrew Lih
> andrew.lih at gmail.com
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [WikiEN-l] Drive-by deletion

body:
This would just mean yet another page that had to be
monitored to make sure inapropriate things didn't slip
through.
* Delete. No need for it.

Mark

--- Anthony DiPierro <anthonydipierro at hotmail.com>
wrote:

> > The thing is, this has been tried directly on VFD
> before, and failed,
> > because people (usually inclusionists) bitch about
> the early removal of
> > debates/pages. Perhaps what is called for is an
> amendment to deletion
> > policy. Heck, I don't know.
>
> The best work I've seen was made by Erik M?ller.
> Essentially, deletion
> first passes through a consensus stage where reasons
> are given and if any
> reason is left unanswered the page is deleted.  If
> there are objections
> answering all the reasons for deletion then it is
> deleted.  Then, only if it
> doesn't pass there does it move to VfD where 80%
> vote is needed to delete.
>
> I opposed the proposal, mainly because the reasons
> for deletion didn't need
> to be agreed upon in advance, so someone could list
> a bogus reason "Delete
> because it is a US President" and no one could
> effectively counter the
> reason.  But I think it could be worked on, and had
> a large majority
> support.
>
> See
>
http://en.wikipedia.org/wiki/Wikipedia:Deletion_requests
>
> Anthony
> _______________________________________________
> 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


subject: [WikiEN-l] Deletion and notability

body:
Wonderful. Let's not delete things that don't meet the
criteria for deletion!
Mark

--- Simon Pulsifer <se_pulsifer at yahoo.ca> wrote:

> I don't post to the mailing list much, but deletion
> has recently become an area of great interest to me.
>
> First off I don't think VfD is "broken." I think it
> is
> wonderful and in an ideal world every article would
> be
> given as much scrutiny as those of VfD receive.  At
> least 99% of deletion decisions are valid.
>
> I do, however, see some worrying trends. My concern
> is
> over the issue of notability.  In the past the
> articles listed on VfD were there because they were
> pure fiction, vanities, nonsense, or advertising. In
> recent months, however, an increasing number of
> articles are being listed because simply because
> they
> are seen as not being notable enough for an
> encyclopedia.
>
> This is despite there being nowhere in What
> Wikipedia
> is not, Wikipedia:Deletion policy, or
> Wikipedia:Vanity
> articles where articles on non-notable things listed
> as being eligible for deletion.  There is no
> consensus
> that things that are well-known but not notable
> should
> eligible for deletion.
>
> Originally non-notable things and people were not
> deleted simply because they were not well known, but
> rather because articles on non-famous individuals,
> neologisms, garage bands, etc. are unverifiable and
> prone to bias.  Over time "non-notable things should
> be deleted because they inevitably violate
> Wikipedia's
> goal of a neutral and high quality encyclopedia" was
> simplified to just "non-notable things should be
> deleted."  With the original reasoning being lost
> the
> definition for what is not notable has increasingly
> been set by wholly arbitrary criteria.  There are at
> least two users, for instance, who today vote to
> delete anything to do with fictional worlds and the
> only justification they feel is necessary is to
> declare these things "not notable" or "fancruft".
>
> For the most part things that are well known, but
> considered by some not to be notable, do not get
> consensus for deletion. Those not getting deleted
> are
> also a problem because they clog VfD and waste
> everyone's time.  Those occasional ones that do
> receive consensus for deletion are an even greater
> problem because content is being removed from
> Wikipedia counter to existing policy and against the
> consensus of all but the small VfD community.
>
> There has been an attempt to add lack of notability
> as
> a reason for deletion (see
> [[Wikipedia:Importance]]).
> This effort seems to have failed and there is no
> current policy for deleting non-notable things,
> other
> than vanity articles.
>
> I have recently been doing the majority of the
> removing of articles from VfD/Old.  I am no longer
> going to delete articles that receive consensus for
> deletion purely because they are not notable.
> Rather
> I propose moving them to [[Wikipedia:List of
> articles
> awaiting a policy to be deleted]]. Articles that do
> not meet any of the 30 criteria listed on What
> Wikipedia is not and the Deletion policy page should
> be set aside.  When and if new policies are worked
> out
> that provide a justification for deleting these
> articles they can then be quickly deleted.
>
> - SimonP
>
>
>
>
>
>
___________________________________________________________ALL-NEW
> Yahoo! Messenger - all new features - even more fun!
>  http://uk.messenger.yahoo.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


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

body:
By 'we' I presume you mean admins, so not scrutiny can
be given by regular users since they can't see the
content of the deleted article.
Mark

--- "csherlock at ljh.com.au" <csherlock at ljh.com.au>
wrote:

> OK, I'm topposting and loving it!
>
> Firstly, deleted articles are not permanently
> deleted. We can retrieve
> them. See [[Wikipedia:Undeletion policy]]. Secondly,
> if an admin is
> making consistent deletions and not listening to
> others, they can be
> de'sysoped after a request from other wikipedia
> editors. Just go talk to
> the [[Wikipedia:Arbitration Committee]]. See also
> [[Wikipedia:Administrators#Administrator_abuse]].
>
> Basically this suggestion is truly horrible and I am
> strongly opposed to
> it.
>
> TBSDY
>
> Eric B. and Rakim 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


subject: [WikiEN-l] Drive-by deletion

body:
Yes, it is impossible to keep up unless you make it a
full time job. If I list enough articles for deletion,
then some will get through simply because I am
determined and want to spend more time on VFD than you
are prepared to.
Mark

--- Ray Saintonge <saintonge at telus.net> wrote:

> 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
>
> _______________________________________________
> 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


subject: [WikiEN-l] Re: Drive-by deletion

body:
An article needing improvement is absolutely NOT a
candidate for deletion. If you hate the current
content, improve it, or blank it and make it a stub.
VFD is not the right forum for this.
Mark

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

>
>  >Mark Richards wrote:
>  >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
>
>
> I meant something different. An article (especially
> by an anon) in which
> many linked terms are not yet Wikipedia articles is
> bound to do poorly in
> Vfd and probably get deleted. It has to do with an
> anon's understanding of
> good linking.
> Another good one is where all links are actually
> external links that have
> been made to display as wikilinks (but the colour
> gives them away).
> I believe that there should be an intermediate
> between speedy and Vfd, on
> pages where the only question is whether they should
> be included _in their
> present form_. This process can be reversed if the
> article grows. It also
> means the RC patrol can request inclusion review
> shortly after a page's
> creation.
>
> 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


body:
Yes, be bold, but we are bold in the knowledge that
the history is kept, so others can moderate excessive
boldness. Deletion breaks this, and so boldness should
not be pursued.
Mark

--- Andrew Lih <andrew.lih at gmail.com> wrote:

> On Fri, 22 Oct 2004 05:49:43 +0300, NSK
> <nsk2 at wikinerds.org> 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.
>
> Well my point is that "be bold" should work both
> ways, not just for
> adding things. There should be some boldness in
> expunging things too.
>
> -Andrew (User:Fuzheado)
> _______________________________________________
> 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


subject: [WikiEN-l] Drive-by deletion

body:
To be clear, non-notability is NOT a reason for
deletion that is in any established policy. It is a
term bandied around a lot by a group of people who
would like to be able to delete more material that
they are not interested in.
Mark

--- John Lee <johnleemk at gawab.com> wrote:

> I disagree. The anon should have explained how it
> was relevant already,
> through the entry. If the entry shows no sign of
> notability, it should
> be VfDed.
>
> What frustrates me the most about the current
> process is the lack of an
> intermediary stage between speedy deletes and VfDs.
> We get articles
> which are 100% delete on VfD, so having them there
> is a waste of time,
> processor cycles, whatever. But if we speedy them,
> then anthony and the
> inclusionist gang whine up our asses to restore
> them, as deleting them
> wasn't in line with policy. And I agree. I only
> speedy the real crap,
> the real stuff that is 100% proven unencyclopedic,
> such as entries made
> up of phrases such as "i do pot", "i am in love with
> u", "green cheese",
> obvious user tests, etc. (contrary to what many
> inclusionists have
> claimed, there are *many* articles created everyday
> which are clearly
> unworthy of inclusion)
>
> I believe if we got some intermediary stage of
> deletion up, it would
> solve a lot of our woes regarding this. Basically it
> would be a
> condensed version of VfD - perhaps with a period of
> time lasting only
> two or three days. The moment an article gets a
> single keep vote, it
> goes to VfD. If by the time is up there has not been
> a single keep vote,
> then there's obviously no point in keeping it, is
> there? That way, we
> don't speedy dubious entries, we don't waste time
> and effort keeping
> obvious bunk entries on VfD for a full week, and
> everyone's happy.
>
> John Lee
> ([[User:Johnleemk]])
>
> Mark Richards wrote:
>
> >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
> >_______________________________________________
> >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
>

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo


body:
Exactly.
No one has ever heard of it.
Deletion is much more fun.
Mark

--- NSK <nsk2 at wikinerds.org> wrote:

> 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
> _______________________________________________
> 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: Henry H. Tan-Tenn

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

body:
Magnus Manske ti 2004/10/21 ChS 03:31 sia-kong:

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

I've never tried this: I suppose one could put the value itself in a
template (protected) but leave the page proper open for annotation.


subject: [WikiEN-l] Drive-by deletion

body:
Why do you think this would discourage disruptive
users? Most of the most disruptive users are long time
Wikipedians who have accounts and about whom we know
quite a lot. A huge number of valuable contributions
come from anons browsing, who pick up a typo, or make
a link because it is easy to do it fast. They would
not do so if they had to register.
Mark

--- NSK <nsk2 at wikinerds.org> wrote:

> On Friday 22 October 2004 22:39, Mark Richards
> wrote:
> > Most problematic edits actually come
> > from logged in users.
>
> Probably because the account registration process
> does not require valid email
> addresses and other info.
>
> I think the registration process should be a bit
> more difficult to discourage
> disruptive users.
>
> --
> 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
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com


from_name: Rowan Collins

body:
On 22 Oct 2004 06:50:00 +0200, Erik Moeller <erik_moeller at gmx.de> wrote:
> No, what you have is [[Media:Bla.jpg]], and this becomes
> Media:Bla.jpg after
> replaceInternalLinks, and replaceExternalLinks then doesn't reognize that
> this is already HTML, and HTMLizes it again. It doesn't do this for non-
> shared media links because they are rendered to  bla.jpg">, hence no absolute URL for replaceExternalLinks to grok, but we
> can't do that if the shared directory is under a different URL.

Yes, as soon as I read Will's message, I realised what you were on
about. Apologies for being thick.

> Doing a placeholder substitution as suggested in this thread kinda works,
> but isn't particularly elegant and likely to lead to future similar
> problems. Whatever order we use, the code needs to be changed to
> accommodate for special cases.

Actually, I think the use of placeholders *is* a mechanism for
accomodating special cases: it says "this bit of code is finished
with, please don't do any more parsing on it". It's a bit of an ugly
way of doing it, in that it's probably quite an expensive process, but
with the 'parser' structure as ugly as it is, it seems to deal with
most things pretty well.

The only alternative that comes to mind is to make things like
replaceExternalLinks() more context-aware, so that they automatically
leave alone things that are already HTML attributes or whatever. But
this would make the code more complex, not less, and there'd be
ambiguous situations that just happen to look like HTML fragments, so
I dread to think what form this "context awareness" could reliably
take.

AFAIK, the only thing that currently breaks as a direct result of
placeholder use is the alt/title attributes of images whose captions
contain links - a caption of "foo [[bar]] baz" gives {alt,title}="foo
baz" because the placeholder is simply removed. [This is
http://bugzilla.wikimedia.org/648] But arguably those attributes
should never be copies of the caption anyway (bug 368). I also keep
meaning to find out if there's a way to get the full content of
placeholders 'on demand', in which case we'd be able to solve it that
way.

--
Rowan Collins BSc
[IMSoP]


from_name: sannse

subject: [WikiEN-l] Drive-by deletion

body:
John Lee wrote

 >I believe if we got some intermediary stage of deletion up, it would
solve a lot of our
 >woes regarding this. Basically it would be a condensed version of VfD
- perhaps
 >with a period of time lasting only two or three days. The moment an
article gets a
 >single keep vote, it goes to VfD. If by the time is up there has not
been a single keep
 > vote, then there's obviously no point in keeping it, is there? That
way, we don't speedy
 >dubious entries, we don't waste time and effort keeping obvious bunk
entries on
 >VfD for a full week, and everyone's happy.

This could be a really good idea. But... what's the betting that
someone will make it a policy to vote "keep" to *every* nomination?

Almost certain I would say

--sannse


subject: [WikiEN-l] Drive-by deletion

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

I can't imagine that that would make any difference. People create stuff
without reading the policy now - you can force them to scroll over a
page of policy and click a checkbox at the bottom, but you can't force
them to read it (ever read an EULA when installing software?) and you
certainly can't force them to follow it.

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

..and..

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

These ideas have been suggested before, but are so far out of alignment
with the philosophy that Wikipedia was founded under that they will
never be implemented. A "no anon editing" Wikipedia can only be done as
a fork, I think.

Cheers!
David...

_____________________________________________________________________________________________________
This email and its attachments are for the sole use of the addressee and may contain information which is confidential and/or
legally privileged. This email and its attachments are subject to copyright and should not be partly or wholly reproduced without
the consent of the copyright owner. Any unauthorised use of disclosure of this email or its attachments is prohibited. If you receive
this email in error, please immediately delete it from your system and notify the sender by return email.


subject: [WikiEN-l] Drive-by deletion

body:
No, not at all. There are plenty of articles that are
easy to validate and verify (schools, for example),
that are deleted for 'non-notability'. The two are not
the same in any way.

On another note, 'worth' is a value that we ascribe to
things, not something they have inherently. It depends
greatly on ones point of view whether a perticular
article is 'worthless'.

Mark

--- John Lee <johnleemk at gawab.com> wrote:

> Yeah, whatever. If the entry doesn't provide any way
> to easily validate
> its veracity, it's the same thing. Once again, the
> onus is on the
> contributor, not the hapless other editors who run
> into the article, to
> prove the article's worthiness.
>
> John Lee
> ([[User:Johnleemk]])
>
> Mark Richards wrote:
>
> >To be clear, non-notability is NOT a reason for
> >deletion that is in any established policy. It is a
> >term bandied around a lot by a group of people who
> >would like to be able to delete more material that
> >they are not interested in.
> >Mark
> >
> >--- John Lee <johnleemk at gawab.com> wrote:
> >
> >
> >
> >>I disagree. The anon should have explained how it
> >>was relevant already,
> >>through the entry. If the entry shows no sign of
> >>notability, it should
> >>be VfDed.
> >>
> >><snip>
> >>
> >>John Lee
> >>([[User:Johnleemk]])
> >>
> >>
> _______________________________________________
> 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


subject: [Wikitech-l] Re: Slaves out of sync

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

Ariel has 6x73GB 15K SCA SCSI drives (4 RAID 1+0 (146GB), 2 RAID 1
(72GB)), and is out of drive bays. Disk space is not cheap.

We certainly should write a script to shut down the master database
server safely before it runs out of disk space. Perhaps we should also
submit a feature request to MySQL AB asking them to prevent this situation.

We have used a script to automatically move old binlogs in the past, but
we haven't been using it recently. It takes some amount of effort to set
up and maintain.

-- Tim Starling


from_name: Jens Ropers

subject: [WikiEN-l] Re: Caching issues

body:
Negative, negative.
On my box I saw caching issues persist beyond a purge:
1. - The Main_Page showed something outdated.
2. - I went to
http://en.wikipedia.org/w/wiki.phtml?title=Main_Page&action=history
3. - I then changed things and loaded the purge URL:
http://en.wikipedia.org/w/wiki.phtml?title=Main_Page&action=purge
4. - This displayed the correct content and a URL of
http://en.wikipedia.org/w/wiki.phtml?title=Main_Page in the address
bar.
5. - Now, as soon as I changed from the
http://en.wikipedia.org/w/wiki.phtml?title=Main_Page URL to the
http://en.wikipedia.org/wiki/Main_Page URL, I was back to the bad old
outdated content again.
Optional 6th step: Rinse and repeat from (2) ad infinitum et ad nauseam.

Anyway, the Slaves out of sync thread on Wikitech-l has already cleared
up what's behind these probs (if I'm not mistaken).
See:
http://mail.wikipedia.org/pipermail/wikitech-l/2004-October/025908.html

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

On 22 Oct 2004, at 07:37, csherlock at ljh.com.au wrote:

> 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
>
> All,
>
> I forgot to note: click on edit of the page, then change action=edit
> to action=purge fixes the issue. This, however, is only a workaround.
>
> TBSDY
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] Go

body:
A related issue (apologies if this is also mentioned elsewhere
already; bug 655 is sort of related) is that we have an "advanced
search" feature, but no "advanced search" link to access it with. That
is, if you get a successful results page, you can modify the
tick-boxes for "search in these namespaces" and "show redirects"; but
this is only available *after* you have already performed a search
with [your] default options. Clicking "Go" or "Search" with no query
doesn't lead to the form either, it just gives an error telling you to
"try another query":
http://meta.wikimedia.org/wiki/Special:Search?search=&fulltext=Search

So perhaps, if we're going to redesign that little bit of UI, we
should include a link labelled "advanced search" or somesuch, which
returns a blank form with these options available. And error messages
could be prepended to this form as well.

On Fri, 22 Oct 2004 15:08:30 +0300, NSK <nsk2 at wikinerds.org> wrote:
> On Friday 22 October 2004 07:53, Erik Moeller wrote:
> > proposes an alternative UI modeled somewhat after Everything2. But the two
> > buttons do different things, which are both useful, therefore both should
> > continue to be supported.
>
> I propose to get rid of Go and implement this behaviour:
> 1. User types and clicks Search (the only button)
> 2. Go's code is executed. If it has a result, it brings the article together
> with a link at the top "Show more relevant search results...".
> 3. If Go's code does not find a result, Search code is executed

--
Rowan Collins BSc
[IMSoP]


subject: [WikiEN-l] Drive-by deletion

body:
On 22 Oct 2004, at 12:45, John Lee wrote:

> I believe if we got some intermediary stage of deletion up, it would
> solve a lot of our woes regarding this. Basically it would be a
> condensed version of VfD - perhaps with a period of time lasting only
> two or three days. The moment an article gets a single keep vote, it
> goes to VfD. If by the time is up there has not been a single keep
> vote, then there's obviously no point in keeping it, is there? That
> way, we don't speedy dubious entries, we don't waste time and effort
> keeping obvious bunk entries on VfD for a full week, and everyone's
> happy.
>
> John Lee

If I read you correctly you're proposing that the "middle road"
semi-speedy deletion thing you're proposing there just lists nominated
articles for a time and that no one actually should/need to vote to
delete them there? I.e. delete votes are unnecessary as not-voted-on
articles listed in that place would get deleted automatically and but a
single "keep" vote would cause the case to be moved to VfD proper?

I was initially opposed to yet another tool, but this one could
actually work and take some strain off VfD.
I've even got an idea what to call this thing: [[Wikipedia:Purgatory]].

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


from_name: csherlock at ljh.com.au

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

body:
NSK wrote:
> On Friday 22 October 2004 06:50, Allan Crossman wrote:
>
>>Unfair; sysops who do a lot of speedy deletions are more likely to be
>>awarded "points".
>
>
> And admins who refrain from acting as admins will never collect points, while
> the others who do will inevitably get some of them (humans are error prone).
> In the end, inactive and coward admins will be the only ones who will have an
> excellent point record (i.e. 0). I don't think that inactivity and cowardness
> should be encouraged among the admin population.
>
> But, again, the suggestion isn't bad. Admins who create problems must be
> punished. It just needs to be discussed how the system can encourage admins
> to use their powers for the common good.
>
> Perhaps negative points could be applied to admins who don't help with
> administrivia and those who use their power in an evil or stupid manner.
> Positive points should be given to those who provide exceptional service to
> the community.
>

Speaking as a (new) administrator: these suggestions are quite silly.
Being an admin is a thankless task, and there are already quite harsh
sanctions for admins who act up. I think people need to get some
perspective and realise that bad admins have been weeded out already, or
will be soon. The existing structures are in place, and they are sufficient.

TBSDY


from_name: Rebecca

body:
> But, again, the suggestion isn't bad. Admins who create problems must be
> punished. It just needs to be discussed how the system can encourage admins
> to use their powers for the common good.

I disagree. I'm sorry to sound harsh, but this is a terrible idea.
People need to be encouraged to do quality control, not have an axe
placed over their heads for doing it.

We have existing checks and balances. They're rarely needed. Something
like this would be a nice way of quickly making Wikipedia crash and
burn.

-- ambi


subject: [Wikitech-l] Re: WikiData: A rant

body:
Magnus Manske wrote:
> <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>

My approach would be to not use SQL, or anything similar. Use a custom
syntax with a greatly restricted feature set. Think in terms of
applications. Only allow queries which can be cached and invalidated.
Fetching single rows would be a good place to start, that's all I would
have implemented if I followed my WikiDB idea.

Cache invalidation or purging is the standard solution here. Make a list
of every article which fetches a particular row, and update it on edit.
Then when the row changes, invalidate all the articles in the list. Make
a list of every article which contains a list of species in the Foobus
family. Invalidate all articles in the list every time a species is
added or removed from that family.

It's disappointing to give up on some of the dream, but at some stage of
the development process, you have to be realistic. My advice would be to
set a short term goal (a few months or so), code something useful,
admire your work, then go from there.

-- Tim Starling


body:
OK, I'm topposting and loving it!

Firstly, deleted articles are not permanently deleted. We can retrieve
them. See [[Wikipedia:Undeletion policy]]. Secondly, if an admin is
making consistent deletions and not listening to others, they can be
de'sysoped after a request from other wikipedia editors. Just go talk to
the [[Wikipedia:Arbitration Committee]]. See also
[[Wikipedia:Administrators#Administrator_abuse]].

Basically this suggestion is truly horrible and I am strongly opposed to
it.

TBSDY

Eric B. and Rakim 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/


subject: [WikiEN-l] Drive-by deletion

body:
Yes, there could be a category for this I suppose, but
there is still the issue that 'notablity' is
inherently POV.

Mark

--- NSK <nsk2 at wikinerds.org> wrote:

> On Friday 22 October 2004 23:28, Mark Richards
> wrote:
> > deleted for 'non-notability'.
>
> That's a Bad Thing (tm) IMO. sysops should delete
> only the pages that are
> useless (spam, tests, profanity) not a page which
> contains factual
> information, no matter how notable this info is, as
> long as you categorise
> the pages in categories according to their
> notability so that people can
> limit their search in notable articles only.
>
> --
> 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
> _______________________________________________
> 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: Allan Crossman

subject: [Wikitech-l] We need fast rollback of page moves

body:
Hi - today on "en" some vandalbot did about 30 or 40 page moves in a
minute or two. It's all fixed now, but for the future, it would be good
if sysops could speedily undo page moves.

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


from_name: NSK

subject: [Wikitech-l] Re: Slaves out of sync

references:
<cl9qnu$si8$1@sea.gmane.org>
	<200410220602.21664.nsk2@wikinerds.org>
	<cl9v13$5rn$1@sea.gmane.org>

body:
On Friday 22 October 2004 06:32, Tim Starling wrote:
> Ariel has 6x73GB 15K SCA SCSI drives (4 RAID 1+0 (146GB), 2 RAID 1
> (72GB)), and is out of drive bays. Disk space is not cheap.

Sorry I agree. SCSI disk space and especially disk bays aren't cheap. I
thought you were using SATA.

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