body:
On 11/30/05, Mathias Schindler <mathias.schindler at gmail.com> wrote:
> On 11/30/05, David Gerard <fun at thingy.apana.org.au> wrote:
> >
> > Would it be a good idea to tell our robots.txt not to index talk pages?
>
> Our google sitemap file has given talk pages a far lower priority than
> the actual articles.

Please note that the priority is relative, see the spec.


list: wikien-l

source: pipermail-mbox

from_name: kosebamse at gmx.net

subject: [WikiEN-l] Most read US newpaper blasts Wikipedia

body:
Snowspinner wrote:

>The objection that Seigenthaler is having to Wikipedia is not even to
>the process or to the speed at which we fix vandalism. It is not to
>our current quality, it is not to anything fixable.

It is to some pieces of obvious disinformation if not slander that has been
visible on the Internet. I wonder how many people form their final opinion
on a person or thing based on some piece of disinformation or slander found
on Wikipedia.

>The entire goal of this project is freedom and openness.

The entire goal of this project is to create an encyclopedia. Freedom,
openness, the Wiki thing etc. are means to that end. We are not here to make
political statements, we are here to write the ultimate encyclopedia, and it
is indicative of our confused state of mind that we are so concerned with
quantity of content, processes and (ultimately political) fundamentals
instead of quality of content.
If you want to write encyclopedia, you must attract the best writers and
motivate them. I dare say the present state of our community is not overly
attractive or motivating, because we look like a family that has inherited a
fortune and instead of looking for quality investments sticks it into
make-money-fast schemes. We should get rid of the make-content-fast way of
thinking.

Kosebamse

--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse f?r Mail, Message, More +++


list: foundation-l

from_name: Poe, Marshall

subject: [Foundation-l] Most read US newpaper blasts Wikipedia

body:
 Jean-Baptiste wrote:

>Actually I don't really see the difference with a classical newspaper.
>They can very well damage reputations... and actually they do ! But
just like freedom of
>the press, freedom of speech is more important than individuals and
Laws allow special
>liability regimes for both the press and wikipedia.

It's important to be clear here.  There is no 'special liability regime'
that protects any publisher, editor, or author from charges of
liability.  The doctrine is clear: if you write something or publish
something about someone that is *perceived as libelous* that person can
sue you.  And such suits occur all the time (especially in the UK). God
grant it won't happen to WP, but it is important to consider that it
could (and, in some cases, perhaps should).

There is a more general consideration, tho: repeated notices in the
*trusted* print press to the effect that WP is not trustworthy will
drive people away.  WP's reputation is on the line. So WP has both good
legal and practical reasons to institute some sort of (let me just say
it) formal editorial control over quality.

This, if I understand, is just what is being discussed now.

Best,

Marshall Poe
The Atlantic Monthly
www.memorywiki.org


list: wikimedia-l


list: wikitech-l

from_name: Nikola Smolenski

subject:
[Wikitech-l] Re: [WikiEN-l] Using Talk pages to influence Google
	results (Most read US newpaper blasts Wikipedia)

body:
On Wednesday 30 November 2005 22:47, David Gerard wrote:
> Would it be a good idea to tell our robots.txt not to index talk pages?

I don't think that would be a good idea. Once I had a browser problem for
which I found a solution on no less than a Wiktionary talk page. Maybe links
on talk pages could be neutered with rel=nofollow.


from_name: SJ

body:
On Thu, 1 Dec 2005, Poe, Marshall wrote:

> There is a more general consideration, tho: repeated notices in the
> *trusted* print press to the effect that WP is not trustworthy will
> drive people away.  WP's reputation is on the line. So WP has both good
> legal and practical reasons to institute some sort of (let me just say
> it) formal editorial control over quality.

<cough> It isn't as though everyone is tiptoeing around that phrase.

There are solutions to improving WP's quality - particularly the
quality of content seen by 99% of our readers and all of our serious
mirrors - that are at once more effective and less controversial than
'formal editorial control'.

SJ


list: wikipedia-l

from_name: Phil Boswell

subject: [Wikipedia-l] Re: Upcoming edit page layout changes

body:
"Brion Vibber" <brion at pobox.com> wrote in
message news:438E3D21.8040908 at pobox.com...
[snip]
> This is online to try out on the test wiki at:
> http://test.leuksman.com/edit/Main_Page
> Avar has expressed objection to putting the notice above the buttons, but
> I
> think it really *needs* to be if we want to pretend it means anything. Any
> final
> comments, and preparation for the change (splitting bits out from the
> copyright
> message) would be good to do; I plan to commit this change in the next day
> or two.

This all looks particularly spiffy. I like the new URL-based method of
specifying edit-mode: when did that slip in without my noticing?

I thoroughly agree about making the notices as prominent as possible.

Now I have to remember to ask [[User:Pilaf]] about where his LivePreview
widget sticks the preview: it's currently underneath the list of templates
which is a particular pain when there were loads :-(
--
Phil
[[en:User:Phil Boswell]]


from_name: Andrew Lih

subject: [WikiEN-l] Most read US newspaper blasts Wikipedia

body:
On 11/30/05, Katefan0 <katefan0 at yahoo.com> wrote:
> I hesitated to post this message because I don't want
> to take credit for the idea.  It was actually an idea
> put forth by Johntex, relayed to me after the recent
> meetup he'd gone to.  I'm not sure that he subscribes
> to wikien-l, though, so I thought I'd mention it FWIW.
>  I believe he also relayed the idea to Jimbo so
> perhaps this has already been circulated.
>
> Johntex's idea is essentially a spinoff of an
> "approved" version.  He essentially proposed that
> Wikipedia create an additional "tab" people could
> click on to see the last "approved" version.
> Everybody can still edit the non-approved version,
> just as normal.  And I guess, taking the idea out to
> its logical extreme, at intervals the two versiosn
> would be compared and any new information meshed into
> the "approved" version.  This way everybody can still
> edit and contribute, but anyone concerned about
> ensuring the version they're looking at has been
> vetted thoroughly could simply click on the "approved"
> tab.

Kate, it's very similar to this:

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

And it seems like it's the least disruptive, highest ROI feature that
we could try, and the implementation would be simple.

-Andrew (User:Fuzheado)


from_name: geni

subject: [WikiEN-l] Re: Fwd: Google Alert - Wikipedia

body:
On 12/1/05, Ray Saintonge <saintonge at telus.net> wrote:
> geni wrote:
>
> >On 11/28/05, Matt Brown <morven at gmail.com> wrote
> >
> >>All of this was, in retrospect, a mistake.  But I'm not sure it can be
> >>chalked up to 'eventualism', rather than other causes.
> >>
> >>
> >By the same token imitatism can't be shown to have any downsides
> >either. The problem with eventualism is that in most cases I can show
> >it supports both sides of the debate.
> >
> That sounds like a description of NPOV.
>
> Ec

NPOV should not support either sie of the debate. It should present both sides.

--
geni


body:
On 12/1/05, kosebamse at gmx.net <kosebamse at gmx.net> wrote:
>> The entire goal of this project is to create an encyclopedia. Freedom,
> openness, the Wiki thing etc. are means to that end. We are not here to make
> political statements, we are here to write the ultimate encyclopedia, and it
> is indicative of our confused state of mind that we are so concerned with
> quantity of content, processes and (ultimately political) fundamentals
> instead of quality of content.
> If you want to write encyclopedia, you must attract the best writers and
> motivate them. I dare say the present state of our community is not overly
> attractive or motivating, because we look like a family that has inherited a
> fortune and instead of looking for quality investments sticks it into
> make-money-fast schemes. We should get rid of the make-content-fast way of
> thinking.
>
> Kosebamse

However in order to atchive this you would need to get schoolwatch to
give up and that is really not going to happen.

--
geni


from_name: Thomas Gries

subject:
[Wikitech-l] How to (safely) prune the database: removing oldest
 revision of Article, Talk, User, User_talk pages

body:
Question to the database experts:

- How can the database of MediaWiki 1.5.x safely be pruned
( in order to actually remove the oldest revisions of Article, Talk,
User and User_talk pages ) ?

An older answer given to me begin of 2005 was

   DELETE FROM old WHERE old_timestamp < '20050101000000'; or whatever

Is it safe to use this statement or is another one recommended ?


from_name: Daniel Mayer

subject:
[WikiEN-l] An actual RC patrol? (was Openness is a means to an
	end. Nothing more)

body:
--- David Gerard <dgerard at gmail.com> wrote:
> Would it be an idea to make RC patrol organised, i.e. people (admins
> or not) sign on for shifts, checking all edits in a given block of
> time? Two patrollers for each time period should be enough, three or
> four for evenings US time. You do RC patrol - would something like
> this make sense?

What we need are teams of people working together in a way that minimizes duplicated effort. As
is, there is no way to know if a diff has been looked at once before, never before, or 200 times.
There is also no way to know what was being looked at (simple vandalism, subtle vandalism,
accuracy, etc). Knowing at least the first part (how many times a diff has been looked at) will
help a great deal. Sorting RC based on that would be even better.

Better still would be to sort RC and similar lists based on trust networks. For example, I trust
you and many other people. So edits either made by you and diffs checked by you should be OK in my
eyes. It would be nice if my RC and similar lists de-emphasized your edits and edits checked by
you. This could go one step farther: I trust your ability to judge whether or not other people are
trustworthy. So it would be nice if I could trust by proxy all the users you trust. This creates a
trust network.

This could also be done P2P via an offline editor and thus minimize server load. The offline
editor would do all the sorting after downloading raw data from Wikipedia.

I think it is obvious that we need bigger and better guns to fight vandals.

-- mav

__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/


from_name: Ray Saintonge

subject: [Wikipedia-l] the road to stability -- Yes! we have a winner!

body:
Neil Harris wrote:

> I agree with Kai on this completely; if Wikipedia is about
> optimization by repeated random/evolutionary/whatever change,
> simulated annealing is _the_ classic way to achieve stable results.
>
> Once an article had been progressively and slowly "cooled" to a low
> enough "temperature", it would be effectively frozen. If an article
> was shown to be seriously wrong, or needed extensive revision, it
> could always be "warmed up" again, either partially or all they way.
> The old "cooled" version of the article could be marked in the history
> as the "previous stable version".
>
> In any case, as stable articles cooled down, they would change less
> and less often, making the use of the article rating process (where
> ratings must necessarily refer only to a single version) more and more
> useful.
>
> Question: what would should a good algorithm for "cooling" and
> "heating" pages be based on? Article ratings for the last few
> versions? Consensus in an "articles for cooling" page? Intervention by
> admins?
>
> Perhaps even some simple automatic heuristic like (for example) _very_
> slowly cooling pages that are read repeatedly by a wide range of
> readers over some significant time period and yet not edited (ie,
> implicitly "validated" in a tiny way by those readers) during that
> time? Perhaps articles should slowly "heat up" if not read for some time?

I have suggested a statistically determined measure of an articles net
rating based on a modified average of all recent individual ratings.
The number of individual ratings upon which the value is based would
also be noted.  A low number of individual ratings would suggest an
article in need of attention.  This could be because the subject is so
obscure that nobody ever pays attention to it, or the page has had so
many recent edits that individual ratings have expired.  If we add the
total number of individual ratings to the data it will be obvious which
of the two alternatives applies.

When statistical determinations are made it is important to remember the
tendency of data to normalize itself.  The individual vote becomes less
important in its own right.  The votes of trolls, POV pushers and other
outlaws have a reduced statistical effect on the net result.  I suppose
that techniques could be built in to neutralize the effects of
sockpuppetry if that is really a problem.  Neutralizing the effects of
sockpuppets is much better for the health of the community than
acrimonious search and punish missions.

Ec


from_name: Lars Aronsson

body:
My old friend Delirium wrote:

> I don't see how that differs from UseNet, which has for decades
> allowed anonymous postings, with no editor to stand behind them.
> If you get libeled on usenet, well, that's just too bad, eh?
> Post a rebuttal.

The difference is, of course, that when you and I contribute to
Wikipedia, we have the ambition to create something more lasting,
more reliable than a bunch of Usenet postings.  It is still
unclear exactly what level of reliability we should expect out of
Wikipedia.  It is probably lower than what people used to expect
of printed encyclopedias in previous centuries, but it should be
higher than most arguments thrown around in discussion forums.
On its front page, Wikipedia has the ambition to *be* a free
encyclopedia, and that might set expectations just a little higher
than can be achieved.  To the core community the emphasis is on
"free," but many outside readers seem to focus on "encyclopedia."

This over-expectation is evident from Seigenthaler's piece, where
he writes:

: Wales, in a recent C-Span interview with Brian Lamb, insisted
: that his website is accountable and that his community of
: thousands of volunteer editors (he said he has only one paid
: employee) corrects mistakes within minutes.

I don't know what Jimbo might have said in that interview, but
apparently Seigenthaler took it to be some kind of guarantee that
every mistake will be corrected within minutes.  I doubt that
Jimbo would ever promise anything like that.

> And in this case, I don't see how ethical issues enter into it
> at all.  If the biography is inaccurate, it should be edited,

The ethical part is that Seigenthaler's biography was not only
incorrect but also contained rather serious allegations.  We
should probably be more careful to check facts when a person is
called a criminal.  Many other errors can be less important.

Instead of a general requirement on sourcing every fact, I think
it would make sense to require sources to such allegations.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se


from_name: Rob Lanphier

subject: [Wikitech-l] Possible Wikidata component: JSONwidget

body:
Hi all,

I've been working for the past month on an browser-based editor for
JSON, called JSONwidget.  For those of you unfamiliar with JSON, it's a
data serialization format, which is a fancy way of saying text markup
for structured data.  It's one of two alternatives to XML that is
gaining traction as simpler, more compact formats text formats for data
serialization (the other one being YAML).

Anyway, what my tool does is takes a JSON file and a JSON-formatted
schema, and renders a user interface for editing the JSON, creating
neatly formatted JSON on the client for submission back to the server.

Here are the demos:
http://robla.net/2005/jsonwidget/#demos

Note that this version has only been tested with Firefox 1.0.7.  I plan
to fix many known bugs in IE and Opera in my next release, and would
welcome help from users of other browsers.  There are still plenty of
rough edges even for Firefox users, but there should be enough there to
give you an idea of where its heading.

For those that object to fancy Javascript interfaces on philosophical
grounds, you'll be pleased to know that it does have a failover mode.
If Javascript is turned off, you are presented with a simple web form to
edit the raw JSON.  Not pretty, but functional in a pinch.

I'm not sure if something like this could be adapted for Wikidata; I
haven't had a chance to really dive in and see where that project is at.
But I'm throwing that out there as a possibility.

Let me know what you think.

Thanks
Rob


from_name: Xed Mac

subject: [Wikitech-l] Using mwdumper.jar on OS X

body:
Thanks for your help so far.

OK, I enter this in the terminal:
/usr/local/mysql-standard-5.0.16-osx10.4-powerpc/bin/mysql
-u root -p wikidb

Then I type this (literally) in mysql:
SOURCE
/Users/xed/Sites/mediawiki/maintenance/tables.sql

....i get this:
Query OK, 0 rows affected, 1 warning (0.17 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected (0.04 sec)

Query OK, 0 rows affected, 1 warning (0.03 sec)

Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected, 1 warning (0.06 sec)

Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 0 rows affected, 1 warning (0.03 sec)

Query OK, 0 rows affected, 1 warning (0.02 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected, 1 warning (0.01 sec)

Query OK, 0 rows affected (0.01 sec)

...

Back in the terminal, I wrote:
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java
-jar -Xmx=200m /Users/xed/Desktop/mwdumper.jar
--format=sql:1.5
/Users/xed/Desktop/20051127_pages_articles.xml.bz2 |
/usr/local/mysql-standard-5.0.16-osx10.4-powerpc/bin/mysql
-u wikiuser -p wikidb

I got the error: invalid initial heap size

So I tried this:
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java
-jar -Xmx512m -Xms256m /Users/xed/Desktop/mwdumper.jar
--format=sql:1.5
/Users/xed/Desktop/20051127_pages_articles.xml.bz2 |
/usr/local/mysql-standard-5.0.16-osx10.4-powerpc/bin/mysql
-u wikiuser -p wikidb

...and now it's stepping thru (very slowly):
1,000 pages (91.033/sec), 1,000 revs (91.033/sec)
2,000 pages (98.917/sec), 2,000 revs (98.917/sec)
3,000 pages (101.93/sec), 3,000 revs (101.93/sec)
4,000 pages (92.913/sec), 4,000 revs (92.913/sec)
5,000 pages (89.284/sec), 5,000 revs (89.284/sec)
6,000 pages (84.647/sec), 6,000 revs (84.647/sec)
7,000 pages (80.61/sec), 7,000 revs (80.61/sec)
8,000 pages (80.176/sec), 8,000 revs (80.176/sec)
9,000 pages (78.468/sec), 9,000 revs (78.468/sec)
10,000 pages (78.394/sec), 10,000 revs (78.394/sec)

etc
It's getting slower as it goes on. I guess that's
normal?

What do I do when this process is finished?

Thanks

X

--- Brion Vibber <brion at pobox.com> wrote:

> Xed Mac wrote:
> > How do I use tables.sql? What do I need to type in
> the
> > terminal?
>
> $ mysql -u root -p your_database_name
> mysql> SOURCE
> /path/to/mediawiki-1.5.3/maintenance/tables.sql
>
> -- brion vibber (brion @ pobox.com)
>
> > _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l

___________________________________________________________
Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/


subject: [WikiEN-l] Re: yet another image lost for posterity

body:
On 12/1/05, Ray Saintonge <saintonge at telus.net> wrote:
> That page has been edited nearly 100 times since.  It's tagged as
> official policy, but it's difficult to consider a page as representing
> policy when its text is so unstable. Since checking the background of
> each paragraph in a policy page would be unreasonable everything on the
> page is in doubt.
>
> Ec

No in so far as policy is ment to reflect practice it is broadly correct.

--
geni


from_name: Peter Gervai

subject:
[Wikipedia-l] Fair use in non-English Wikipedias (moved from
	wikien)

body:
On Sun, 27 Nov 2005 17:10:53 -0500
Anthony DiPierro <wikilegal at inbox.org> wrote:

> Again, from a legal standpoint, I don't think it should matter whether
> 99% of editors and readers live in Poland or 5% do.  So if someone
> *could* sue Wikipedia for an image in the Polish Wikipedia, then they
> probably *could* sue Wikipedia for an image in the English Wikipedia.

By the way it's not about just sueing Wikipedia, it is about sueing the
user of the Wikipedia _content_, which is supposed to be free ("libre").

IANAL but European law generally do not allow USA "fair use". We have
kind of similar laws which are much more restrictive, basically resulting
"USA fair use = not usable" [should be examined in every darned case
individually, and usually denied].

Our goal (in national 'pedias) to create a content which is useable by
the native speakers of the given language, and those speakers generally
happen to live outside US jurisdiction. Basically we have to follow US
*and* local law both to be able to say "the content is free".

Peter
(Hungary)

ps: hu.wikipedia basically use the same 'no fair use' policy. I believe
most EU and european countries are supposed to act the same, as we probably
have very similiar laws regarding this case.


subject: [Wikipedia-l] Re: [WikiEN-l] GFDL compatibility of image licenses

body:
On Mon, 28 Nov 2005 10:39:15 -0500
Anthony DiPierro <wikilegal at inbox.org> wrote:

> By the way, this sentence contains at least one common misconception
> about copyleft.  Images only "become GFDL" if they are released by
> their copyright holder under the GFDL.  They don't automatically
> become released under the GFDL.

Problem is that "by uploading this crap you agree to release the given
crap under GFDL"... if there's any, that's it.

g.


from_name: Jonathan Leybovich

subject: [Wikitech-l] Re: Credit card processing

body:
>
> Date: Thu, 01 Dec 2005 12:49:40 +0000
> From: Neil Harris <neil at tonal.clara.co.uk>
> Subject: Re: [Wikitech-l] Re: Credit card processing
> for forthcoming
> To: Wikimedia developers <wikitech-l at wikimedia.org>
> Cc: board at wikimedia.org
>
> I don't think that anyone is advocating dropping
> PayPal or any other
> existing payment option, just adding direct donation
> by credit card as
> another option.

Yes, I see.  In that case here are the major credit
card payment systems which I would recommend the
Foundation contact for information about rates:

Processors:

First Data- http://www.firstdata.com/
Paymentech - http://www.paymentech.com/
Citibank Merchant Services -
http://www.citibank.com/us/cards/merchant/

Gateways-

Concord EFS Net - http://www.concordefsnet.com
Cybersource - http://www.cybersource.com/

Verisign also has a credit card payments division;
however, that was just sold to Ebay, which owns
PayPal, so I'm not sure if they're accepting new
customers.

I think almost all of these payment systems support
international credit card payments, though some may
require having a deposit account either with a
particular bank, or in a particular currency.

Technically, Concord probably has the simplest
integration since their architecture is XML over
HTTP(S)-based.  Integrating with a processor would be
more difficult, but at least it helps that the
Foundation need only implement one type of operation-
auth-capture- since it does not deliver goods to its
payers, which normally requires deferring the actual
transfer of funds (i.e. capture) until the time of
shipment.  Another nice benefit of using only the
auth-capture operation is that the Foundation would
never have to store credit card numbers in a database.

Anyway, I'd be happy to help with more information or
expertise, including with the technical implementation
assuming my employer would not consider that a breach
of contract... :/

__________________________________________
Yahoo! DSL ? Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com


from_name: Brion Vibber

subject: [Wikitech-l] Using mwdumper.jar on OS X

body:
Xed Mac wrote:
> OK, it's just finished:
> 2,136,559 pages (189.635/sec), 2,136,559 revs
> (189.635/sec)
>
> I don't see the pages in my Wiki. Now what?

You tell me! I assume that you:

1) Watched for errors during the import, and logged it all to a file you can now
review.
2) Looked in the database to see what's there

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20051201/29832ee4/attachment.pgp>


from_name: Matt Brown

subject:
[Foundation-l] Requiring a References section (was Re: Enforcing
	WP:CITE)

body:
On 12/1/05, SJ <2.718281828 at gmail.com> wrote:
> 1) Wikipedia is important enough to significantly injure the reputations
> of people/organizations that are known elsewhere on the web. It may
> provide 2 or more of the top 10 search results for content about them.
>     An old problem, but getting worse with increased popularity.  This is
> the most egregious case I have seen.

Perhaps I simply considered this 'old news' more than many.

> 3) This article was linked to from other pages. It was noticed and
> wikified. At this stage, something could have been done about it.
>     If the first page of our style guide included not only "how to bold the
> topic" and "how to link out", but also "how to flag emotional or
> controversial content" and "how to mark short, unsourced articles" -- this
> might have been noticed and fixed during the ensuing three months.

Good point.  Wikification should start including such things, as well
as formatting fixes.

I think it's also the case that we should be especially careful about
unattributed claims about living persons.  It's the topic where
misinformation can be most hurtful.

> Why not?  Requiring a 'references' section for every article (thanking the
> heavens that WP is not paper), and reminding every editor that *every* new
> article should come with at least one reference, seems a responsible thing
> to do.  Can you offer a reason not to have such a section for any article?

I meant that more than that is hard to automate.  You're right that
the bare minimals can be easily checked.  However, I can't see that we
can automate much beyond that with ease.

> If you're writing about one of those topics that is a) not private
> research/analysis of your own, but b) has never been written about
> anywhere else [that you know of], then we need a new class of references :
> "personal observation by [user]", with a relevant tag not unlike the
> original-reporting templates used on Wikinews.  Then it will be crystal
> clear that readers should visit your page, and see whether they trust you
> as the primary/original observer/author.

Much of this falls under 'original research', doesn't it?  Or are you
talking about the cases where someone believes that something is true
but doesn't have the references to hand?

-Matt


from_name: Andrew Venier

body:
Justin Cormack wrote:
> Just queue new articles so they have to go via an admin before
> joining the main namespace (they can sit in New: before that).
>
Just to clarify, are you talking about New Pages or Recent Changes?  (I
think the discussion started as RC, and moved to NP).

The practical problem I see with this scheme (which is worse for RC) is
that any edits started between one user's submission and admin approval
will amount to edit conflicts.

There are a number of ways such conflicts could be managed, but then the
system stops being so simple.


from_name: Alex Schenck

subject: [WikiEN-l] A bold fix needed to the "omg backlog" problem

body:
I will copy what I wrote to David here...

That's right!

I want to ask for your opinion here. I was feeling brave this morning and
decided to see if I could make a dent in Category:Wikipedia
backlog<http://en.wikipedia.org/wiki/Category:Wikipedia_backlog>.
After looking at about 25 articles with the wikification tag attached to
them, and being so disgusted with the lot as to be unable to make a *single*
change, something major hit me.

We need to, as one might say, flush the crap down the toilet. Allow me to
explain.

A LOT of the articles in Category:Articles that need to be
wikified<http://en.wikipedia.org/wiki/Category:Articles_that_need_to_be_wikified>are
so poorly written and so obscure that they have
*no possible use, worth or value to anyone!* Jimbo himself made it clear in
that interview that although Wikipedia does have some gems of articles (ie
our Featured Articles), there is a rather poor signal to noise ratio. We all
know that backlogs need to be cleared out, but no one is going to be able to
do it without a.) time that reaches beyond time itself, b.) unlimited
patience and c.) endless knowledge. In other words, to clear out the
backlogs would be akin to an act of God.

I know you know what I'm thinking, David. I want to nuke a ton of articles
in the backlog. Things like
this<http://en.wikipedia.org/wiki/Help_the_Aged>may have a place on
Wikipedia, but *not* in their current form. If these
things are important enough, they can be tagged as such and someone can be
given it to work with. But I want to delete a lot of articles.

I know I'm going to get a lot of flak from other users concerning this. They
will kneejerk to "OMG ABUSIVE ADMIN LALALALLA" and "DELETIONIST! OMG
DELETIONIST!". But, we *need* to do something about the absolutely wretched
backlogs.

Get back to me on this. Thanks. Alex
Schenck<http://en.wikipedia.org/wiki/User:Linuxbeak>(that's
Linuxbeak <http://en.wikipedia.org/wiki/User_talk:Linuxbeak> to you) 16:40,
1 December 2005 (UTC)

Now, with that said, I need feedback. Please provide.

--Linuxbeak


subject: [Wikitech-l] Using mwdumper.jar on OS X

body:
It's up to 1,200,000 in it's count now:
1,200,000 pages (118.572/sec), 1,200,000 revs
(118.572/sec)

I thought there were less than 1,000,000 articles...
What's up with that?

X

--- Xed Mac <xed2507 at yahoo.co.uk> wrote:

> Thanks for your help so far.
>
> OK, I enter this in the terminal:
>
/usr/local/mysql-standard-5.0.16-osx10.4-powerpc/bin/mysql
> -u root -p wikidb
>
> Then I type this (literally) in mysql:
> SOURCE
> /Users/xed/Sites/mediawiki/maintenance/tables.sql
>
> ....i get this:
> Query OK, 0 rows affected, 1 warning (0.17 sec)
>
> Query OK, 0 rows affected, 1 warning (0.00 sec)
>
> Query OK, 0 rows affected (0.04 sec)
>
> Query OK, 0 rows affected, 1 warning (0.03 sec)
>
> Query OK, 0 rows affected, 1 warning (0.01 sec)
>
> Query OK, 0 rows affected, 1 warning (0.00 sec)
>
> Query OK, 0 rows affected, 1 warning (0.01 sec)
>
> Query OK, 0 rows affected, 1 warning (0.01 sec)
>
> Query OK, 0 rows affected, 1 warning (0.01 sec)
>
> Query OK, 0 rows affected, 1 warning (0.00 sec)
>
> Query OK, 0 rows affected, 1 warning (0.01 sec)
>
> Query OK, 0 rows affected, 1 warning (0.00 sec)
>
> Query OK, 0 rows affected, 1 warning (0.06 sec)
>
> Query OK, 0 rows affected, 1 warning (0.01 sec)
>
> Query OK, 0 rows affected, 1 warning (0.03 sec)
>
> Query OK, 0 rows affected, 1 warning (0.02 sec)
>
> Query OK, 0 rows affected, 1 warning (0.00 sec)
>
> Query OK, 0 rows affected, 1 warning (0.01 sec)
>
> Query OK, 0 rows affected, 1 warning (0.00 sec)
>
> Query OK, 0 rows affected, 1 warning (0.01 sec)
>
> Query OK, 0 rows affected, 1 warning (0.00 sec)
>
> Query OK, 0 rows affected, 1 warning (0.00 sec)
>
> Query OK, 0 rows affected, 1 warning (0.00 sec)
>
> Query OK, 0 rows affected, 1 warning (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> ...
>
> Back in the terminal, I wrote:
>
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java
> -jar -Xmx=200m /Users/xed/Desktop/mwdumper.jar
> --format=sql:1.5
> /Users/xed/Desktop/20051127_pages_articles.xml.bz2 |
>
/usr/local/mysql-standard-5.0.16-osx10.4-powerpc/bin/mysql
> -u wikiuser -p wikidb
>
> I got the error: invalid initial heap size
>
> So I tried this:
>
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java
> -jar -Xmx512m -Xms256m
> /Users/xed/Desktop/mwdumper.jar
> --format=sql:1.5
> /Users/xed/Desktop/20051127_pages_articles.xml.bz2 |
>
/usr/local/mysql-standard-5.0.16-osx10.4-powerpc/bin/mysql
> -u wikiuser -p wikidb
>
> ...and now it's stepping thru (very slowly):
> 1,000 pages (91.033/sec), 1,000 revs (91.033/sec)
> 2,000 pages (98.917/sec), 2,000 revs (98.917/sec)
> 3,000 pages (101.93/sec), 3,000 revs (101.93/sec)
> 4,000 pages (92.913/sec), 4,000 revs (92.913/sec)
> 5,000 pages (89.284/sec), 5,000 revs (89.284/sec)
> 6,000 pages (84.647/sec), 6,000 revs (84.647/sec)
> 7,000 pages (80.61/sec), 7,000 revs (80.61/sec)
> 8,000 pages (80.176/sec), 8,000 revs (80.176/sec)
> 9,000 pages (78.468/sec), 9,000 revs (78.468/sec)
> 10,000 pages (78.394/sec), 10,000 revs (78.394/sec)
>
> etc
> It's getting slower as it goes on. I guess that's
> normal?
>
> What do I do when this process is finished?
>
> Thanks
>
> X
>
>
>
> --- Brion Vibber <brion at pobox.com> wrote:
>
> > Xed Mac wrote:
> > > How do I use tables.sql? What do I need to type
> in
> > the
> > > terminal?
> >
> > $ mysql -u root -p your_database_name
> > mysql> SOURCE
> > /path/to/mediawiki-1.5.3/maintenance/tables.sql
> >
> > -- brion vibber (brion @ pobox.com)
> >
> > > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> >
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>
>
>
___________________________________________________________
>
> Yahoo! Model Search 2005 - Find the next catwalk
> superstars -
> http://uk.news.yahoo.com/hot/model-search/
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>

___________________________________________________________
WIN ONE OF THREE YAHOO! VESPAS - Enter now! - http://uk.cars.yahoo.com/features/competitions/vespa.html


body:
On 12/1/05, geni <geniice at gmail.com> wrote:
> Someone has taken to emailing with random headers attacking my
> spelling and me. You may rememer them they surfaced on this list
> trying to inforce a slightly odd version of english grammer. I'm
> waiting to see how long it takes for them to explode.

Thanks for the amusing mental picture.  I'm sure they are having a fit.

-Matt


from_name: Neil Harris

subject: [Wikitech-l] Re: Credit card processing for forthcoming

body:
Jonathan Leybovich wrote:
>> I am confused, though, as to why PayPal is not a
>> viable option.  Every payment system imposes some sort
>> of per-transaction fee, and the 3% transaction amount
>> charge reflects not another part of PayPal's cut, but
>> simply the fact that the merchant receives money from
>> the card holder's bank immediately while the card
>> holder is given a 20-30 day grace period before
>> interest accrues on their new balance.  Thus switching
>> from PayPal may not necessarily save much on costs.
I don't think that anyone is advocating dropping PayPal or any other
existing payment option, just adding direct donation by credit card as
another option.

At the moment, the options available are PayPal or Moneybookers, either
of which is quick and easy if you already have an account.

However, if they don't have an account with either, a potential donor
will have to:
* go to one of them to start an account
* find out how they work
* decide to trust them with your credit card details
* set up a new account, including filling in captchas, E-mail addresses,
other personal details, inventing __and remembering__ yet another strong
password, reading and agreeing to their contract terms and conditions
* entering your credit card details
* then going through the process of donating to Wikipedia with their
newly set up account

Compare this with a direct credit card donation, where a donor will need to
* decide to trust the Wikipedia Foundation with their credit card details
* entering them and the amount of their donation into the donation form,
and then clicking "OK"

Since donations are mostly an "impulse buy", I would imagine that a
great many potential donors just give up at the first stage of setting
up a new money transfer account.

Thus, direct donations should, if I'm right, significantly increase the
rate of donations by allowing people who simply would not have donated
at all to give money without going to undue effort.

If the CC processor's rates are _significantly_ higher than the
alternative, we can simply add a notice suggesting that people who
already have an account with these prefer using them to a direct
donation. If they are not significantly higher, the message can simply
be left out; anything which requires effort or thought from potential
donors is simply a barrier to donation, and will cause some small
fraction of potential donors not to bother. In any case, I would imagine
that people with these accounts would prefer to use them anyway, since
they require entering fewer details.

At the moment, I would imagine that even a gateway processing
arrangement would be quite effective, since it is intended only to catch
people who otherwise would not donate at all. In the longer term, if the
uptake from CC payments is significant enough, and if a cost/benefit
analysis justifies it, moving to a direct processing arrangement would
be worth considering in the long run.

Here's a specific worked example:

* Merchant Express (www.merchantexpress.com) quote a rate of 2.33% plus
25 cents, with a monthly subscription fee of $9.95
* assuming a typical donation of $10, that means they take an effective 4.8%

My best guess is that offering CC processing will increase the level of
donations by 15 - 20%.

if only a conservatively estimated 10% more people donate because of the
CC option, increasing a base of $250,000 to $275,000, the net gain per
three-monthly fundraiser would be

95.2% * $25,000 - ($9.95*3) = $23,770

or about ten servers.

Even if CC payment cannibalizes all of the cheaper payment methods, but
still increases donations by 10%, it would still result in a significant
net gain per fundraiser:

95.2% * $275000 - 97% * $250000 = $19,300.

and in the utterly worst case, where CC payment cannibalizes all cheaper
payment methods, and there is no gain at all in donations, the CC
payment option can simply be removed from the donations page at the end
of day one, limiting the worst-case risk for this experiment to (given a
generous estimated $20,000 of donations made on day one)

1.8% * $20,000 + 12 * $9.95 = $479.

...and I'm sure that with an effective monthly average expected take of
$83,333 (on the basis of four $250,000 fundraisers a year) the Wikimedia
Foundation could find/negotiate far better rates than these published
entry-level rates (which were simply the first ones I found via the top
Google hit for "credit card processing").

-- Neil


from_name: Matthew R. Howard, Sr.

body:
Daniel Mayer wrote:
{snip}

>What we need are teams of people working together in a way that minimizes duplicated effort. As
>is, there is no way to know if a diff has been looked at once before, never before, or 200 times.
>There is also no way to know what was being looked at (simple vandalism, subtle vandalism,
>accuracy, etc). Knowing at least the first part (how many times a diff has been looked at) will
>help a great deal. Sorting RC based on that would be even better.
>
>Better still would be to sort RC and similar lists based on trust networks. For example, I trust
>you and many other people. So edits either made by you and diffs checked by you should be OK in my
>eyes. It would be nice if my RC and similar lists de-emphasized your edits and edits checked by
>you. This could go one step farther: I trust your ability to judge whether or not other people are
>trustworthy. So it would be nice if I could trust by proxy all the users you trust. This creates a
>trust network.
>
>This could also be done P2P via an offline editor and thus minimize server load. The offline
>editor would do all the sorting after downloading raw data from Wikipedia.
>
>I think it is obvious that we need bigger and better guns to fight vandals.
>
>-- mav
>
>
>
{snip}
Something like that would be great! For every vandalism that gets
reverted, I can almost gaurantee 3 or 4 of us checked, and tried to
rollback. I'd also love to have more active admins in the
#wikipedia-en-vandalism channel (at least today I would have) The last
few days, it's been getting crazy. Lotta serial vandals.... IMHO, almost
anything that could reduce the duplication in effort would be great.
Maybe changing the bot, so that... a user could 'check in' with the bot,
and it would rotate vandal warnings to the users that are 'checked in',
via privmsg, and the users could in turn, respond to the bot {notvandal,
vandal, warnvandal1(2,3,4,5), etc} another nice function to this 'dream
bot', would be for it to notify admins of users as they pass thier 4th
or 5th warning that week/day/hour/whatever.... (on the same rotating
scheme, as to prevent duplication of effort there, too)... I've been
debating on writing such a bot in PHP:PEAR/SmartIRC, but work keeps
getting in the way... Anyhow just my thoughts on the subject, as a
relatively new vandal whacker

[[User:Vilerage]]


body:
geni wrote:

>On 12/1/05, Justin Cormack <justin at specialbusservice.com> wrote:
>
>
>>The suggestion was to have a constant patrol, and process everything
>>very quickly. If you want to do this it should be enforced.
>>
>>Any mechanism where things have to go through some form of category
>>change say is better than just hoping things dont get missed, and lets
>>you avoid the situation of not knowing what someone else has reviewed.
>>
>>Doesnt have to be done by admins, although vandals might work it out
>>pretty quickly if they could sign off their own new articles.
>>
>>
>
>We tried this. We switched it off. Pretty much all new articles are
>cheacked. With edit rates of at least once a second there is no way we
>can chech every edit.
>
>
>--
>geni
>
>
>
>
Ya, your best bet is going to be some sort of heurustical (sp?) or other
automated content-analysis and flagging system....


subject: [Wikitech-l] Using mwdumper.jar on OS X

body:
OK, it's just finished:
2,136,559 pages (189.635/sec), 2,136,559 revs
(189.635/sec)

I don't see the pages in my Wiki. Now what?

X

--- Xed Mac <xed2507 at yahoo.co.uk> wrote:

> It's up to 1,200,000 in it's count now:
> 1,200,000 pages (118.572/sec), 1,200,000 revs
> (118.572/sec)
>
> I thought there were less than 1,000,000 articles...
> What's up with that?
>
> X
>
> --- Xed Mac <xed2507 at yahoo.co.uk> wrote:
>
> > Thanks for your help so far.
> >
> > OK, I enter this in the terminal:
> >
>
/usr/local/mysql-standard-5.0.16-osx10.4-powerpc/bin/mysql
> > -u root -p wikidb
> >
> > Then I type this (literally) in mysql:
> > SOURCE
> > /Users/xed/Sites/mediawiki/maintenance/tables.sql
> >
> > ....i get this:
> > Query OK, 0 rows affected, 1 warning (0.17 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.00 sec)
> >
> > Query OK, 0 rows affected (0.04 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.03 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.01 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.00 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.01 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.01 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.01 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.00 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.01 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.00 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.06 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.01 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.03 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.02 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.00 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.01 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.00 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.01 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.00 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.00 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.00 sec)
> >
> > Query OK, 0 rows affected, 1 warning (0.01 sec)
> >
> > Query OK, 0 rows affected (0.01 sec)
> >
> > ...
> >
> > Back in the terminal, I wrote:
> >
>
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java
> > -jar -Xmx=200m /Users/xed/Desktop/mwdumper.jar
> > --format=sql:1.5
> > /Users/xed/Desktop/20051127_pages_articles.xml.bz2
> |
> >
>
/usr/local/mysql-standard-5.0.16-osx10.4-powerpc/bin/mysql
> > -u wikiuser -p wikidb
> >
> > I got the error: invalid initial heap size
> >
> > So I tried this:
> >
>
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java
> > -jar -Xmx512m -Xms256m
> > /Users/xed/Desktop/mwdumper.jar
> > --format=sql:1.5
> > /Users/xed/Desktop/20051127_pages_articles.xml.bz2
> |
> >
>
/usr/local/mysql-standard-5.0.16-osx10.4-powerpc/bin/mysql
> > -u wikiuser -p wikidb
> >
> > ...and now it's stepping thru (very slowly):
> > 1,000 pages (91.033/sec), 1,000 revs (91.033/sec)
> > 2,000 pages (98.917/sec), 2,000 revs (98.917/sec)
> > 3,000 pages (101.93/sec), 3,000 revs (101.93/sec)
> > 4,000 pages (92.913/sec), 4,000 revs (92.913/sec)
> > 5,000 pages (89.284/sec), 5,000 revs (89.284/sec)
> > 6,000 pages (84.647/sec), 6,000 revs (84.647/sec)
> > 7,000 pages (80.61/sec), 7,000 revs (80.61/sec)
> > 8,000 pages (80.176/sec), 8,000 revs (80.176/sec)
> > 9,000 pages (78.468/sec), 9,000 revs (78.468/sec)
> > 10,000 pages (78.394/sec), 10,000 revs
> (78.394/sec)
> >
> > etc
> > It's getting slower as it goes on. I guess that's
> > normal?
> >
> > What do I do when this process is finished?
> >
> > Thanks
> >
> > X
> >
> >
> >
> > --- Brion Vibber <brion at pobox.com> wrote:
> >
> > > Xed Mac wrote:
> > > > How do I use tables.sql? What do I need to
> type
> > in
> > > the
> > > > terminal?
> > >
> > > $ mysql -u root -p your_database_name
> > > mysql> SOURCE
> > > /path/to/mediawiki-1.5.3/maintenance/tables.sql
> > >
> > > -- brion vibber (brion @ pobox.com)
> > >
> > > >
> _______________________________________________
> > > Wikitech-l mailing list
> > > Wikitech-l at wikimedia.org
> > >
> >
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
> >
> >
> >
> >
>
___________________________________________________________
> >
> > Yahoo! Model Search 2005 - Find the next catwalk
> > superstars -
> > http://uk.news.yahoo.com/hot/model-search/
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> >
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
>
>
___________________________________________________________
>
> WIN ONE OF THREE YAHOO! VESPAS - Enter now! -
>
http://uk.cars.yahoo.com/features/competitions/vespa.html
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>

___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com


from_name: Walter van Kalken

subject: [Foundation-l] Enforcing WP:CITE - reacting and overreacting

body:
daniwo59 at aol.com wrote:

>
>In a message dated 11/30/2005 7:09:03 PM Eastern Standard Time,
>chris at starglade.org writes:
>
>I wasn't  talking about the article in question, I was talking in general
>about the  kinds of pages on my watchlist where this happens (which are
>mainly  politics/philosophy-related). Sorry for the  misunderstanding.
>
>Chris
>
>
>I still contend that we should not just be randomly removing material that
>isnt sourced. We should not be working on the assumption that the material is
>inaccurate. Rather than removing material, ask for sources or find people to
>help source it. I want us to start with the assumption that the material is
>good, unless proven otherwise, not that it is bad, unless proven good. Just
>removing people's good-faith edits is not improving wikipedia either.
>
>Danny
>
That was precisely what I tried to point out with my soi example.

Walter/Waerth


from_name: Anthere

body:
Ray Saintonge wrote:
> Anthere wrote:

> You forgot to mention your sense of humour, which is always a useful
> suppository when dealing with anal people.
>
> Ec (who joined in the same month)

Cough....

:-)


from_name: poore5 at adelphia.net

subject: [WikiEN-l] David Hager is listed as convicted rapist

body:
Hello,

Advice please.

During a bout of Insomnia-Induced Insanity, I did a major expansion of the article about David Hager. Hager is the controversial fellow that Bush appointed to the FDA committee on Reproductive Health Drugs. (Self-disclosure: We both live in central Kentucky and our paths crossed through our professions from mid 80's - mid 90's.) Being a controversial figure, I was prepared to deal with POV crap. However, I never thought anyone would put him on a list of convicted rapists. Of course, I immediately took his name off the list. He was on the list for less than five hours, from Dec. 1 00:58 to 05:19. This brings up several issues.

1. Was this information spread to other web sites like Answers.com? Who do I ask to find out?

2. Do we all agree that this is a BIG problem. Can you imagine what would happen if another major media source published Hager?s name on a list of convicted rapists?

2. How do I (hopefully, we) stop this unregistered user (or any other) from doing this again? Being very, very generous, I will assume this was an isolated incidence of poor judgment. This doesn't change the fact that this libelous misinformation appeared in OUR encyclopedia.

 3. I can?t unring this bell. The Wikipedia article is listed 6 in an Yahoo search of the words David Hager. Being a registered user, I will be associated with this article forever. While, an unregistered user can damage Wikipedia, Hager, and me.

Immediate solution? Ask everyone here to put his name on your watch list.
Long term solution???.

SP AKA FloNight


from_name: Travis Derouin

subject: [Wikitech-l] Squid caching issue

body:
Hi,

We recently added a Squid cache for our wiki, for the most part it's
working out quite well.

Although, it doesn't look like popular articles are being cached
properly. I've followed the steps listed here:
http://meta.wikimedia.org/wiki/Squid_caching, the only change being is
that we have a redirect script set up to redirect hostnames, described
here http://wiki.ehow.com/Implement-Redirects-in-Squid, although
removing this doesn't seem to help the cause.

What we are seeing is that Squid isn't caching articles, but keeps on
requesting the same article from Apache.  It does look like the
headers are being set from Mediawiki:

HTTP/1.1 200 OK
Date: Thu, 01 Dec 2005 19:31:03 GMT
Server: Apache/2.0.46 (Red Hat)
X-Powered-By: PHP/4.3.10
Content-language: en
Vary: Accept-Encoding,Cookie
Cache-Control: s-maxage=18000, must-revalidate, max-age=0
Last-modified: Thu, 24 Nov 2005 18:32:18 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

But by tailing the logs and looking at how many times a popular page
has been requested today, Apache is returning 200 codes for the same
page just as many times as it is being requested from Squid, so Squid
isn't serving any cached versions of the page.

If the page hasn't changed, shouldn't it  be returning a 304 header
response saying it hasn't been changed if Squid was working properly?
Should the Expires header be set as well?

Any ideas on how this can be fixed, or how to find out what's going on?

Thanks,
Travis


from_name: Ryan Lane

subject:
[Wikitech-l] Re: How to (safely) prune the database: removing
	oldest revision of Article, Talk, User, User_talk pages

body:
Thomas Gries <mail at ...> writes:

>
> Question to the database experts:
>
> - How can the database of MediaWiki 1.5.x safely be pruned
> ( in order to actually remove the oldest revisions of Article, Talk,
> User and User_talk pages ) ?
>
> An older answer given to me begin of 2005 was
>
>    DELETE FROM old WHERE old_timestamp < '20050101000000'; or whatever
>
> Is it safe to use this statement or is another one recommended ?
>

If you find a good way of doing this (possibly Brion's suggestion), can you add
a page on meta with simple instructions? I'm sure other people (me especially)
would like a safe way of doing this.

Ryan Lane


from_name: Brian

subject:
[Wikitech-l] Re: [Foundation-l] Hosting scans of the 1911
	Britannica on Wikimedia

body:
You select one of the name ranges, and then it will list all the pages
for that range. You then select one of those pages to get the actual
image for that page.

Anthony DiPierro wrote:

>Hmm, I tried that out and all I got was a list of name ranges.  Must
>be doing something wrong.  I'll try it again when I get home from
>work.
>
>Thanks for the info.
>
>Anthony
>
>On 12/1/05, Brian <brian0918 at gmail.com> wrote:
>
>
>>Tim Starling has a demo of it at the link below. I don't know if he's still
>>doing anything with it though. You might ask on wikitech-l.
>>
>>http://en.wikisource.org/wiki/User:Tim_Starling
>>
>>
>>
>>Anthony DiPierro wrote:
>>Whatever happened to this? Are they being hosted anywhere yet? I'd
>>
>>
>really
>
>
>>like to get my hands on a copy of this data.
>>
>>
>
>Anthony
>
>On 11/8/05, Brian
>
>
>><brian0918 at gmail.com> wrote:
>>
>>
>
>
>
>>For those who don't know, the 1911 Encyclopaedia Britannica is a
>>famous
>>
>>
>public domain encyclopedia, advertised as the "sum of all
>
>
>>human
>>
>>
>knowledge" in 1911.
>
>I recently (today) acquired a DVD containing
>
>
>>scans of every page of the
>>
>>
>1911 Britannica, along with index files for it
>
>
>>all, organized by letter
>>
>>
>and page number. I've already talked with avar,
>
>
>>TimStarling, and brion
>>
>>
>on IRC, and TimStarling specifically asked me to tell
>
>
>>you all that he is
>>
>>
>"confident that the server requirements will be minimal."
>
>
>>They would set
>>
>>
>up a domain name, generate some web pages automatically using
>
>
>>the index
>>
>>
>files, and host the entire set of 29,700 files totaling about 4
>
>
>>GB.
>>
>>
>
>One more thing, these are black and white TIFs, and there is
>
>
>>discussion
>>
>>
>about whether they should be mass converted to PNGs to be easily
>
>
>>viewable.
>>
>>
>
>brian0918 at gmail.com
>_______________________________________________
>foundation-l
>
>
>>mailing
>>list
>>
>>
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>
>
>>
>>
>
>
>


body:
On Thu, 2005-12-01 at 19:18 +0100, Erik Moeller wrote:
> This is interesting. Based on my own experience, I can tell you that
> cross-browser compatibility is going to be a PITA.

Oh, I know.  ;-)  I actually got things working well in IE midway
through developing this, which practically involved a rewrite.  The IE
bits tend to regress because keeping it working involves dealing with my
wife's Windows box.  That said, I think the scope of bugfixes needed to
get things working well are small.

>  For Wikidata and
> Ultimate Wiktionary, I'm considering using this library:
>
> http://ianbicking.org/examples/repeat_form/form.html

Cool, thanks for the pointer.  At first, I was really excited, because I
thought that it was doing a bunch of really complimentary things like
dealing with the extra WHAT-WG datatypes (e.g. <input type="date">), but
it looks like he's just started with the repeat part.  That said, it
looks like a really small amount of code, which is nice.

> It's built on top of Mochikit, a fairly powerful JavaScript library.

I'd looked at Mochikit briefly while I was developing this, but was
running into performance issues that a library might exacerbate.  I was
using Behaviour.js at first, and found I got a big performance boost by
writing custom code rather than using Behaviour the way that I was.  The
good thing about using Behaviour was that it made me think about cleaner
approaches to attaching events to controls.

That said, I might be able to get some cross-browser and code clarity
benefits by using Mochikit, so I may revisit that decision.

> When dealing with complex forms on top of a relational database (which
> is essentially what Wikidata is going to be, plus versioning and other
> wiki-ness), safe failover is really hard to achieve. Essentially, one
> has to accept that applications of a certain complexity, especially
> dealing with data entry, require certain capabilities on the client end.

Yup.  Even for something as simple and specific as what I wanted to do
(configure an election with an arbitrary number of candidates) I ran
into problems with plain ol' HTML forms.

> The above forms are one example - where, with JavaScript, you can easily
> create complex relationships between different elements, without
> JavaScript, you would have submit the same form 10 or 20 times, use
> kludges like a fixed number of empty fields, etc. That doesn't even
> touch upon AJAX stuff like autocompletion, which is hard to do without
> in some contexts. So when it comes to building Wikidata UIs, I think it
> makes sense to apply the [[Pareto principle]].

Here's a way I think something like this could work with Wikidata.
Right now, JSONwidget is doing all of the heavy lifting on the client,
and doing it with two JSON-formatted components:

*  The data
*  The schema describing the data format

My next step for JSONwidget is to add another piece, which is somewhat
analogous to a style sheet.  Currently with JSONwidget, the relationship
between the datatype (e.g. string, int, bool) and the input control is a
hard-coded, one-to-one relationship.  My thought is to add a way of
custom binding of nodes of the tree (even whole subtrees) to new
controls.  This could be on a per schema node (by identifier/tree
location) or per datatype basis.

This same approach could be taken on the back end as well, where nodes
in the schema get mapped to fields in the database.  A default mapping
could map this to a generalized but possibly suboptimal table layout.
An administrator could then lock down a particularly popular schema, add
a custom table, index the hell out of that table, and convert the
existing data into the new database binding.

Anyway, food for thought.

Rob


body:
Yeah, it appears to be broken now.

Anthony DiPierro wrote:

>Hmm...
>
>I go to http://en.wikisource.org/wiki/User:Tim_Starling/ScanSet_TIFF_demo
>
>That gives me the list of ranges.  I click on "ANDROS-AUSTRIA" (number 2).
>
>That takes me to
>http://en.wikisource.org/w/index.php?title=User:Tim_Starling/ScanSet_TIFF_demo&vol=02
>
>But that page is the same as the previous page (the same identical
>ranges).  Are you getting the same results?  If so, maybe the script
>is just broken.
>
>On 12/1/05, Brian <brian0918 at gmail.com> wrote:
>
>
>>You select one of the name ranges, and then it will list all the pages for
>>that range. You then select one of those pages to get the actual image for
>>that page.
>>
>>
>>Anthony DiPierro wrote:
>>Hmm, I tried that out and all I got was a list of name ranges. Must
>>
>>
>be doing
>
>
>>something wrong. I'll try it again when I get home from
>>
>>
>work.
>
>Thanks for
>
>
>>the info.
>>
>>
>
>Anthony
>
>On 12/1/05, Brian <brian0918 at gmail.com> wrote:
>
>
>
>>Tim Starling has a demo of it at the link below. I don't know if he's
>>still
>>
>>
>doing anything with it though. You might ask on
>
>
>>wikitech-l.
>>
>>
>
>http://en.wikisource.org/wiki/User:Tim_Starling
>
>
>


from_name: Ray Saintonge

subject: [Foundation-l] Enforcing WP:CITE

body:
Brian wrote:

> Matt Brown wrote:
>
>> I think there is a good deal of un-necessary panic going around about
>> this USA Today thing.  Did it really tell us anything new?  No.
>> Misinformation in rarely visited articles has ALWAYS been a problem.
>
> Yes, but it doesn't mean that we shouldn't do anything about it. We
> know about it, now let's fix it.

Fixing it is not the same as burying it.

>> Let's not run around like headless chickens because some journalist
>> found that conspiracy-theorist things had been put into his Wikipedia
>> article.
>
> That journalist writes for the most read paper in the US. He tells
> everyone that Wikipedia is useless. People read that and believe that
> Wikipedia is useless. This is a fact that we have to face, not ignore
> out of pride.

He's not the first one to say that Wikipedia is "useless", and I'm sure
he won't be the last.  If the critic makes specific observations enough
will notice to do something about those points.  We will never silence
the ones who just make general comments no matter how good we get.  As
long as we threaten to undermine their vested interests they will
continue the criticism.

>> Fact is: Wikipedia's improving.  At quite a tremendous rate, in fact.
>> It's easy to forget (a) the magnitude of the task, and (b) how bad we
>> were even a year ago.
>
> We can easily get to a point in time when we will be overwhelmed by
> the number of editors and new content, and are wishing that we had
> taken some sort of measures early on, rather than sit back and boast
> about improvements.

So who's sitting back and boasting?  Those improvements have happened.
Accepting that does not mean that everybody stops making improvements.
Editors just need to stick to what they're good at instead of worrying
about what they feel others are not doing.

Ec


subject: [Foundation-l] Enforcing WP:CITE


from_name: David Gerard

subject: [WikiEN-l] In those times of ... well, doubt.

body:
Delphine wrote:

>You All at Wikipedia kick some serious ASS!!  I was trying to figure
>out how to site
>a page from your website, when low and behold I found that you not
>only had citation
>information, but you also already had the MLA format ready to go.
>I just wanted to say thank you for making my citation soooo easy!!

I'd suggest we add a "Cite this version" link to the skins, but that
might look like we're positioning ourselves as better than we are ;-)

- d.


from_name: geni

subject: [WikiEN-l] Openness is a means to an end. Nothing more

body:
On 12/1/05, Daniel Mayer <maveric149 at yahoo.com> wrote:
> (better RC patrol features, trust networks to filter RC and watchlists,
> article validation, etc).

RC patrol is reaching it's pratical limit. I'm seeing more vandalism
on my watchlist and no matter how good the people doing it there is
simply no way for them to know if a large percentage of it is true or
not

--
geni


body:
On 12/1/05, David Gerard <dgerard at gmail.com> wrote:
> Delphine wrote:
>
> >You All at Wikipedia kick some serious ASS!!  I was trying to figure
> >out how to site
> >a page from your website, when low and behold I found that you not
> >only had citation
> >information, but you also already had the MLA format ready to go.
> >I just wanted to say thank you for making my citation soooo easy!!
>
>
> I'd suggest we add a "Cite this version" link to the skins, but that
> might look like we're positioning ourselves as better than we are ;-)
>
>
> - d.

Is the old suggestion for putting a link to WP:TOOLS into the sidebar
still active? Rename it to something like advance features and you
could put the cite thing an other useful stuff there.

--
geni


subject:
[WikiEN-l] An actual RC patrol? (was Openness is a means to an end.
	Nothing more)

body:
geni wrote:
>On 12/1/05, Daniel Mayer <maveric149 at yahoo.com> wrote:

>> (better RC patrol features, trust networks to filter RC and watchlists,
>> article validation, etc).

>RC patrol is reaching it's pratical limit. I'm seeing more vandalism
>on my watchlist and no matter how good the people doing it there is
>simply no way for them to know if a large percentage of it is true or
>not

Would it be an idea to make RC patrol organised, i.e. people (admins
or not) sign on for shifts, checking all edits in a given block of
time? Two patrollers for each time period should be enough, three or
four for evenings US time. You do RC patrol - would something like
this make sense?

(I don't know how long the time periods would be - an hour? 30
minutes? 10 minutes?)

- d.


body:
geni wrote:

>Is the old suggestion for putting a link to WP:TOOLS into the sidebar
>still active? Rename it to something like advance features and you
>could put the cite thing an other useful stuff there.

I *like* that one. I'm a big fan of simple and clear interfaces that
nevertheless have a "Wizards may do what they like and keep both
pieces" button.

- d.


from_name: Delirium

subject: [Wikipedia-l] Openness is a means to an end. Nothing more

body:
Daniel Mayer wrote:

>>>The entire goal of this project is freedom and openness.
>>>
>>>
>
>That is incorrect. The entire goal of this project is to create the largest, most widely-used, and
>best encyclopedia in the world and to give that to everybody on the planet. Everything else, and I
>mean *everything* (including our openness and the community itself), is a means to *that* end.
>Nothing more.
>
>
I strongly disagree with that---that may be your goal (and perhaps
Jimbo's), but a goal of a lot of people here is to create a Free (as in
Freedom) encyclopedia as the primary end.  The fact that this increases
its availability is quite nice, but the Freedom aspect is not merely a
means to the end of increasing availability, but the end itself.  For me
at least, and I suspect at least some number of other people, this is
the *only* end---to produce a completely Free encyclopedia, which
everyone is then free to use as they wish, save that they may not
restrict others' right to do the same with their derived works.  This
then allows any third party to fulfill whatever end they have in mind,
including disseminating it to every person on earth, editing it into
other works, producing WikiReaders, producing travel guides, using it as
source material for literary works, or whatever else.

Were this not true, there would be a rival Gnupedia that many of us
would be working on instead---The Gnupedia proposal was withdrawn only
because Wikipedia serves this goal already.

-Mark


from_name: Justin Cormack

subject:
[WikiEN-l] An actual RC patrol? (was Openness is a means to an
	end. Nothing more)

body:
On Thu, 2005-12-01 at 17:10 +0000, David Gerard wrote:
> geni wrote:
> >On 12/1/05, Daniel Mayer <maveric149 at yahoo.com> wrote:
>
> >> (better RC patrol features, trust networks to filter RC and watchlists,
> >> article validation, etc).
>
> >RC patrol is reaching it's pratical limit. I'm seeing more vandalism
> >on my watchlist and no matter how good the people doing it there is
> >simply no way for them to know if a large percentage of it is true or
> >not
>
>
> Would it be an idea to make RC patrol organised, i.e. people (admins
> or not) sign on for shifts, checking all edits in a given block of
> time? Two patrollers for each time period should be enough, three or
> four for evenings US time. You do RC patrol - would something like
> this make sense?
>
> (I don't know how long the time periods would be - an hour? 30
> minutes? 10 minutes?)

Unworkable - who knows when they can do it.

Just queue new articles so they have to go via an admin before
joining the main namespace (they can sit in New: before that).

Not much code.


body:
On 12/1/05, David Gerard <dgerard at gmail.com> wrote:
> geni wrote:
> >On 12/1/05, Daniel Mayer <maveric149 at yahoo.com> wrote:
>
> >> (better RC patrol features, trust networks to filter RC and watchlists,
> >> article validation, etc).
>
> >RC patrol is reaching it's pratical limit. I'm seeing more vandalism
> >on my watchlist and no matter how good the people doing it there is
> >simply no way for them to know if a large percentage of it is true or
> >not
>
>
> Would it be an idea to make RC patrol organised, i.e. people (admins
> or not) sign on for shifts, checking all edits in a given block of
> time? Two patrollers for each time period should be enough, three or
> four for evenings US time. You do RC patrol - would something like
> this make sense?
>

If it were posible it would probably have some utility if only to give
us some idea of the amount of rescoures we have availible.

> (I don't know how long the time periods would be - an hour? 30
> minutes? 10 minutes?)

10 minutes. Those who can go longer are free to sign up back to back.
those of us who tend to get disstracted by seeing things we can fix
can still make a contribution

--
geni


body:
geni wrote:

>On 12/1/05, Ray Saintonge <saintonge at telus.net> wrote:
>
>
>>That page has been edited nearly 100 times since.  It's tagged as
>>official policy, but it's difficult to consider a page as representing
>>policy when its text is so unstable. Since checking the background of
>>each paragraph in a policy page would be unreasonable everything on the
>>page is in doubt.
>>
>>
>No in so far as policy is ment to reflect practice it is broadly correct.
>
>
Being "broadly" correct doesn't help unless you accept the principle
that these rules are only guidelines.  Failing that, even small changes
in wording can alter the meaning of a "rule".

Ec


from_name: Tony Sidaway

body:
On 12/1/05, Justin Cormack <justin at specialbusservice.com> wrote:
>
> Just queue new articles so they have to go via an admin before
> joining the main namespace

Why?  Isn't that missing the point of having a wiki in the first place?


subject: [WikiEN-l] EXTREME Fix Crappy Prose CHALLENGE!

body:
    http://en.wikipedia.org/wiki/Category:Articles_that_need_to_be_wikified

If you're feeling particularly strong and have a fresh pack of
[[Kretek|Gudangs]] and a bottle of whisky to hand, there's a Metric
Shitload of stuff in that category that can only be fixed by hard
editorial slog. Call them the "unfeatured articles" ... the polar
opposite of [[WP:FA]].

(Worst is when it's an article about something clearly article-worthy,
but just thinking about how to fix the crappy prose makes your brain
seize up ...)

[Note that I'm not saying "OMGWTFBBQ WESUCKANDWE'RED0000MED" ... I'm
pointing out a practical thing that people can do if they're feeling
inspired to hard unglamorous slog. I'm not sure I am right now; I'll
let you know when I'm back on Sunday.]

- d.


from_name: Delphine Ménard

body:
A little sweet something, since only the ones in the back of the room see those.

Chosen extracts from OTRS (http://meta.wikimedia.org/wiki/OTRS)

Names of people, places and emails have been removed.

Have a smile. ;-)

===
You All at Wikipedia kick some serious ASS!!  I was trying to figure
out how to site
a page from your website, when low and behold I found that you not
only had citation
information, but you also already had the MLA format ready to go.
I just wanted to say thank you for making my citation soooo easy!!

THANK YOU THANK YOU THANK YOU!!!

H.
===
I wanted to thank you for creating such a wonderful and accessible product,
and would like to suggest to you...

[snip good suggestion]

Thanks again for making me smarter,

C.

===
my name is [snip] and I'm from Slovakia.

I'm using your site only a few weeks(since I connected to the
Internet),but  I think is great! Great idea, great posts, great site,
WIKIPEDIA IS GREAT !!!
For me it's unvaluable source of informations. When I will earn some
money, I will donate.
Stay as you are in present - don't change to one of information-traders.

!!! THANKS FOR HELPING WORLD - THANKS FOR WIKIPEDIA !!!

====
Subject: Just a thank you
I just wanted someone in your organization to know that I love your website!
I do not know who invented it, but it is most often the website I go to when
I want to know something about a subject. It is a place to start for almost
EVERYTHING!

====
Hello. I just wish to say how very great such a site as Wikipedia is.
Kudos to all within the organisation, and keep up the great work.

Thank you really.

C.
===
Dear creators of this website,

I am a 21 year old Political Science major at the University of
[snip]. I would just like to comment on this website, because its
amazing.
There is so much information, and it is always accurate. I use this website
often when doing research for essays, and the information based on the world
wars is fantastic. Please keep up the good work, because you are making the
lives of students like me much easier.

===

You people (ie, Wiki
administrators) really are among the most efficient
I've ever dealt with!  Keep up the fantastic work, and
have a great weekend!!

M. - (Attorney at Law)

===

etc. etc.

These are just a few I could whip out, but I thought it would help us
remember that we are *also* doing a good job.

Thanks all.

Best,

Delphine
--
~notafish


subject: [Wikipedia-l] In those times of ... well, doubt.


subject: [WikiEN-l] An actual RC patrol?

body:
geni wrote:

[on signed-up RC patrol periods]

>10 minutes. Those who can go longer are free to sign up back to back.
>those of us who tend to get disstracted by seeing things we can fix
>can still make a contribution

You sign up for your 10-minute block, and you can spend an hour or
whatever on it but you will process that 10-minute block. That could
work.

- d.


from_name: Sam Korn

body:
On 12/1/05, Daniel Mayer <maveric149 at yahoo.com> wrote:
> What we need are teams of people working together in a way that minimizes duplicated effort. As
> is, there is no way to know if a diff has been looked at once before, never before, or 200 times.
> There is also no way to know what was being looked at (simple vandalism, subtle vandalism,
> accuracy, etc). Knowing at least the first part (how many times a diff has been looked at) will
> help a great deal. Sorting RC based on that would be even better.
>
> Better still would be to sort RC and similar lists based on trust networks. For example, I trust
> you and many other people. So edits either made by you and diffs checked by you should be OK in my
> eyes. It would be nice if my RC and similar lists de-emphasized your edits and edits checked by
> you. This could go one step farther: I trust your ability to judge whether or not other people are
> trustworthy. So it would be nice if I could trust by proxy all the users you trust. This creates a
> trust network.
>
> This could also be done P2P via an offline editor and thus minimize server load. The offline
> editor would do all the sorting after downloading raw data from Wikipedia.
>
> I think it is obvious that we need bigger and better guns to fight vandals.

This "trust network" sounds not entirely different to the whitelist on
CDVF.  It shouldn't be too difficult to create a shared whitelist that
members of a specified group can all use and add to.  Multiple lists
could be created and you could subscribe to as many as you like and
that the members accept you.

This sounds eminently possible to me, if a fair bit of work.  Do
people with some technical knowledge have an idea if it is possible?

--
Sam


body:
On 12/1/05, Justin Cormack <justin at specialbusservice.com> wrote:
> On Thu, 2005-12-01 at 17:10 +0000, David Gerard wrote:
> > geni wrote:
> > >On 12/1/05, Daniel Mayer <maveric149 at yahoo.com> wrote:
> >
> > >> (better RC patrol features, trust networks to filter RC and watchlists,
> > >> article validation, etc).
> >
> > >RC patrol is reaching it's pratical limit. I'm seeing more vandalism
> > >on my watchlist and no matter how good the people doing it there is
> > >simply no way for them to know if a large percentage of it is true or
> > >not
> >
> >
> > Would it be an idea to make RC patrol organised, i.e. people (admins
> > or not) sign on for shifts, checking all edits in a given block of
> > time? Two patrollers for each time period should be enough, three or
> > four for evenings US time. You do RC patrol - would something like
> > this make sense?
> >
> > (I don't know how long the time periods would be - an hour? 30
> > minutes? 10 minutes?)
>
> Unworkable - who knows when they can do it.

Obsesives who have wikipedia nights and the like.

> Just queue new articles so they have to go via an admin before
> joining the main namespace (they can sit in New: before that).
>
> Not much code.

Due to the level of new page patrol that is one area that is pretty
much covered and to be honest all the admin viewing in the world is
not going to be able to detect false info in a boarderline notable
person.

vandalism that hits already existing articles is more of a problem at
this point.

--
geni


body:
On Thu, 2005-12-01 at 17:38 +0000, Tony Sidaway wrote:
> On 12/1/05, Justin Cormack <justin at specialbusservice.com> wrote:
> >
> > Just queue new articles so they have to go via an admin before
> > joining the main namespace
>
> Why?  Isn't that missing the point of having a wiki in the first place?

The suggestion was to have a constant patrol, and process everything
very quickly. If you want to do this it should be enforced.

Any mechanism where things have to go through some form of category
change say is better than just hoping things dont get missed, and lets
you avoid the situation of not knowing what someone else has reviewed.

Doesnt have to be done by admins, although vandals might work it out
pretty quickly if they could sign off their own new articles.


from_name: Ilya N.

subject: [WikiEN-l] Most read US newspaper blasts Wikipedia

body:
Calls for a bs: namespace ;)

Anyways, I think this was a failiure on both sides.

Mr. Seigenthaler for perhaps blowing this a little out of proportion (for a
while there it shounded like he wanted wikipedia held legally responsibly).

Wikipedia for not detecting something obviously false after almost a third
of a year on what I would imagine could be at least read once every while

On 11/30/05, Rob <gamaliel8 at yahoo.com> wrote:
>
> I suspect the crap information inserted into the John
> Seigenthaler article was part of a general trend of a
> group of JFK conspiracy theorists who have used
> Wikipedia as a dumping ground for their more
> farfetched speculations.  I've spend a good chunk of
> my WP time over the last year cleaning up as much of
> this stuff as I could possibly stand, and in fact
> rewriting much of the Lee Harvey Oswald article was my
> first major WP project.
>
> Even if this has nothing to do with the conspiracy
> buffs, it is part of a much larger problem, which is
> that every unsourced text dump by an anon seems to be
> treated as holy writ and uncritically accepted.  While
> we should apply WP:accept good faith to editors, we
> should apply a lot more skepticism to unsourced info
> dumps, the source of many problems involving libel and
> copyright violations and just good old fashioned
> inaccuracy. We have a culture of openness and DIYism
> and all those good things, but I'm not convinced we
> have a culture of quality control yet. How could any
> halfway decent editor see a passage like "For a brief
> time, he was thought to have been directly involved in
> the Kennedy assassinations of both John, and his
> brother, Bobby. Nothing was ever proven" and not think
> "Hmmm, something's wrong here, at the very least it is
> totally unsourced".
>
> Maybe the problem is simply that an article like John
> Seigenthaler Sr. is too obscure to get a lot of eyes
> on it.  It appears that between the crap insertion and
> the insertion of a copyvio bio (possibly by
> Siegenthaler himself?) months later, only one editor
> edited the article.  Perhaps we could just chalk this
> all up to obscurity, but there are too many of the
> same type of problems with articles that aren't as
> obscure that we shouldn't just write this one off as
> an anomaly.
>
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
~Ilya N.
http://w3stuff.com/ilya/ (My website; DarkLordFoxx Media)
http://en.wikipedia.org/wiki/User:Ilyanep (on Wikipedia)


subject: [WikiEN-l] An actual RC patrol?

body:
On 12/1/05, David Gerard <dgerard at gmail.com> wrote:
> geni wrote:
>
> [on signed-up RC patrol periods]
>
> >10 minutes. Those who can go longer are free to sign up back to back.
> >those of us who tend to get disstracted by seeing things we can fix
> >can still make a contribution
>
>
> You sign up for your 10-minute block, and you can spend an hour or
> whatever on it but you will process that 10-minute block. That could
> work.
>
>
> - d.

That would require some softwear changes since you would need a way to
get your hands on ten minutes worth of recent changes (over 500 edits
at this time of day) in a way that you could store them. Resonably in
the sort term I think the best we can hope for is that we will be able
to identify gaps and try and motivate people into filling them.

--
geni


from_name: SJ

body:
On 12/1/05, Walter van Kalken <walter at vankalken.net> wrote:
> >>If you're writing about one of those topics that is a) not private
> >>research/analysis of your own, but b) has never been written about
> >>anywhere else [that you know of], then we need a new class of references :
> >>"personal observation by [user]", with a relevant tag not unlike the
> >>original-reporting templates used on Wikinews.  Then it will be crystal
> >>clear that readers should visit your page, and see whether they trust you
> >>as the primary/original observer/author.

Walter, please read what I wrote carefully.  The kind of article you
wrote should surely be kept in Wikipedia, but it should also clearly
identify you, Walter van Kalken, Wikipedia editor, as the source -- in
a template that clarifies which of various reasons led to the lack of
external links.  From least to most like OR :
  1) printed references exist, but the author couldn't find a cite at the moment
  2) the author knows of no printed references; personal communication
with (named source/authority)
  3) the author doesn't know of any printed references; direct
personal observation (simple observation, similar to a photo; not
'research')
  4) the author doesn't know of any printed references; 'common
knowledge' or 'common sense'

> >Much of this falls under 'original research', doesn't it?  Or are you
> >talking about the cases where someone believes that something is true
> >but doesn't have the references to hand?

Not necessarily.  It is important to distinguish between 'research'
and 'observation'.  When I add a photo I took of a U2 concert, and say
"U2 concert in Boston, December 2005", that's personal observation.
The image page tells you that [[User:Sj]] took the photo and uploaded
it on a given date.  Likewise for articles, in the very-rare case that
you've learned about a fact not noted elsewhere online (part of an
article); or a topic which is /referenced/ in many places but not
/explained/ anywhere online (a new article), perhaps first-hand from
an expert.  In practice, I think the number of such topics is
miniscule.  For instance...

> I am surprised that both you SJ and Mart are saying this. Obviously both
> off you didn't read my case about the soi article on english wikipedia.
> Which is an article like many which is almost impossibly referenced.

A minute's googling turned up at least two suitable references; I
added them to the English article.  If I knew any Thai, I'm certain I
could come up with more in that language.

> Since the two of you never read it I'll post it again here.

Don't get your undies in a bundle.

> 3) All the even-numbered sois are on one side of the street, the
> odd-numbered ones on the other.
>
> How do you want me to prove that from citations without flying you over
> here?

That's tough to find by searching online.  Nvertheless, I'm certain
there are references that discuss simple street numbering, in all
manner of languages; even guidelines for numbering new streets in
Thai.

> 4) If for instance a soi is added between soi 7 and soi 9 it will get
> the name soi 7/1, the next one soi 7/2 etc.

Ditto.

> 6) On lower Sukhumvit road in Bangkok for instance the soi's are named
> after important landowners or families of landowners who had land in the
> area in the past.
>
> Verified with Thais whose families actually come from these landowners
> and have been living in the area for a long time. Again no books.

Just name individual named-sois, and perhaps link to references that
mention that name for one or two of the major ones.

> 7) Some sois become major thoroughfares and because of that get known by
> their name only. Examples are Thonglor (Sukhumvit soi 55), Asoke
> (Sukhumvit soi 21) etc.
>
> Again plain fact. Books anyone?

Again, just link to sources that refer to these by their name (ideally
also mentioning their soi number as well)

> or that are known IRL. Like me, anyone can always call me (see my
> phonenumbers) I even put my homeaddress up once. I might not always be

Right.  Which is why, if the author can't find a source (generally one
will exist, /somewhere/), there should be a standard way to add a
'reference' bullet to an article that explains the author should be
treated as the source until a better one is found... and listing a
reason that no other source is provided.

++SJ


subject: [Foundation-l] Most read US newpaper blasts Wikipedia

body:
On 12/1/05, David Gerard <fun at thingy.apana.org.au> wrote:

> If the "trusted" print press turn away people who believe anything they
> see on the internet, I suspect that would actually be better for us than
> claiming we absolutely have to strangle the freedom that produced what
> we have so far.

We should certainly not strangle that freedom.  But I'm not worried
about people being 'turned away' from WP because of bad press.  I'm
worried about the real damage that may be done to people due to bad
content.  As a community, we should be far more concerned about this
than about our own image.

++SJ


body:
On 12/1/05, Justin Cormack <justin at specialbusservice.com> wrote:
> The suggestion was to have a constant patrol, and process everything
> very quickly. If you want to do this it should be enforced.
>
> Any mechanism where things have to go through some form of category
> change say is better than just hoping things dont get missed, and lets
> you avoid the situation of not knowing what someone else has reviewed.
>
> Doesnt have to be done by admins, although vandals might work it out
> pretty quickly if they could sign off their own new articles.

We tried this. We switched it off. Pretty much all new articles are
cheacked. With edit rates of at least once a second there is no way we
can chech every edit.

--
geni


body:
On 12/1/05, Sam Korn <smoddy at gmail.com> wrote:
> On 12/1/05, Daniel Mayer <maveric149 at yahoo.com> wrote:
> > What we need are teams of people working together in a way that minimizes duplicated effort. As
> > is, there is no way to know if a diff has been looked at once before, never before, or 200 times.
> > There is also no way to know what was being looked at (simple vandalism, subtle vandalism,
> > accuracy, etc). Knowing at least the first part (how many times a diff has been looked at) will
> > help a great deal. Sorting RC based on that would be even better.
> >
> > Better still would be to sort RC and similar lists based on trust networks. For example, I trust
> > you and many other people. So edits either made by you and diffs checked by you should be OK in my
> > eyes. It would be nice if my RC and similar lists de-emphasized your edits and edits checked by
> > you. This could go one step farther: I trust your ability to judge whether or not other people are
> > trustworthy. So it would be nice if I could trust by proxy all the users you trust. This creates a
> > trust network.
> >
> > This could also be done P2P via an offline editor and thus minimize server load. The offline
> > editor would do all the sorting after downloading raw data from Wikipedia.
> >
> > I think it is obvious that we need bigger and better guns to fight vandals.
>
> This "trust network" sounds not entirely different to the whitelist on
> CDVF.  It shouldn't be too difficult to create a shared whitelist that
> members of a specified group can all use and add to.  Multiple lists
> could be created and you could subscribe to as many as you like and
> that the members accept you.
>
> This sounds eminently possible to me, if a fair bit of work.  Do
> people with some technical knowledge have an idea if it is possible?
>
> --
> Sam

It's posible but it hits a brick wall pretty fast. A lot of the
vandalism on my watchlist is from anons.

Optimiseing is good but it hits problems:

You can only go so far.
If you sart ignoreing too many edits because you think they are safe
vandles will start to exploit that.

--
geni


from_name: Brion Vibber

subject: [Wikitech-l] Squid caching issue

body:
Travis Derouin wrote:
> HTTP/1.1 200 OK
> Date: Thu, 01 Dec 2005 19:31:03 GMT
> Server: Apache/2.0.46 (Red Hat)
> X-Powered-By: PHP/4.3.10
> Content-language: en
> Vary: Accept-Encoding,Cookie
> Cache-Control: s-maxage=18000, must-revalidate, max-age=0

You need to turn on squid mode, so that MediaWiki sends out a different max-age
for cacheable pages, and then have Squid rewrite that for downstream. Then squid
won't have to talk to the apache at all for cached hits for anonymous visitors
with no session cookies.

Otherwise Squid still has to hit Apache/MediaWiki for everything to check for
304s, which is a lot slower than being able to return directly from cache.

> But by tailing the logs and looking at how many times a popular page
> has been requested today, Apache is returning 200 codes for the same
> page just as many times as it is being requested from Squid, so Squid
> isn't serving any cached versions of the page.
>
> If the page hasn't changed, shouldn't it  be returning a 304 header
> response saying it hasn't been changed if Squid was working properly?

Probably should be; you might want to investigate that.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20051201/5108dccc/attachment.pgp>


from_name: daniwo59 at aol.com

body:
Thank you, Delphine.

I think we all needed that.

Danny


from_name: Daniel Mayer

body:
payroll

-- Delirium <delirium at hackish.org> wrote:
> I strongly disagree with that---that may be your goal (and perhaps
> Jimbo's), but a goal of a lot of people here is to create a Free (as in
> Freedom) encyclopedia as the primary end.  The fact that this increases
> its availability is quite nice, but the Freedom aspect is not merely a
> means to the end of increasing availability, but the end itself.

You say that, but then you explain why that is so in terms of increasing use and availability
(bringing us back into means-to-an end territory). Also, freedom to use Wikipedia would be
pointless if its quality was so bad that nobody would bother.

I'm here to create something that people will find useful. If it ain't useful, then who cares if
it is free? Wikipedia's free qualities are very, very important to be sure. But that aspect is
only part of the picture.

For me
> at least, and I suspect at least some number of other people, this is
> the *only* end---to produce a completely Free encyclopedia, which
> everyone is then free to use as they wish, save that they may not
> restrict others' right to do the same with their derived works.  This
> then allows any third party to fulfill whatever end they have in mind,
> including disseminating it to every person on earth, editing it into
> other works, producing WikiReaders, producing travel guides, using it as
> source material for literary works, or whatever else.

The value of freedom is in its use. The fact that Wikipedia is free makes it much more useful. One
reason I contribute is that I know my contributions will be kept free; again, that is a means to
an end (getting people like me and you to add content and discourage viable forks by making it
possible to easily incorporate any changes to the forked version).

-- mav

__________________________________________
Yahoo! DSL ? Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com


from_name: Netocrat

subject:
[Wikitech-l] Re: Re: Patch: suppress auto-numbering of TOC and
	honour	user prefs

body:
On Wed, 30 Nov 2005 17:13:39 +0000, Rowan Collins wrote:
[attribution truncated]
> On 29/11/05, Netocrat wrote:
>> Let me know if there's a more appropriate place to submit this.
>
> Well, I think the officially preferred way is to attach to a [new] bug
> on http://bugzilla.wikimedia.org and add the "patch" and "need-review"
> keywords.

After defining the constant in MagicWord.php as ?var Arnfj?r?
Bjarmason suggested I've done that.

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

[...]
--
http://members.dodo.com.au/~netocrat


body:
SJ wrote:

>We should certainly not strangle that freedom.  But I'm not worried
>about people being 'turned away' from WP because of bad press.  I'm
>worried about the real damage that may be done to people due to bad
>content.  As a community, we should be far more concerned about this
>than about our own image.
>
>
That's true, but at the moment Wikipedia has not yet instituted a system
by which we can say that we are even reasonably sure that a particular
revision of a particular article is accurate.  This has been
long-planned, but not operative.  In the meantime, people need to read
Wikipedia with a large grain of a salt---it is great for finding out
information, but any information that is important should be
double-checked (this is true of any sources, but especially true of ones
in flux).  Basically, as David Gerard has mentioned, we've peaked too
early---Wikipedia is still in beta, working out how to deal with these
issues, so should be treated appropriately.

Perhaps we should make the disclaimers more prominent?  There are plenty
of possible ways people could be damaged other than libel---for example,
someone could rely on a wholly made-up bit of medical advice.

-Mark


body:
On 12/1/05, geni <geniice at gmail.com> wrote:
> It's posible but it hits a brick wall pretty fast. A lot of the
> vandalism on my watchlist is from anons.
>
> Optimiseing is good but it hits problems:
>
> You can only go so far.
> If you sart ignoreing too many edits because you think they are safe
> vandles will start to exploit that.

Yep, a lot of the vandalism is from anons.  I personally would never
whitelist anons, as that just isn't reliable.  But with a whitelist
you cut out all the users who do make good edits, meaning you don't
have to check them.  All the sharing does beyond what already exists
is optimises it for use by many people.

Of course, not everyone should use this system.  Any universally-used
system has loop-holes.  Having numerous systems means the loopholes
disappear, or at least become insignificant.

I'm sure there *are* loopholes, but I haven't seen them yet.  Care to expand?

--
Sam


from_name: Thomas Gries

body:
To Brion:
thanks for your explanation [not copied here]

To all:
I overlooked this nice and recent
http://bugzilla.wikimedia.org/show_bug.cgi?id=3612
Function to compress or delete old content in database

which appears to be a solution or at least the best starting point to
find a solution to my question

>>to the database experts:
>>- How can the database of MediaWiki 1.5.x safely be pruned
>>( in order to actually remove the oldest revisions of Article, Talk,
>>User and User_talk pages ) ?
>>
>>


body:
On Thu, 1 Dec 2005, Delirium wrote:

> Perhaps we should make the disclaimers more prominent?  There are plenty of
> possible ways people could be damaged other than libel---for example, someone
> could rely on a wholly made-up bit of medical advice.

Let us by all means make disclaimers more prominent.  It is too late for
the project not to be successful -- from a position of strength the
community can afford to be more self-critical, and even to start
generating our own harsh statistics on how [in]accurate or [un]referenced
our content is.

More suited to wikipedia-l, since we're talking about that; re-adding it
to the Cc: list.

--SJ


subject:
[Wikipedia-l] Re: [Foundation-l] Most read US newpaper blasts
	Wikipedia


body:
On 12/1/05, Sam Korn <smoddy at gmail.com> wrote:
> On 12/1/05, geni <geniice at gmail.com> wrote:
> > It's posible but it hits a brick wall pretty fast. A lot of the
> > vandalism on my watchlist is from anons.
> >
> > Optimiseing is good but it hits problems:
> >
> > You can only go so far.
> > If you sart ignoreing too many edits because you think they are safe
> > vandles will start to exploit that.
>
> Yep, a lot of the vandalism is from anons.  I personally would never
> whitelist anons, as that just isn't reliable.  But with a whitelist
> you cut out all the users who do make good edits, meaning you don't
> have to check them.  All the sharing does beyond what already exists
> is optimises it for use by many people.
>
> Of course, not everyone should use this system.  Any universally-used
> system has loop-holes.  Having numerous systems means the loopholes
> disappear, or at least become insignificant.
>
> I'm sure there *are* loopholes, but I haven't seen them yet.  Care to expand?

When I do RC patrol I do it the old fashioned way and whitelist
everyone who isn't an anon. Other than say saturday morning and the
like that still means there are far to many edits for me to cheack all
of them.

--
geni