from_name: Daniel P.B.Smith

subject: [WikiEN-l] VfD is imperfect

body:
There's a need for VfD or something like it.

1) Some have argued that most of the actual deletions need not be and
in most cases should not be actual page deletions. They can, for
example, often be redirects. The thing, is that it doesn't matter
whether the disposition is a very ruthless edit, making the page into a
redirect, or deleting the page. The issue is that casual observer who
is not a subject expert, but is a savvy Wikipedian, looks at a page and
thinks "this looks like obvious garbage that probably ought to go."
When a page is to be effectively deleted and you're NOT absolutely
sure, there needs to be a place to take it to where a few other
eyeballs can look at it, where there is a high probability of getting a
few comments and where things take place in a well-defined time frame.

2) In my subjective opinion, it seems to me that some of the criticism
that is ostensible being directed at the VfD process is, in reality,
directed against individuals. That may be well be a misperception, but
it is my perception.

3) There is such a thing as a VfD regular. VfD regulars have developed
a clubby atmosphere. VfD regulars have developed a very unfortunate
tendency to talk as if they were in an executive session where the
author was absent when in fact the author of the article has been all
but invited to the meeting. Frank and jocular expressions of disgust at
repetitive situations are common. These have reached the point of being
Bad Things, and I think the Dartmouth affair and its aftermath show it.
So many people now enjoy piling on to anything Dartmouth that an
article about the wildlife of Dart'''moor''' was recently mentioned in
an "Oh, no, not another" context by someone who apparently couldn't be
bothered to look up Dartmoor in Wikipedia, on the Web, in a dictionary
or atlas, or anywhere else.

4) In theory, it seems to me, 95% of what's done in VfD could be done
by putting a note on the talk page of, say, [[The Law of Success]]
saying "I'm think this article is garbage and I'm going to make it into
#REDIRECT [[Napoleon Hill]]." The problem is that people really do
watch and respond to VfD postings, whereas article Talk pages on
garbage articles are not being tracked and do not get the benefit of
many eyes.

5) VfD does generate serious discussions. In many cases they are
thoughtful discussions. The outcome is rarely predictable and the
effect in many cases is beneficial.

VfD has problems. To say "It's broken" is overstating the case, and
figuring out what need to be done to improve it is not trivial or
obvious, since a lot of the sturm and drang is the result of genuine
differences in opinion about what the content of Wikipedia ought to be.

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


list: wikien-l

source: pipermail-mbox

from_name: Magnus Manske

subject: [WikiEN-l] Images from Smithsonian Libraries (Dibner Library)

body:
FYI: The Dibner Library at the Smithonian has many good images of
people, many of them in the PD by age. I asked for clearance to use
Dibner Library images on wikipedia. Here's the result.

Magnus

-------- Original Message --------
Subject: 	Re: Smithsonian Libraries image request
Date: 	Thu, 02 Sep 2004 10:56:23 -0400
From: 	Erin Clements <ClementsE at si.edu>
To: 	<magnus.manske at web.de>

Dear Mr. Manske,

For us to feel comfortable having the Dibner Portraits on Wikipedia, we would prefer this credit line:
"Image reproduced courtesy of the Smithsonian Institution Libraries from Scientific Identity, Portraits from the Dibner Library of the History of Science and Technology"
with a direct link to this site:http://www.sil.si.edu/digitalcollections/hst/scientific-identity/index.htm

We would like this line in lieu of "This image has been released into the public domain by the copyright holder, its copyright has expired, or it is ineligible for copyright. This applies worldwide."

We will forego the standard permissions form.  However, please keep in mind that the modern (post-1926) portraits are on our site under Fair Use policies for a non-profit educational project.  If they are used in other ventures, valid copyrights may need to be cleared.

Thank you for your interest in our collections,

Erin E. Clements
New Media Office, Smithsonian Institution Libraries
PO Box 37012 MRC 154
Washington, DC  20013-7012
p. 202.633.1708** new number
f.  202.786.2861
clementse at si.edu

>>> Magnus Manske <magnus.manske at web.de> 09/02/04 03:17AM >>>
Dear Mr. Clements,

first, let me thank you for your answer. Yes, wikipedia would very much
like to continue using images from your great resource. Please sent me
the permission form and credit line. As you no doubt have seen on the
Dumas image page, we already do link back to your site containing the
image, but we will of course extend/modify that credit according to your
request.

One point, however, remains: According to U.S. copyright law, a mere
reproduction of an image in the public domain *does* remain in the PD,
contrary claims notwithstanding. Only a "creative act" could change that
status, and scanning or (digital) photographic reproduction, which is
apparently the case for your image collection, does not constitute such
an act. Thus, the claim on the Dumas image page is correct.

Of course, we will cite the source of *all* your images with your credit
line, public domain or not. Your permission and the PD are, after all,
not mutually exclusive; the PD only extends any permission where
copyright law allows (and demands) it.

Yours,
Magnus Manske

Erin Clements wrote:

>Dear Mr. Manske,
>
>I am writing in response to your digital image request below. We would be happy for you to include images from our Scientific Portrait collection on Wikipedia.  However, we do ask that proper credit is given for the images and that you complete a permissions form.  Even if the works in question are a part of the public domain, the digital images which you are using are not. Therefore, I do question the line under this picture:
>http://en.wikipedia.org/wiki/Image:Jean_Baptiste_Andr%E9_Dumas.jpg
>which states that the image has been released into the public domain. Please refer here for more information: http://www.sil.si.edu/permissions/
>
>If Wikipedia would like to continue using, please let me know and I would be happy to provide you with the permission form and proper credit line.
>
>Sincerely,
>
>
>From: 	Magnus Manske <magnus.manske at web.de>
>To:	<LIBMAIL at si.edu>
>Date: 	7/29/04 9:29AM
>Subject: 	Copyright status of images
>
>Hello,
>
>I am a volunteer for Wikipedia, the free encyclopedia
>(http://www.wikipedia.org ). Recently, I have begun to include portraits
>from your excellent "Dibner Library of the History of Science and
>Technology" into the appropriate articles.
>
>Example : http://en.wikipedia.org/wiki/Gerardus_Joannes_Vossius
>
>While most of these images are in the public domain by age (as mere
>scanning does not change the copyright status), there have been some
>concerns especially about the "newer" ones.
>
>Wikipedia itself is a strictly non-commercial project - all contents is
>freely available and will remain so. However, all Wikipedia material is
>available under the GNU Free Documentation License (see
>http://en.wikipedia.org/wiki/Wikipedia:Copyrights ), which allows for
>commercial use. The information, however, will always stay free (as in
>free speech).
>
>The Wikipedia project would very much like to use all the Dibner Library
>images to complement its biography articles. We would, of course, link
>back to your site from every such image; in fact, we already do (click
>on the Vossius image from the link above) where we use them. It would be
>great if you could officially release the Dibner images under GFDL (or
>in the public domain); if not, please suggest an alternative that would
>be acceptable to you.
>
>Thank you in advance,
>Magnus Manske
>
>
>Erin E. Clements, Permissions Coordinator
>New Media Office, Smithsonian Institution Libraries
>PO Box 37012 MRC 154
>Washington, DC  20013-7012
>p. 202.633.1708** new number
>f.  202.786.2861
>clementse at si.edu
>
>
>
>
>


list: wikitech-l

from_name: Constans, Camille (C.C.)

subject: [Wikitech-l] Search down

body:
>
>
>Apologies if I missed a post, but why is the internal search down?
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>

If search is enabled during peak hours, wikipedia is down :)

We wait for the dedicated search server.

shaihulud


from_name: Conal Watterson

subject: [WikiEN-l] Another troll "testing" Wikipedia

body:
Wikipedia is going to need to be robust enough to cope. There's plenty
of junk on it at present, one is going to have to accept that.
"Wikifaith" is overrated IMO, there's no point in believing that
Wikipedia is some flawless amazing gift to humanity! Too many
wondermints!

Perhaps instead of just Featured Article or not, we could have ratings
on each article. How to set those would be another matter - but
there's likely to be some solution. Perhaps it could just be an
accumulated rating, that if one reads it, one can add your vote to the
average. Logged in users could have a greater influence, perhaps
sysops even more (or less ;o)

But perhaps I'm musing too much.

Zoney

On Sun, 5 Sep 2004 14:19:21 -0700 (PDT), Rick <giantsrick13 at yahoo.com> wrote:
>
> http://www.frozennorth.org/C2011481421/E652809545/index.html
>
> RickK
>
>
> ---------------------------------
> Do you Yahoo!?
> Win 1 of 4,000 free domain names from Yahoo! Enter now.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] Search down

body: Apologies if I missed a post, but why is the internal search down?


from_name: Zoney

subject: [WikiEN-l] Re: Re: Re: VfD is broken

body:
On Sun, 5 Sep 2004 22:11:57 -0700 (PDT), Rick <giantsrick13 at yahoo.com> wrote:
> How did something which was only first created on August 26 suddenly become policy without a vote or an open discussion?
>
> And if you think that inclusionists haven't been arguing to get rid of VfD, then you obviously haven't been reading all of the posts.
>
> RickK
>
> Chris Wood <standsongrace at hotmail.com> wrote:
> > Unfortunately, the things which CAN be quickly deleted are very limited.
> Right now, there is a huge number of pages written by a troll named [[El
> Coronado]] which are obvious fiction, but they are not allowed to be speedy
> deleted, because obviously false information is not an acceptable condition
> (by some) for speedy deletion. Instead, we have to go through the
> cumbersome VfD process to get rid of them. If obviously false information
> was an accpetable criterion, then we could have gotten rid of all of this
> user's creations already, and we wouldn't have several different entries on
> VfD for them.
> >
> > If there were no VfD, what would be the inclusionists' acceptable process
> for getting rid of this false information?
>
> I don't think any "inclusionists" have argued to get rid of VfD. We're just
> saying it isn't working like it was originally designed to. I don't have an
> alternative process, just a recommendation that people actually follow
> policy on which articles should be listed on VfD - this is
> http://en.wikipedia.org/wiki/Wikipedia:Importance
>
>
> ---------------------------------
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

I have not argued for immediate cessation of VfD. Rather I have agreed
that it would be nice to carefully and sensibly look at the
alternatives. At the least, this could cut down on VfD nominations.

Perhaps speedy-delete *could* be used more for vanity pages etc. But
perhaps add an appeals process for when it happens before the party
involved has a chance to defend themselves.

Perhaps merge-and-delete should NEVER reach VfD and rather just be
done (the content is not deleted, so it's not so contentious). But a
successful attribution procedure is needed to make this easier (the
history of the deleted page somehow preserved/added into the main
one). Maybe the history of the deleted page could be put in a sub-page
of the main page, with a link to that in the tagline of the edit
placing merged content?

Anyways, once again to emphasise:

*I favour debate - not immediate cessation of VfD*

Zoney

--
*~()____) This message will self-destruct in 5 seconds...


from_name: Erik Moeller

subject: [WikiEN-l] Re: Accuracy Heuristics

body:
David-

> More, it was submitted to Slashdot by the vandal in question.

> "In this experiment, I painted graffiti on the walls of the local school.
> It's not vandalism, though, as I'm blogging about it. It was just to test
> the response times of the janitorial staff. I suggest you all try what I
> did to prove it for yourself."

While I'm not too happy with what he did, I do hope that it breathes some
fresh life into the peer review discussion. The two core weaknesses of
Wikimedia are people acting like assholes and people who don't know what
they're talking about. If we systematically review and flag particular
revisions of articles, we can create a space within which they do not
exist.

The validation system which is currently in CVS is only a rating system
and doesn't really help in sorting out individual facts. I'm afraid that
as a sole measure, it would contribute to the problem rather than solve
it, as people grow eager to push articles through quality control and
choose high ratings. These articles then attain a false notion of being
authoritative. Similarly, controversial articles might never gain such
status because some people don't like their content.

There's an interesting project going on here:
http://en.wikipedia.org/Wikipedia:WikiProject_Fact_and_Reference_Check

Like the participants in this project, I've been thinking a bit about ways
to mark-up individual facts in articles. Essentially, I want to take a
text like

  The inscription is approximately 15 metres high by 25 metres wide, and
  100 metres up a cliff from an ancient road connecting the capitals of
  Babylonia and Media (Babylon and Ecbatana).

and mark up parts of it, like so:

  ??The inscription is approximately 15 metres high by 25 metres wide??

"??..??" means that this part of the article needs a source. Using CSS,
all passages marked with "??" could be highlighted or not, depending on
personal preferences.

or like this:

  ^+The inscription is approximately 15 metres high by 25 metres wide
  [[Source:Behistun, p.84]]

The part starting with "^+" would be referenced by the [[Source:]]. There
could be different markup for different quality citations, e.g. ^- for a
general encyclopedia or Google citation and ^= for a secondary source
citation.

The [[Source:]] namespace could be a magic template-type namespace that
would load the bibliographical data from a page and insert it into a
footnote, so we don't have to keep inserting the same information.

Using a method like this, we have real semantic information about
individual facts and can easily make statements like
* 80% of the facts in this article have sources
* 40% of the sources we cite are of high quality
* Source X is used in Y articles

Of course these claims themselves could be faked. But together with
stable-revision flagging and a consensus-based peer review process
associated with every page, we could try to do for quality what we've done
for quantity. If you wanted to, you could view only articles that have
been reviewed and that are deemed 100% accurate.

Regards,

Erik


subject: [Wikitech-l] Re: Accuracy Heuristics


list: wiktionary-l

from_name: Ray Saintonge

subject:
[Wiktionary-l] Attribution when uploading data from an other
	source

body:
Gerard Meijssen wrote:

> I am working on uploading the GEMET data into Wiktionary. The GEMET
> data does specify who phrased the defention to a term (they are
> typically institutions). From a GNU-FDL point of view we need to
> attribute where this infomation came from.
>
> There are three ways of doing this:
> *Upload them with a "GEMET" user so that the source is them and not me
> and have the source in there as text.
> *Upload them with a user depending of the institution that defined the
> term
> *Upload them with my own user, and have the source GEMET and the
> institution in text.
>
> Personally I think the second one is the most correct. The consequence
> is however that many users will be created. Any other ideas ??

The original defining institution should be mentioned at the right place
in whichever of the above options is chosen.  They do need to understand
that their definition will be editable in accordance with wiki custom.

Ec


list: foundation-l

from_name: Anthere

subject: [Foundation-l] Re: Article "Etes-vous archikhûbe et archifâkh ?"

body:
Note : Yannf a envoye cette copie a la ml ? ma
demande.

Yann,

Je pr?f?rerais tr?s tr?s vivement que lorsque tu
parles au nom du conseil de Wikimedia (ie, en tant que
porte parole)
* soit tu demandes ? un membre du board son opinion au
pr?alable
* soit qu'au minimum, tu mettes en copie le courrier
envoy?, ? la liste de discussion ou ? un membre.

Tu peux bien sur parfaitement ?crire en ton nom
propre.

Anthere

-------

Yann Forget a ?crit:
> Bonjour,
>
> L'article de la rubrique "?ducation" titr?
"Etes-vous archikh?be et
> archif?kh ?" (1) est en partie copi? depuis
l'encyclop?die en ligne
> Wikip?dia, notamment de
http://fr.wikipedia.org/wiki/Argot_scolaire . La
> licence des textes de cette encyclop?die impose de
citer la source si le
> texte est r?utilis?, hors votre article ne cite
aucune source. Pourriez-vous,
> s'il vous pla?t, corriger cette lacune ?
>
> En vous remerciant par avance,
> Yann Forget
> porte-parole de la fondation Wikipedia
>
> 1)
http://www.lefigaro.fr/education/20040825.FIG0233.html
>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> WikiFR-l mailing list
> WikiFR-l-g2DCOkC13y2GglJvpFV4uA at public.gmane.org
> http://mail.wikipedia.org/mailman/listinfo/wikifr-l

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail


list: wikimedia-l


from_name: Tim Starling

subject: [WikiEN-l] Re: VfD is broken

body:
Chris Wood wrote in full:
> Deletionism is a problem because it is against current Wikipedia policies.

[...and some other similar posts]

Chris, how about rolling those 6 posts up into one in the future, and
quoting the text that you're replying to. This is a mailing list, not IM.

-- Tim Starling


from_name: Brion Vibber

subject: [Wikitech-l] Database shema : let's start the fun

body:
Ashar Voultoiz wrote:
> Hello !
>
> Sometime ago there was a lot of discussion about a database shema
> change. I am wondering if that's a dead-end horse or if we can
> eventually start discussion again and eventually got the changes in for
> version 1.4 ?

The main holdup so far has been the knowledge that we'll need to convert
the current Wikipedias, so any change needs to be constrained to reduce
downtime.

The biggest changes that we'd like to do are:

* Put current and old revisions together, to avoid having to juggle data
between cur and old all the time and to allow a consistent revision
numbering scheme (permalinks for current revision as well as the olds)

* Separate page information like the title from the individual revision
data, so page renames of longstanding pages don't bog down the server
touching thousands of rows

* Separate the actual *text* out of the revision information table so
that contribs, history, etc don't pull so much junk into memory.

And possibly:
* Add language-specific title sort key field
* Add case-insensitive 'canonical title match' field

Now as you can imagine changing the cur and old tables is about the most
traumatizing thing we could do to the servers. :)

A 'minimal effort' change could be to move all cur revisions into old,
then rebuild a 'page' table from the cur data and let 'old' be a
revisions table. I believe Jamesday has been experimenting with seeing
how slow/fast this kind of conversion might be...

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040906/95fc388a/attachment.pgp>


from_name: Chris Wood

subject: [WikiEN-l] Re: Re: Re: VfD is broken

body:
> This doesn't mean the few listings that are voted outright and almost
> unanimous "keep" shouldn't be removed.
>
> A cadre of inclusionists aren't always right either. If it's
> controversial, then it stays. This doesn't stop the non-controversial
> items from getting removed.
>
> Jiang

If there are 4 votes for deletion, and 2 for inclusion, the article is
deleted. IMHO that's controversial, and not unanimous.


subject: [WikiEN-l] Re: VfD is broken

body:
> > Having an article only gives the impression to readers that we tolerate
junk.
>
> Which is good.  If we give the impression to readers that we tolerate
> only full-grown complete articles, we will detract contributors who are
> perhaps not quite as good a writer as they would like to be.

Exactly. This is why Nupedia failed.


subject: [WikiEN-l] Re: VfD is broken

body:
Thankyou. Those non-arguments are continually brought up by people, and
responses mentioning their uselessness ignored.


subject: [WikiEN-l] Re: VfD is broken

body:
> Let's step back and take a look:
>
> Looking over the VfD discussions, I have noticed that in the vast
> majority of cases the consensus is very clear one way or the other.
> Few listings cause anywhere near a 50/50 split.  In the cases where
> the consensus is to delete, that means the listing was justified --
> the content did not belong in the Wikipedia.  Good call, let's get
> rid of it and move on.  In the cases where the consensus is to keep,
> that means that someone was mistaken in their individual assessment
> of the article, but the community recognized the value of it.

No, consensus to delete does not mean the listing was justified. The parent
post of this thread pointed out how VfD is undermining Wikipedia policy.

> Those "deletionists" some people like to talk about are the same
> people overwhelmingly voting to keep valid articles.  They aren't
> deletionists; they are investigators.  They check to see whether
> a listed article belongs in the Wikipedia according to <whisper>
> standards </whisper>.  Most articles that are listed on VfD do end
> up getting deleted, and for good reason -- they didn't belong. The
> Wikipedia is an encyclopedia and it does have <whisper> standards
> </whisper>.  It disturbs me that I feel I have to whisper the
> word "standards" as if it were a dirty word. Those "deletionists"
> are merely people willing to take their time to see if an article
> meets minimum standards for inclusion in the Wikipedia.  The
> reason you see so many votes to delete is that, for the most part,
> people do a very good job in bringing only invalid articles to VfD
> (i.e. the system works).
>
> What types of articles get deleted on VfD?  Vanity pages,
> advertisements, original research, source material, medical advice,
> memorials to deceased friends, stories that received a small article
> on page 16 of their local newspaper years ago, political rants, game
> guides, neologisms, hoaxes, etc.  Anything that doesn't belong in an
> encyclopedia.  Standards.  It's all about standards.  This isn't about
> evil deletionists wanting to methodically delete every article until
> there is nothing left.  It is about "is this a valid article or not?"
>
> Some would argue "It doesn't hurt to leave non-encyclopedic junk
> because no-one will look for it / wikipedia isn't paper / anyone
> should be allowed to write anything they want."  Forget standards,
> let it devolve into a free-for-all so we can be proud of...  what?

Same here. Just because an article is not up to standard does not mean it
should be deleted, rather, it should be improved. Just because an article is
not important to 99% of people, should we ignore the 1% who are interested?
Wikipedia is supposed to be *more* than a traditional encyclopedia, and is
open to obscure articles. Many people on VfD don't seem to realise this, and
don't seem to have read the relevant policies.

What are these "standards" you mention? They aren't Wikipedia policy.

Have a look at Wikipedia:Importance.

> The examples I gave above are only some of the types of articles that
> do not qualify for Speedy Deletion but obviously do not belong in an
> encyclopedia.  So we can either let admins delete on-sight anything
> that doesn't belong (we don't need to go there) or else have a very
> limited list of things that can be deleted on-sight and list other
> questionables on a page to get community input.  Hmm...  that second
> option sounds a lot like what we have now.
>
> The system works.  It isn't broken.  It could use some tweaking,
> sure.  I'm open to constructive ideas to improve the system, as is
> being discussed in another thread.  To call VfD "broken," to say that
> it isn't needed, to declare that all content is valid, to compare a
> review process to a slum --  Well, I'll just bite my tongue.

Of course some content is invalid. Just not so much as is being deleted
daily at VfD. Especially when you consider current guidelines.

Some form of VfD is needed, but it is broken. 25 listings per day? What's
more important, deleting articles that many people think are unimportant
(ignoring the (obviously existing) people who think it is important), or
improving the quality of articles?


subject: [WikiEN-l] Re: Re:VfD is broken

body: Deletionism is a problem because it is against current Wikipedia policies.


subject: [WikiEN-l] Re: Re: VfD is broken

body:
I'm guessing you mean "person who does not exist in reality or in notable
fiction".


from_name: Luís Fernando

subject: [Wikitech-l] off-line GPL program

body:
Hello

I'm new here and joined after Jimmy seems to have liked my suggestion
about doing an off-line version of Wikipedia.

We all know Wikipedia is updated frequently, so it should have a daily
database of changes in order to the program be able to update the
database.

Basically, the database + program could be purchased on CD or downloaded on
internet. We could have a "static database" (since we can't rewrite
CDs) and make just "diffs databases" to update. When the diffs
database gets big, the program should suggest purchasing a new CD or an "updated
static database" (for the case the user has downloaded the program).

I'm interested on starting this program (that will be licensed as GPL)
and I can do it in C++ (compiling with Microsoft Visual C++). Since
it's a GPL program, I know most people would prefer using a GPL
compiler like gcc and maybe for an opensource OS, but I'm not used to
program on it.

Well... Of course I want to participate the project, but I want to do a Windows
version now (I've learned a lot of Windows APIs from other programs I did
before and I'm really not interested on learning all again for other
OS at this time). We may change the compiler since I have no problems
to make a few "adjustments" in the way I program and I'm a computer
science student, so one day or other I'll need to learn that.
After this program is done, we could port it to other OS, or if many
people don't agree to do it for Windows, we can split and each group
start doing it for different OS.

So now I've 2 questions, because I'm new here:
1) Was it already discussed here? Is there already something in
progress? (maybe I should have asked that before writting everything I
did ;) )

2) What do we have?
   a) How is wikipedia database organized?
   b) Can we have access to the "raw database" so the program could
   use it?
   c) Is there already a "changed log"?

3) Who's with me? ;)

I think that's all for now.

Regards,

/*

+---------------------------------+
| Lu?s Fernando Estrozi           |
+---------------------------------+
| Ci?ncia da Computa??o - USP     |
|                                 |
| mailto:lemon at grad.icmc.usp.br   |
| ICQ#: 25541891                  |
|                                 |
| http://grad.icmc.usp.br/~lemon/ |
+---------------------------------+

There are 10 types of people in the world: Those who understand binary, and those who don't

*/ EOF


subject: [WikiEN-l] Re: Re: Re: VfD is broken

body:
> Stubs yes, but their notability and/or verifiability is another. What
> will people think of how trustworthy our information is if we permit
> rubbish such as a biased advertisement for a discussion forum to
> languish on Wikipedia?

But what do you mean by notability? Your humble opinion? Have a look at the
proposed policy on what "notability" means at
http://en.wikipedia.org/wiki/Wikipedia:Importance.


subject: [WikiEN-l] Re: Re: Re: VfD is broken

body:
> Unfortunately, the things which CAN be quickly deleted are very limited.
Right now, there is a huge number of pages written by a troll named [[El
Coronado]] which are obvious fiction, but they are not allowed to be speedy
deleted, because obviously false information is not an acceptable condition
(by some) for speedy deletion.  Instead, we have to go through the
cumbersome VfD process to get rid of them.  If obviously false information
was an accpetable criterion, then we could have gotten rid of all of this
user's creations already, and we wouldn't have several different entries on
VfD for them.
>
> If there were no VfD, what would be the inclusionists' acceptable process
for getting rid of this false information?

I don't think any "inclusionists" have argued to get rid of VfD. We're just
saying it isn't working like it was originally designed to. I don't have an
alternative process, just a recommendation that people actually follow
policy on which articles should be listed on VfD - this is
http://en.wikipedia.org/wiki/Wikipedia:Importance

> It took a great deal of work and research by several people actively
involved in the VfD process to make this into a useable article.  Would
those of you objecting to VfD actually have preferred that it have remained
as it was in its original state?
> I am an active participant in [[Cleanup]].  But there are hundreds of
articles listed there that never get worked on.  By putting a 5-day deadline
on them on the VfD page, we get some very reasonable articles, which then
get kept.  VfD is NOT just a "deletionist" playground, it's a serious effort
by many people to make decent articles, or to figure out what to do with
articles that aren't decent.

We are saying "improve the article, don't delete it , if the article is
important (Wikipedia:Importance) enough". VfD is not about improvement, it's
about deletion. Cleanup is about improvement. Yes, there are some articles
(less than hundreds) which are never worked on. Yet surely that is better
than the hundreds which are deleted, not because they don't belong in
Wikipedia, but because they aren't good enough?


subject: [Wikitech-l] GNOME Pedia

body:
Saw this trundle across the wire on Planet GNOME, thought some might be
interested:

   Rodrigo Moya: 6/September/2004

   GNOME Pedia

   I've just imported to GNOME CVS  the code for the GNOME Pedia
   application, which is a GNOME frontend to the Wikipedia. This code
   comes  from Hendrik Richter, who started the application and had it
   more advanced than  my  skeleton.

   It is written in C#, and so far it should allow simple access to the
   Wikipedia (although  I can't confirm, since I'm missing gecko-sharp in
   my system, which  is needed).

http://rodrigo.gnome-db.org/news.php?6/September/2004

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040906/145a88ff/attachment.pgp>


subject: [WikiEN-l] Re: VfD is broken

body:
Sorry. I guess I'm reacting against people who seem not to read parent posts
properly... I won't do that again.


subject: [WikiEN-l] Re: Re: Re:VfD is broken

body:
> > Deletionism is a problem because it is against current Wikipedia
policies.
>
> Both extremes - extreme deletionism, and extreme inclusionism - are
> against current Wikipedia policies.
>
> -Matt (User:Morven)

Absolutely. So let's formulate a guideline which clarifies what those
policies are, so these extremes can be easily refuted
(http://en.wikipedia.org/wiki/Wikipedia:Importance).


from_name: Ævar Arnfjörð Bjarmason

subject: [Wikitech-l] A domain for is.wikipedia.org, wikipedia.is

body:
Two users on the Icelandic Wikipedia (Spm and Svavarl) have been
considering buying the Wikipedia.is domain for the Icelandic
wikipedia. This email is sent to you (Jimbo Wales) as well as the
WikiTech list and the WikiIS list to inquire about political will to
do this so to speak.

Technically we could do this without any involvement from Wikimedia
Svavarl has already voulenteered to host the DNS servers and
(apperently) to pay for it. The cost being 10,000 ISK pr. year + tax
which is about $160 USD.

Which brings me to the point of this all, i would like to know if the
Wikimedia foundation would be willing to write all interwikilinks to
the icelandic wikipedia as http://wikipedia.is or
http://www.wikipedia.is (depending on which we choose) instead of
http://is.wikipedia.org and whether this would require that it have
legal custody of the domain ( which would be no issue at all for us ).

Our reasons for wanting a domain are threefold, first none-.is domains
are generally shunned in Iceland for aesthetic reasons, .com, .net and
.org domains are generally associated with something
none-professional, no corporation or respected institute would use
them. Second is the charge for foreign downloads in Iceland is about
$3 per 100MB, this of course is measured by IP addresses and not by
TLD's however the general misconception among the general population
is the opposite, for this reason many do not visit none-.is sites when
they approach their download limit which ranges from 100MB to 4GB for
common ASDL connections (going from 100MB to 4GB cost about $50).
Third the Icelandic wikipedia does not show up in many Icelandic
searches, most notably not by leit.is (a search engine used by
technophobes) and by "$query site:is" on google, though it should be
noted that passing the hl=is option to google will turn up
is.wikipedia.org. This only happens when using the Icelandic google
interface which many do not use (mainly because it's outdated, doesn't
list news, froggle and others).


subject: [Wikitech-l] Re: Automatic minor edits

body:
>Chris Wood wrote:
>> Rules for marking minor edits could go something like this:
>> 1) All edits by anonymous users are minor (same rule as now)
>> 2) A change of 5 words or less, not next to each other or in the same
>> sentence, is major.
>> 3) Any number of formatting changes (italics, tables, header levels etc)
is
>> major.
>> 4) Everything else is minor.
>
>Pop quiz: what's wrong with the above text?
>
>-- brion vibber (brion @ pobox.com)

LOL,  *is embarrassed*

As Timwi said, perhaps "minor" should be renamed to "trivial" in any case,
in which case maybe this could work?

Or perhaps just a "min-diff" thing as Erik suggested.


from_name: Thomas R. Koll

body:
On Mon, Sep 06, 2004 at 02:17:12PM +0200, ?var Arnfj?r? Bjarmason wrote:
> Technically we could do this without any involvement from Wikimedia
> Svavarl has already voulenteered to host the DNS servers and
> (apperently) to pay for it. The cost being 10,000 ISK pr. year + tax
> which is about $160 USD.

Uh, that's expensive, I get my de. domains for 11,- euro per year.

> Our reasons for wanting a domain are threefold, first none-.is domains
> are generally shunned in Iceland for aesthetic reasons, .com, .net and
> .org domains are generally associated with something
> none-professional, no corporation or respected institute would use
> them. Second is the charge for foreign downloads in Iceland is about
> $3 per 100MB, this of course is measured by IP addresses and not by
> TLD's however the general misconception among the general population
> is the opposite, for this reason many do not visit none-.is sites when
> they approach their download limit which ranges from 100MB to 4GB for
> common ASDL connections (going from 100MB to 4GB cost about $50).

OK, that's a complicated situation. I'd suggest setting up
a weekly-updated mirror at wikipedia.is and redirecting all
edit-requests to the wikipedia.org
Do Svavarl have the same situation for his own server? I.e. does
it cost him more if non-is computers connect to his server?
If not, we should consider using his offer for a proxy which
would proxy EVERY request to is.wikipedia.org via his server.
I'm sure gwicke who has set up the squid can deliver more help
about that issue.

We had discussions about moving some wikipedias to different locations
than the current one but for the admins it's easier to maintain only
one server-farm.

ciao, tom
--
== Weblinks ==
* http://shop.wikipedia.org - WikiReader Internet zu kaufen
* http://de.wikipedia.org/wiki/Benutzer:TomK32
* http://www.hammererlehen.de - Urlaub in Berchtesgaden


from_name: Minty

body:
Hello.  Sort of jumping in from nowhere, hope thats ok.

> OK, that's a complicated situation. I'd suggest setting up
> a weekly-updated mirror at wikipedia.is and redirecting all
> edit-requests to the wikipedia.org

You could also use an apache setup, and do proxypassing and caching.

This is a bit random, but fwiw :

No weekly updates - it requests docs as it needs them.  Tweaking the
cache settings would control your bandwidth usage - either force it to
cache for ~1 week, or else check on each request if it needs to
re-download the source.  Assuming the original wikipedia site allows
you to cache it's pages....

This would also let dynamic content be served from your .is domain
(logged in users), although it would push the bandwidth usage of your
"proxy" up quite a bit.

A couple more apache config rules would tell it to redirect edit
requests to the original.  Although, technically, you might prefer to
have these sent through your local domain, and have it act as a proxy.
 That way edits don't dump users at the .org site.

I may have missed something, but I think from a vanilla apache setup,
you can get this working with exactly no coding and only about 5-10
lines in the apache config.  Quite neat really.....

It does assume all the links in the html are relative and don't
specify a domain in full, but that does appear to be the case from a
quick scan.  If they did exist, your users would end up back on the
original .org site.

I should also point out that I'm not taking about a proxy that would
require anyone to tinker with their browser settings, nor would it
work for anything other than the wikipedia site.

- User requests www.wikipedia.is/something
- Request arrives at www.wikipedia.is machine/apache
  - apache proxies the request to is.wikipedia.org/something
  - returns the result to user

Obviously it would be a tad slower than going to the original site direct.

Anyway....  I should also point out that the vast majority of people
(namely, world minus geek) rarely pay the slightest attention to the
url anyway - hence why you see search queries for domain names.  But
then, those people probably aren't on this list :)


body:
On Mon, 6 Sep 2004 14:32:59 +0200, Thomas R. Koll <tomk32 at gmx.de> wrote:
> On Mon, Sep 06, 2004 at 02:17:12PM +0200, ?var Arnfj?r? Bjarmason wrote:
> > Technically we could do this without any involvement from Wikimedia
> > Svavarl has already voulenteered to host the DNS servers and
> > (apperently) to pay for it. The cost being 10,000 ISK pr. year + tax
> > which is about $160 USD.
>
> Uh, that's expensive, I get my de. domains for 11,- euro per year.
>
>
> > Our reasons for wanting a domain are threefold, first none-.is domains
> > are generally shunned in Iceland for aesthetic reasons, .com, .net and
> > .org domains are generally associated with something
> > none-professional, no corporation or respected institute would use
> > them. Second is the charge for foreign downloads in Iceland is about
> > $3 per 100MB, this of course is measured by IP addresses and not by
> > TLD's however the general misconception among the general population
> > is the opposite, for this reason many do not visit none-.is sites when
> > they approach their download limit which ranges from 100MB to 4GB for
> > common ASDL connections (going from 100MB to 4GB cost about $50).
>
> OK, that's a complicated situation. I'd suggest setting up
> a weekly-updated mirror at wikipedia.is and redirecting all
> edit-requests to the wikipedia.org
That would not be the same as getting a domain.
> Do Svavarl have the same situation for his own server? I.e. does
> it cost him more if non-is computers connect to his server?
> If not, we should consider using his offer for a proxy which
> would proxy EVERY request to is.wikipedia.org via his server.
> I'm sure gwicke who has set up the squid can deliver more help
> about that issue.
>
> We had discussions about moving some wikipedias to different locations
> than the current one but for the admins it's easier to maintain only
> one server-farm.
>
> ciao, tom
> --
> == Weblinks ==
> * http://shop.wikipedia.org - WikiReader Internet zu kaufen
> * http://de.wikipedia.org/wiki/Benutzer:TomK32
> * http://www.hammererlehen.de - Urlaub in Berchtesgaden
>


subject: [Wikitech-l] Re: Database shema : let's start the fun

references:
<chi9tu$vv8$1@sea.gmane.org> <413CC55F.30307@pobox.com>
	<chipdj$13t$1@sea.gmane.org>

body:
Ashar Voultoiz wrote:
> With the millions of revision I am not sure if 'revisions' will be fast
> maybe add another table wich cache the data like:
>
> lastest(article_id, revision_id)
>
> Where:
>   'lastest.article_id' is UNIQUE
>   'lastest.revisions_id' point to 'revisions.id'

Why have a separate table? Put that in the page table (equivalent of cur
without the revisons themselves).

> Can't it be configured per database in mysql ? Looks like we can use
> collation for this purpose:

That's all MySQL 4.1 stuff, which is still in beta. We can't rely on any
of it being present.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040906/0d536ad9/attachment.pgp>


body:
This whole proxy discussion is a bit of topic though seeing as my
inquiry was about DNS related issues.

On Mon, 6 Sep 2004 14:42:01 +0100, Minty <mintywalker at gmail.com> wrote:
> Hello.  Sort of jumping in from nowhere, hope thats ok.
>
> > OK, that's a complicated situation. I'd suggest setting up
> > a weekly-updated mirror at wikipedia.is and redirecting all
> > edit-requests to the wikipedia.org
>
> You could also use an apache setup, and do proxypassing and caching.
>
> This is a bit random, but fwiw :
>
> No weekly updates - it requests docs as it needs them.  Tweaking the
> cache settings would control your bandwidth usage - either force it to
> cache for ~1 week, or else check on each request if it needs to
> re-download the source.  Assuming the original wikipedia site allows
> you to cache it's pages....
>
> This would also let dynamic content be served from your .is domain
> (logged in users), although it would push the bandwidth usage of your
> "proxy" up quite a bit.
>
> A couple more apache config rules would tell it to redirect edit
> requests to the original.  Although, technically, you might prefer to
> have these sent through your local domain, and have it act as a proxy.
>  That way edits don't dump users at the .org site.
>
> I may have missed something, but I think from a vanilla apache setup,
> you can get this working with exactly no coding and only about 5-10
> lines in the apache config.  Quite neat really.....
>
> It does assume all the links in the html are relative and don't
> specify a domain in full, but that does appear to be the case from a
> quick scan.  If they did exist, your users would end up back on the
> original .org site.
>
> I should also point out that I'm not taking about a proxy that would
> require anyone to tinker with their browser settings, nor would it
> work for anything other than the wikipedia site.
>
> - User requests www.wikipedia.is/something
> - Request arrives at www.wikipedia.is machine/apache
>   - apache proxies the request to is.wikipedia.org/something
>   - returns the result to user
>
> Obviously it would be a tad slower than going to the original site direct.
>
> Anyway....  I should also point out that the vast majority of people
> (namely, world minus geek) rarely pay the slightest attention to the
> url anyway - hence why you see search queries for domain names.  But
> then, those people probably aren't on this list :)
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Gerard Meijssen

subject: [Wikitech-l] Attribution when uploading data from an other source

body:
I am working on uploading the GEMET data into Wiktionary. The GEMET data
does specify who phrased the defention to a term (they are typically
institutions). From a GNU-FDL point of view we need to attribute where
this infomation came from.

There are three ways of doing this:
*Upload them with a "GEMET" user so that the source is them and not me
and have the source in there as text.
*Upload them with a user depending of the institution that defined the term
*Upload them with my own user, and have the source GEMET and the
institution in text.

Personally I think the second one is the most correct. The consequence
is however that many users will be created. Any other ideas ??

Thanks,
    GerardM


subject: [Wiktionary-l] Attribution when uploading data from an other source


from_name: Gabriel Wicke

body:
On Mon, 2004-09-06 at 14:32 +0200, Thomas R. Koll wrote:

> If not, we should consider using his offer for a proxy which
> would proxy EVERY request to is.wikipedia.org via his server.
> I'm sure gwicke who has set up the squid can deliver more help
> about that issue.

If it's a reliable server and the offer is still valid, why not? To run
a squid, port 80 needs to be unused though, or one has to do some
iptable tricks to redirect wikipedia to another port. Apache would work
as a proxy as well- but it doesn't support purging, so it couldn't
cache.
An account on the server would be necessary imo, otherwise maintaining
the squid would be difficult.
--
Gabriel Wicke


body:
The offer was for DNS hosting, i have no idea if he is willing to host
a squid server.

On Mon, 06 Sep 2004 16:06:39 +0200, Gabriel Wicke <lists at wikidev.net> wrote:
> On Mon, 2004-09-06 at 14:32 +0200, Thomas R. Koll wrote:
>
> > If not, we should consider using his offer for a proxy which
> > would proxy EVERY request to is.wikipedia.org via his server.
> > I'm sure gwicke who has set up the squid can deliver more help
> > about that issue.
>
> If it's a reliable server and the offer is still valid, why not? To run
> a squid, port 80 needs to be unused though, or one has to do some
> iptable tricks to redirect wikipedia to another port. Apache would work
> as a proxy as well- but it doesn't support purging, so it couldn't
> cache.
> An account on the server would be necessary imo, otherwise maintaining
> the squid would be difficult.
> --
> Gabriel Wicke
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


references:
<chi9tu$vv8$1@sea.gmane.org>	<413CC55F.30307@pobox.com>	<chipdj$13t$1@sea.gmane.org>	<413CEB1A.7010806@pobox.com>
	<chirl1$5b1$1@sea.gmane.org>

body:
Ashar Voultoiz wrote:
>> Why have a separate table? Put that in the page table (equivalent of
>> cur without the revisons themselves).
>
> But the page table will have millions of entries (as it track all
> current articles and past revisions). Maybe it will slow down queries ?
> Or maybe it's what indexes are for, aren't they ?

No, it only has one row per page.

>>> Can't it be configured per database in mysql ? Looks like we can use
>>> collation for this purpose:
>>
>> That's all MySQL 4.1 stuff, which is still in beta. We can't rely on
>> any of it being present.
>
> Maybe we can wait for MySQL 4.1 to become stable and well spread ... Not
> sure if we can wait several months though.

We support back to what Debian stable ships, which is PHP 4.1.2 and
MySQL 3.23.x.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040906/2d0061f3/attachment.pgp>


from_name: cookfire

body:
Gerard Meijssen schreef:

> I am working on uploading the GEMET data into Wiktionary. The GEMET
> data does specify who phrased the defention to a term (they are
> typically institutions). From a GNU-FDL point of view we need to
> attribute where this infomation came from.
>
> There are three ways of doing this:
> *Upload them with a "GEMET" user so that the source is them and not me
> and have the source in there as text.
> *Upload them with a user depending of the institution that defined the
> term
> *Upload them with my own user, and have the source GEMET and the
> institution in text.
>
> Personally I think the second one is the most correct. The consequence
> is however that many users will be created. Any other ideas ??

Back when I was a lot more active I have been entering all the chemical
elements into the English Wiktionary. To give attribution to I made a
reference to the source material in three places:

- the entry itself
- the comment
- the talk page of each of these entry pages

Maybe it was a bit overkill, but it was the most effective way I could
think off. You are the one who is entering them, though, so you are the
'operator'. I wouldn't create another user. You deserve the credit of
doing the work. It will also get pretty messy if you have to log in and
out all the time, just to have the material submitted under the correct
user account.
I understand that this material is not only going to go into the nl
Wiktionary, so that would mean you are going to be creating such users
for each Wiktionary.

Polyglot


from_name: Thomas Luft

body:
?var Arnfj?r? Bjarmason wrote:

>The offer was for DNS hosting, i have no idea if he is willing to host
>a squid server.
>
Hi ?var,

if I understand it correctly you suggest setting up www.wikipedia.is and
send all queries there to is.wikipedia.de. So the traffic would still
cost more because people end up at wikipedia.org but the most of the
non-geeks will visit the site because its TLD is .is?
Was that what you meant?
Regards

Thomas


from_name: Jens Ropers

body:
Normally I would weigh in for making wikipedia.is a REDIRECT only and
against your suggestion to move the show from is.wikipedia.org to
wikipedia.is. After all, there is merit in the current, somewhat
uniform XYZ.wikipedia.org setup, which e.g. allows switching language
Wikipedias by editing the address line.

However, seeing your unique reasons (if it really is as "bad" as you
say) maybe the best option would be to make wikipedia.is and
is.wikipedia.org mirrors? If you really want to "keep it in the
country", you'd maybe have to host the mother lode in Iceland anyway.
Or would that be too traffic intensive and problematic as far as edit
conflicts?

-- Jens

On 6 Sep 2004, at 16:05, wikitech-l-request at wikimedia.org wrote:

> Message: 3
> Date: Mon, 6 Sep 2004 14:17:12 +0200
> From: ?var Arnfj?r? Bjarmason <avarab at gmail.com>
> Subject: [Wikitech-l] A domain for is.wikipedia.org, wikipedia.is
>
> Our reasons for wanting a domain are threefold, first none-.is domains
> are generally shunned in Iceland for aesthetic reasons, .com, .net and
> .org domains are generally associated with something
> none-professional, no corporation or respected institute would use
> them. Second is the charge for foreign downloads in Iceland is about
> $3 per 100MB, this of course is measured by IP addresses and not by
> TLD's however the general misconception among the general population
> is the opposite, for this reason many do not visit none-.is sites when
> they approach their download limit which ranges from 100MB to 4GB for
> common ASDL connections (going from 100MB to 4GB cost about $50).
> Third the Icelandic wikipedia does not show up in many Icelandic
> searches, most notably not by leit.is (a search engine used by
> technophobes) and by "$query site:is" on google, though it should be
> noted that passing the hl=is option to google will turn up
> is.wikipedia.org. This only happens when using the Icelandic google
> interface which many do not use (mainly because it's outdated, doesn't
> list news, froggle and others).


body:
On Mon, 06 Sep 2004 16:39:24 +0200, Thomas Luft <tluft at web.de> wrote:
> ?var Arnfj?r? Bjarmason wrote:
>
> >The offer was for DNS hosting, i have no idea if he is willing to host
> >a squid server.
> >
> Hi ?var,
>
> if I understand it correctly you suggest setting up www.wikipedia.is and
> send all queries there to is.wikipedia.de.
The main reason we want this now is that we indent to send out a press
release about the 1 million articles plus our own little paragraph
about the Icelandic wikipedia. Having wikipedia.is would go down
better with the Icelandic press than some .org domain due to reasons
specified in the original message.

What i was asking, or meant to ask is whether it would be possible to
change the rendering of [[is:* and [[:is:* from
http://is.wikipedia.org to http://www.wikipedia.is both in interwiki
links and in in line text.
>So the traffic would still
> cost more because people end up at wikipedia.org but the most of the
> non-geeks will visit the site because its TLD is .is?
> Was that what you meant?
Yes, however i meant not to setup a redirect domain but change the
official domain from is.wikipedia.org to wikipedia.org, if we just
wanted a redirect we could set that up ourselves without any
assistance from wikimedia.
> Regards
>
> Thomas
>


from_name: vtulimak at hytti.uku.fi

subject:
[Wikitech-l] JATKO: Re: toplist for most common wikipedia "not
	found" queries

body:
----- Forwarded message "Jimmy (Jimbo) Wales" <jwales at wikia.com> ----
Date: Sat, 4 Sep 2004 09:08:21 -0700
From: "Jimmy (Jimbo) Wales" <jwales at wikia.com>
Subject: Re: toplist for most common wikipedia "not found" queries
To: vtulimak at hytti.uku.fi

Can you send this to wikitech-l mailing list, it is a good idea.

vtulimak at hytti.uku.fi wrote:

>
>   Hi!
>
>   How about a top-1000 list for most commonly searched queries that did not
> return any search results? A special table for this to database. Top 1000
> because some of most common typos would end up quite high in that chart. This
> way people could provide the information that is most needed by wikipedia
users.
>
>   cheers,
>   Ville Tulim?ki
>

----- end of forwarded message -----


from_name: Smári P. McCarthy

subject:
[WikiIS-l] Re: [Wikitech-l] A domain for is.wikipedia.org,
	wikipedia.is

body:
Hello all,

  As far as I'm concerned, a redirect would be enough. However, the
interwiki hack would be quite nice if it's a possibility.

  I think ?var is making things slightly complicated by requesting this
though. Our original discussion (mine and SvavarL's that is) was
regarding the option of having wikipedia.is for reasons of
"advertising"... we have been preparing a poster campaign for schools
and other places of education, to increase awareness of Wikipedia's
existence in Iceland... our active editor group is small and we tend to
get overly entertained by minor details, hence it would be a good thing
to size it up a bit. (?var told me that someone had inquired about the
original XCF of the advertizement.. but it is indeed a Word Document,
which I keep forgetting to upload when I'm at work, sorry. But I am now
offtopic..)

Getting back on track, the situation is quite straightforward: We would
like the wikipedia.is domain.

The questions are therefore three:

a) Does the Wikimedia foundation make any claims to- or requests
regarding domains referencing Wikipedia, i.e. registration rights,
subdomains, MX transfers, etc?

b) Does MediaWiki currently have the technical capabilities to reference
is.wikipedia.org interwiki's as wikipedia.is instead, without any major
hassle for the developers or inconveniances to anything else, and will
somebody be willing to enable such referencing if we were to aquire the
domain?

c) Is there someone who would be willing to configure the Apache servers
to accept wikipedia.is and/or www.wikipedia.is as a Virtual Host
referencing the same internal Wiki directory as is.wikipedia.org
currently does?

I hope that clears things up a bit...

   kv, Smari.
	[[User:Spm]] on en. and is.

p.s., a question to the developers, completely unrelated to the above:
Why is there a differentiation made between the terms "article" and
"category"? Would it not be clever to allow any article to reference
another article as it's category? This has probably been debated at your
end before.. but I wasn't there. :-)

--
Sm?ri P. McCarthy
spm at vlug.eyjar.is
(+354) 662 2701


from_name: Ashar Voultoiz

subject: [Wikitech-l] Re: Search down

body:
Constans, Camille (C.C.) wrote:
>>
>>Apologies if I missed a post, but why is the internal search down?
>>_______________________________________________
>>Wikitech-l mailing list
>>Wikitech-l at wikimedia.org
>>http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> If search is enabled during peak hours, wikipedia is down :)
>
> We wait for the dedicated search server.
>
> shaihulud

Today's Tip:
http://www.google.com/
  [foobar site:wikipedia.org    ] [Go]

:o)

--
Ashar Voultoiz


list: wikipedia-l

subject: [Wikipedia-l] Wikipedia on the BBC website !!

body:
http://news.bbc.co.uk/2/hi/technology/3624384.stm

:)

Thanks,
    GerardM


from_name: David Gerard

subject: [WikiEN-l] Re: Accuracy Heuristics

body:
On 09/06/04 09:26, Erik Moeller wrote:

> While I'm not too happy with what he did, I do hope that it breathes some
> fresh life into the peer review discussion. The two core weaknesses of
> Wikimedia are people acting like assholes and people who don't know what
> they're talking about. If we systematically review and flag particular
> revisions of articles, we can create a space within which they do not
> exist.
> The validation system which is currently in CVS is only a rating system
> and doesn't really help in sorting out individual facts. I'm afraid that
> as a sole measure, it would contribute to the problem rather than solve
> it, as people grow eager to push articles through quality control and
> choose high ratings. These articles then attain a false notion of being
> authoritative. Similarly, controversial articles might never gain such
> status because some people don't like their content.

That would be the sort of thing that worried me about a rating system.

> There's an interesting project going on here:
> http://en.wikipedia.org/Wikipedia:WikiProject_Fact_and_Reference_Check
> Like the participants in this project, I've been thinking a bit about ways
> to mark-up individual facts in articles. Essentially, I want to take a
> text like
>   The inscription is approximately 15 metres high by 25 metres wide, and
>   100 metres up a cliff from an ancient road connecting the capitals of
>   Babylonia and Media (Babylon and Ecbatana).
> and mark up parts of it, like so:
>   ??The inscription is approximately 15 metres high by 25 metres wide??
> "??..??" means that this part of the article needs a source. Using CSS,
> all passages marked with "??" could be highlighted or not, depending on
> personal preferences.
> or like this:
>   ^+The inscription is approximately 15 metres high by 25 metres wide
>   [[Source:Behistun, p.84]]
> The part starting with "^+" would be referenced by the [[Source:]]. There
> could be different markup for different quality citations, e.g. ^- for a
> general encyclopedia or Google citation and ^= for a secondary source
> citation.
> The [[Source:]] namespace could be a magic template-type namespace that
> would load the bibliographical data from a page and insert it into a
> footnote, so we don't have to keep inserting the same information.

Oh, I *do* like that. Has this been experimented with? Has a protocol/
language guru sanity-checked these additions to MediaWiki syntax?

> Of course these claims themselves could be faked. But together with
> stable-revision flagging and a consensus-based peer review process
> associated with every page, we could try to do for quality what we've done
> for quantity. If you wanted to, you could view only articles that have
> been reviewed and that are deemed 100% accurate.

This sounds absolutely wonderful :-)

- d.


from_name: Nicolas Weeger

body:
Gerard Meijssen a ?crit :
> http://news.bbc.co.uk/2/hi/technology/3624384.stm
>
> :)
>
>
> Thanks,
>    GerardM

Nice, except for that:

They also have around 300 volunteer system administrators who oversee
entries.

which is plain wrong since sysops don't know everything :)

Nicolas Ryo


from_name: Delirium

subject:
[Wikitech-l] Re: Why is DL/DD (rather than CSS) used for indented
	text?

body:
Timwi wrote:

> Our current list syntax is defined in such a way that the asterisk at
> the beginning of several lines sometimes represents a single list item
> (which contains a list inside it); do you regard that as "strange"
> too? I am perfectly fine with it, even though it is fundamentally
> different from XML.  I say, let us define the ":" syntax in such a way
> that several consecutive lines beginning with ":" constitute the
> correct markup for a poem.  It is certainly better (and more aesthetic
> in the wiki text) than "<br>".

These sorts of things are inconsistent with the usual definition of a
paragraph in wikitext, which is "linebreaks don't matter".  Bizarrely,
if you took a legal wikitext paragraph, and put a ':' in front of it,
you wouldn't get an indented paragraph (which is what you'd expect to
get) unless the entire paragraph was written on one line.

-Mark


from_name: Brion Vibber

references:
<chi9tu$vv8$1@sea.gmane.org>
	<413CC55F.30307@pobox.com>	<chipdj$13t$1@sea.gmane.org>
	<413CEB1A.7010806@pobox.com>	<chirl1$5b1$1@sea.gmane.org>
	<3585b2e1040906192050b31ba1@mail.gmail.com>

body:
Hunter Peress wrote:
> Recent Changes.php and user_contributions code are too similar. Schema
> needs to be changed to support  both of these features running off
> almost the same code no ?

Recentchanges is distinct for a couple of reasons: first, it uses a
summary table of the last few days' updates to speed things up rather
than pulling from cur and old. Second, it includes log entries (upload,
deletion, protection, etc). In the past these have been
specially-treated wiki pages -- automatic updates to them didn't save
anything in the old table (who want ten thousands revisions of an
ever-growing log page?) so a full set of information would not appear
when pulling data from cur+old, but every update is included in the
recentchanges table.

In 1.4 there's now a logging table which records all those log entries,
and those are listed also in the recentchanges table. Log entries won't
show up in Contributions (nor do they right now unless by a stroke of
chance you're the most recent person to have changed anything recorded
in that log).

> Along these lines, if the above consolidation of code is not good,
> then some of the same schema changes need be done so that  the diff
> (not the history of the page as it is now) is linked directly off the
> user_contributions page.

That's already in 1.4 CVS.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040906/8c43d24b/attachment.pgp>


from_name: Eckhart Wörner

subject: [Wikitech-l] off-line GPL program

body:
Hello Lu?s,

Lu?s Fernando schrieb:
> So now I've 2 questions, because I'm new here:
> 1) Was it already discussed here? Is there already something in
> progress? (maybe I should have asked that before writting everything I
> did ;) )

Well, I am already developing a Wikipedia offline reader using the XUL
framework [1]. But I'm still waiting for some features for the reasons
shown below.

> 2) What do we have?
>    a) How is wikipedia database organized?
There are two database tables - the "cur" and the "old". The cur table
stores the current version of an article, the old table stores each
previous version. Since there is no revision id attached to an article
version in the cur table, you can't point to a specific article version
- see [2].

>    b) Can we have access to the "raw database" so the program could
>    use it?

There is a thread in this mailing list concerning this question ([3]).

> 3) Who's with me? ;)

Probably me. ;-)

Eckhart

--
[1] http://en.wikipedia.org/wiki/XUL
[2] http://bugzilla.wikipedia.org/show_bug.cgi?id=181
[3] http://mail.wikipedia.org/pipermail/wikitech-l/2004-August/024770.html


from_name: John Lee

subject: [WikiEN-l] Re: VfD is broken

references:
<BAY16-F17vaTMeiefq5000181b1@hotmail.com>	<413B23C9.3030609@yahoo.com>
	<chfkuf$n0t$1@sea.gmane.org>

body:
Timwi wrote:

> John Lee wrote:
>
>>> 4. Articles about "non-notable" stuff does not hurt Wikipedia. Since
>>> noone cares about the stuff, noone will link to it and noone will
>>> search for it and NOONE will ever see it!
>>
>>
>> A keyword search can easily bring up non-notable articles. When
>> somebody sees an entry resembling a blog posting, what will they
>> think of Wikipedia?
>
>
> They will think "Whee! There's stuff to improve!" and become a
> contributor.

That happens like what - how often? Most people I know would just close
the window and Google the topic elsewhere. They might think, "An
encyclopedia about somebody's breakfast? Ok...."

>
>> If it's a notable article, it will be improved anyway.
>
>
> An article goes through VfD for how long? 5 days? 7 days? Hardly
> enough to give people time to improve a bad article on an obscure topic.
>
Those interested will know that it is on VfD. If it is arcane, there's a
chance no current Wikipedian knows about the subject yet, in which case,
I say it's better safe than sorry to delete. A better article can be
recreated later.

>> Honestly, if I had to pick between deleting a (hypothetical) article
>> on Ronald Reagan which is full of unrelated nonsense about doing
>> drugs or keeping it in the hopes somebody would improve it, I'd do
>> the former without skipping a beat.
>
>
> Of course, that is an extreme example. How about Anthere's recent
> example:
>
>     The '''medlar''' is a [[fruit]].
>
> Admittedly, this article is:
> * short
> * incomplete
>
> However, it is also:
> * factually accurate
> * NPOV
> * actually something I didn't know!
>
> Hence, it is useful.

I would vote keep and put on cleanup. It is not rubbish.

>
>> Having an article only gives the impression to readers that we
>> tolerate junk.
>
>
> Which is good.  If we give the impression to readers that we tolerate
> only full-grown complete articles, we will detract contributors who
> are perhaps not quite as good a writer as they would like to be.

I think you misunderstood. I was trying to say that at the very least,
we should prove we have some credibility by at the very least having
articles on notable/verifiable topics only. If there's good content but
bad formatting, it's for cleanup. If it's just non-notable crap, it
shouldn't be on Wikipedia.

>
>> I'd rather receive complaints from readers that we don't have an
>> article on Ronald Reagan than complaints that our article of Ronald
>> Reagan is useless, which in turn will lead to questioning the
>> credibility of other innocent articles.
>
>
> The missing of an article on Ronald Reagan would similarly lead to
> questioning the completeness of other innocent articles.

Better to have no information instead of misleading information.

>
> Now, please don't get me wrong; I am not a complete inclusionist,
> either.  For example, I too don't think it would make sense to have a
> separate article on every single school anyone ever went to. However,
> I have been wanting to contribute to advanced topics in Computation
> Theory and Complexity Theory, but have been a bit hesitant to do so
> because some of the things I want to write about would start out as
> simple stubs and risk being deleted.
>
I'd encourage you to do so. I started [[resort]], which is still a stub
after close to a year, and it was VfDed in less than a few hours, yet
survived. Most Wikipedians aren't extreme deletionists. I don't vote to
delete stubs or substubs, just patent nonsense.

John Lee
([[User:Johnleemk]])


from_name: Hunter Peress

references:
<chi9tu$vv8$1@sea.gmane.org> <413CC55F.30307@pobox.com>
	<chipdj$13t$1@sea.gmane.org> <413CEB1A.7010806@pobox.com>
	<chirl1$5b1$1@sea.gmane.org>

body:
Recent Changes.php and user_contributions code are too similar. Schema
needs to be changed to support  both of these features running off
almost the same code no ?

Along these lines, if the above consolidation of code is not good,
then some of the same schema changes need be done so that  the diff
(not the history of the page as it is now) is linked directly off the
user_contributions page.

On Tue, 07 Sep 2004 01:25:33 +0200, Ashar Voultoiz <thoane at altern.org> wrote:
> Brion Vibber wrote:
> > Ashar Voultoiz wrote:
> >> With the millions of revision I am not sure if 'revisions' will be
> >> fast maybe add another table wich cache the data like:
> >>
> >> lastest(article_id, revision_id)
> >>
> >> Where:
> >>   'lastest.article_id' is UNIQUE
> >>   'lastest.revisions_id' point to 'revisions.id'
> >
> >
> > Why have a separate table? Put that in the page table (equivalent of cur
> > without the revisons themselves).
>
> But the page table will have millions of entries (as it track all
> current articles and past revisions). Maybe it will slow down queries ?
> Or maybe it's what indexes are for, aren't they ?
>
> >> Can't it be configured per database in mysql ? Looks like we can use
> >> collation for this purpose:
> >
> > That's all MySQL 4.1 stuff, which is still in beta. We can't rely on any
> > of it being present.
>
> Maybe we can wait for MySQL 4.1 to become stable and well spread ... Not
> sure if we can wait several months though.
>
> --
> Ashar Voultoiz, learning new things with Brion
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


body:
Hello !

Sometime ago there was a lot of discussion about a database shema
change. I am wondering if that's a dead-end horse or if we can
eventually start discussion again and eventually got the changes in for
version 1.4 ?

I have some ideas of new fields that can help, and probably a friend who
is a database designer who is willing to help review our shema (although
he is writing a book actually).

Or maybe we just add new tables and new fields whenever we want new
features, but I am not sure it is the best solution.

--
Ashar Voultoiz


subject: [WikiEN-l] VfD is broken

body:
Eric B. and Rakim wrote:

>> > 1. There is no reason to delete any of the pages there at all.
>> > Copyvios already has a special page. And there is also already
>> > candidates for speedy deletion and simple vandalism that is deleted on
>> > sight.
>>
>> Please provide examples. Speedy deletions are for contributions that
>> don't make sense. VfD is for those that do but aren't encyclopedic.
>
>
> Examples of what? Examples of what would happen in the theoretical
> situation that articles wasn't deleted due to VfD?

Examples to backup your reason for claiming that there is "no reason to
delete any of the pages there at all". How do we deal with imaginary
nonsense? Speedy deleting them won't work, as then we'll be deleting
articles which look fake, but could be otherwise. We need the discussion
on VfD to collectively improve and research the articles' topics.

>> > 4. Articles about "non-notable" stuff does not hurt Wikipedia. Since
>> > noone cares about the stuff, noone will link to it and noone will
>> > search for it and NOONE will ever see it!
>>
>> A keyword search can easily bring up non-notable articles. When somebody
>> sees an entry resembling a blog posting, what will they think of
>> Wikipedia?
>
>
> Really? Looking at VfD I couldn't find very many articles that
> probably had been indexed by Google.  But the article Puchland that
> most on the people on VfD wants to delete ought to have been indexed
> because it has been there since 2003.
>
> Google can't bring it up somehow. Yahoo can, but wont unless the
> search is specific ("israel forum" works i.e.). And if I made such a
> search, I'm sure I would be more satisfied with a decent description
> of an online-forum than no hits at all.
>
> Hypothetically, if every person that lists an article on VfD also
> listed how they encountered the article, what would be the most common
> methods of encountering for those articles that ALSO are deleted? I
> guess:
>
> 1. Recent changes 90%
> 2.  Checking user contributions of specific users. 7%
> 3. Links from specific user's pages. 3%
>
> And maybe once in a blue moon someone would say "encountered it while
> searching for something else". Wikipedia is very good at organising
> itself automagically and that is why VfD is not needed.
>
> If there was a function that counted page hits this assertion could be
> proven. Especially if it only counted page hits from users that are
> not logged in. Then maybe people would realise it is not worth the
> time, effort and flames to save a handful of people from visiting a
> page that they might or might not wanted to see.
>
> Btw, if you are sure that there is a method that "can easily bring up
> non-notable articles", please explain what it is. Lets also say that
> "easily" in this context means:
>
> 1. Does not involve the "Wikipedia:" or "Special:"-namespace.
> 2.  A sucess rate of 5% (debatable) or higher.
> 3. The method is not restricted to a certain area of Wikipedia.
>
> Tricky, isn't it? :)

Let's say somebody writes an article about "Sexual promiscuity of John
Kerry" and that makes up bogus claims that he has raped several women
and had extramarital relations with a secretary. The Googlerank will
ensure it is ranked highly, as you can bet bloggers will be talking
about it. This in turn will lead to questioning of our credibility. The
page isn't a copyvio. It's not patent nonsense, because it's prose that
makes sense, so it doesn't fit the speedy delete criteria. What do we do
with the article? All it takes is for one person to complain to a major
news agency or even just Slashdot, and our whole reputation goes down
the drain.

>
>> > 6. And cause those articles are never read by anyone it doesn't hurt
>> > to remove them from Wikipedia. But that's not why vfd is sabotaging
>> > Wikipedia. It is because 50-80% of the articles listed there should
>> > not and will not be deleted. The authors of those articles are forced
>> > to defend their work to people that just haven't got a clue and never
>> > will. Then they have to engage in more pointless arguing with the
>> > deletionists just to prevent them from destroying Wikipedia!
>>
>> Please provide examples. A good deal of the time, the authors don't
>> defend their works. Contrary to common belief, very few people who visit
>> VfD are rabid deletionists who will vote delete for an arbitrary reason.
>> Most of us actually take the time to Google the article's subject, etc.
>> The author doesn't have to do much. I've VfDed a lot of articles in my
>> time, and a lot of them were kept, not thanks to the author's
>> intervention, but the research of other kind-hearted Wikipedians.
>
>
> http://en.wikipedia.org/wiki/Vfd#Maine_Mall_--_Add_to_this_discussion
> http://en.wikipedia.org/wiki/Vfd#Gay_Nigger_Association_of_America__--_Add_to_this_discussion
>
> http://en.wikipedia.org/wiki/Vfd#Pyle_MS_--_Add_to_this_discussion
> http://en.wikipedia.org/wiki/Vfd#Dan_O.27Connor_--_Add_to_this_discussion
> http://en.wikipedia.org/wiki/Vfd#Most_visited_websites_--_Add_to_this_discussion
>
>
> etc...
>
> 1. A lot of time was wasted by the persons listing those pages.
>
> 2. Some voluntarily wastes their time by voting. Their life, their
> problem.
>
> 3. VfD's problem is that XX% of those that voted "keep" did not do it
> because they enjoy wasting time but because they feel that they are
> forced to defend good articles from being destroyed. Atleast poor
> "anthony (see warning)", who voted "keep" 38 times, didn't really seem
> to enjoy the process.

Huh? Are you saying that everyone who votes keep on VfD is pushing their
own agenda of inclusionism? We must presume "delete-worthy until proven
innocent", because otherwise Wikipedia will proliferate with
unverifiable articles. Those articles were listed on VfD so a wider
audience than those who visit a Talk page can research the article.
There's an off-chance, for example, that somebody might be a Maine
historian and thus know about Maine Mall's significance. It's unlikely
he/she would stumble across Maine Mall though. VfD is for drawing
people's attention to articles. It's not a threat as anthony claims -
it's more like asking, "Does this article merit inclusion?" IMO, anthony
is just making himself look bad and acting detrimentally to Wikipedia if
he won't improve articles without certain conditions that don't even
affect his ability to edit, as he claimed in the Maine Mall discussion.

>
>> > 7. The Wikipedia concept is that anyone can edit a page and that only
>> > those who edits a page gets to determine what information goes into a
>> > page. Its like "do it yourself cause you can't tell anyone else what
>> > to do cause there is no way to force them to do it." Now that concept
>> > doesn't work with vfd cause someone can say "uuuh.. delete unless it
>> > is improved in a week.". That person basically forces those who care
>> > about the article to write what they know about it or it will be
>> > killed. It is not fair at all.
>>
>> Well, honestly, tell me, what is there to write about someone's smelly
>> socks? If it's a notable article, it will be improved anyway. Are you
>> suggesting we tolerate garbage just because the garbage's topic is
>> something notable? Honestly, if I had to pick between deleting a
>
>
> 1. You believe there is a defintion for what garbage is. There is not.
> What you call garbage is what others call stubs.
>
> 2. If we didnt allow garbage, Wikipedia wouldn't be what it is. If we
> do not continue to allow garbage, Wikipedia will not grow.

What I call garbage is an article about Marilyn Monroe full of prose
that isn't an obvious speedy, yet contains lies fabricated out of
full-cloth, i.e. "Marilyn Monroe was a Soviet spy and sold American
secrets to the Russians during the Cold War." It's a stub, yes, but it's
a useless stub because it's completely unverifiable and almost certainly
false. Are you saying we keep this so Wikipedia will grow?

>
>> (hypothetical) article on Ronald Reagan which is full of unrelated
>> nonsense about doing drugs or keeping it in the hopes somebody would
>
>
> Is this a straw man? Anyway, I find it easier to do: click edit,
> select all, press delete, write "Ronald Reagan was USA:s president
> 1984-1992", press save than to do: search for a non-existant article
> about an American president, click edit, write the same stuff, press
> save.

That's what I would do, but that was just an example that's easy. What
about a Czech actor on whom nothing can be found in Google (except for
Czech-language pages)? What if the article is full of allegations that
"[the actor] is an alien from Mars and has been scientifically proven to
have no penis."? Do we delete it, or do we let it sit and wait for a
Czech to improve it? I seriously hope somebody who can speak Czech would
improve the article during the article's VfD listing, but presuming they
don't, I say we delete.

>
>> improve it, I'd do the former without skipping a beat. Having an article
>> only gives the impression to readers that we tolerate junk. I'd rather
>
>
> We do tolerate "junk". And if you mean that VfD is somehow effecting
> the "junk"-level of Wikipedia then you are wrong.  There are so many
> articles that could have been listed on VfD but aren't just because
> there are so many articles that is added each day.

Examples please. At the very least, provide statistics. Obvious VfDs and
speedys are much easier to catch compared with catching vandalism. If
you were talking about vandalism, you'd have a case, but this is VfD.

>
>> > 8. As an example:
>> >
>> > NASA Project Gemini Familiarization Manual -- Add to this discussion
>> >
>> > The flight manual for the Gemini spacecraft - excellent Wikisource
>> > material. Transwiki and delete --Rlandmann 00:33, 2 Sep 2004 (UTC)
>> >
>> >    * Transwiki and delete. Geogre 00:54, 2 Sep 2004 (UTC)
>> >    * Transwiki and delete. GeneralPatton 00:55, 2 Sep 2004 (UTC)
>> >    * Have moved article to Wikisource. Please Delete DarylC 2 Sep 2004
>> >
>> > Which of these comments is a total waste of everyones time?
>> > Rlandmann's is because despite the fact that he had an excellent idea
>> > he was to damn lazy to carry it out himself as he easily could. Geogre
>> > and GeneralPatton just seem to show off their excellent talents in
>> > agreeing. Finally, DarylC, the primary author of the page actually
>> > does some work and moves the article. Very good DarylC.
>> >
>> > The problem with this is that atleast thousand people have been forced
>> > to read this meaningless junk because Rlandmann didn't place the
>> > suggestion to transwiki on the article's talk page which would have
>> > been the right thing to do.
>>
>> You are missing the whole point of VfD. The point is to ask a wide
>> audience - that "thousand people" - "Is this article worth keeping, or
>> do we move it elsewhere/delete it?". The point of VfD is consensus.
>> Placing the request on the Talk leads to a very very limited audience -
>> how many Wikipedians read Talk pages on a regular basis? And unitarily
>> moving it is even worse.
>
>
> 1. Rlandmann asked thousand people if NASA Project Gemini
> Familiarization Manual should be "transwikied"... 3 people responded.
> Doesnt seem very efficient.
>
> 2. To WHO does it matter what happens with NASA Project Gemini
> Familiarization Manual? To the ones who read that article's talk page.
>
> 3. If someone gets a consensus consisting of the article's talk page's
> audience which includes the primary author of the page. Wouldn't then
> that consensus have as much if not more weight than a consensus
> received from VfD?

1. Are you suggesting we have a thousand votes for every discussion? To
me it sounds like you're just grasping for straws to back up your
argument against VfD. Those three who responded are likely those who had
the time to research the article sufficiently on Google, or know
something about it, but wouldn't have known about the article's existence.

2. No. It matters to those who know about the article's topic, but don't
know the article exists. VfD informs them that the article exists, and
that somebody would like to know what others think about the article's
encyclopedicness.

3. No. IMO, VfD provides a wider audience, which is key.

>
>
> To those who believe that VfD is flawed, could this idea or some
> alteration of it be a way to improve it?
>
>> > 10. The only way to fix vfd would be to allow people to cast the
>> > identical vote on range of articles listed there.  Then you would be
>> > able to vote "keep doesn't hurt wikipedia" (or whatever) on each and
>> > every article.
>
It'd be useful in rare cases, but overall, I think it'd just lead to
mass voting by rabid deletionists/inclusionists.

John Lee
([[User:Johnleemk]])


from_name: Michael Snow

subject: [Foundation-l] Update on status of press release

body:
Our upcoming press release about the 1,000,000-article milestone for
Wikipedia is approaching completion. I just wanted to keep everyone
informed who's helping with the project. Based on the current rate of
article creation, we're still looking at September 15 as the date for
the millionth article, and we plan to starting sending the press release
that day.

I anticipate some changes still need to be made - for example, a new
quote from Jimbo instead of recycling the one from the last press
release. But I plan to push on and hopefully have a final text ready in
the next 24 hours or so. Anyone who still has input they want to offer,
please don't hold back; I would love to have your help, but we need to
freeze the text for the translation process very soon.

Thanks also to the translators, many of whom have already started
working on the draft text. I will announce on this list again when the
text is finalized, so you can update translations to that version.

--Michael Snow


body:
Ashar Voultoiz wrote:

> Hello !
>
> Sometime ago there was a lot of discussion about a database shema
> change. I am wondering if that's a dead-end horse or if we can
> eventually start discussion again and eventually got the changes in
> for version 1.4 ?
>
> I have some ideas of new fields that can help, and probably a friend
> who is a database designer who is willing to help review our shema
> (although he is writing a book actually).
>
>
> Or maybe we just add new tables and new fields whenever we want new
> features, but I am not sure it is the best solution.
>
When there is room for some new database tables, I am working on some
idea's for wiktionary. These tables would be relational.

I am thinking about these tables and relations

Word table
Language table
Meaning table
WordType table
Translation table
Idiom table
Synonym / Antonym  etc table

A Wiktionary page has one or more Words
A Word has a Language
A Word has one or more Meanings
A Meaning has a WordType
A Word has one or more Translations
A Translation may have a Word in another Language, and a defenition in
the same Language.
Synonym etc has another Word in the same Language and an indication what
kind of relation exists.

These are the initial ideas that I have, I am still toying with them. I
think they will allow one database to contain all words in all
languages. It will result in a more integrated wiktionary whereby
efforts will be a benefit within the whole wiktionary environment.

NB At this stage I am thinking about structure; user interface I have
not yet considered the user interface. The user interface has to be
intuitive and has to accomodate several languages.

Thanks,
    GerardM


subject: [Wiktionary-l] Re: [Wikitech-l] Database shema : let's start the fun


from_name: Kurt Jansson

subject:
[Foundation-l] ticket system and newsletter software (was:
 Secretlondon's attacks on Jimbo Wales)

body:
Erik Moeller schrieb:

> A ticket system would offer quite a few advantages over a simple mailing
> list: 1) no duplicate effort, 2) no need for spamming your inbox, just do
> everything through a single web interface, 3) easily expand the team of
> "agents", with different categories and associated user rights.
> Essentially a Bugzilla for emails.

We've been talking about a ticket system in the German press team, and most
people support it's use, though it would be less open. But it would be less
chaotic, too. ATM some questions get answered twice, others might be overlooked
between all the spam and viruses (especially a virus filter would be a big (!)
improvement for the people answering the info at wikipedia.de mails).

> This system here looks interesting:
> http://otrs.org/
> http://otrs.org/screenshot/

Another system which has been mentioned is
http://www.bestpractical.com/rt/

A newsletter software would also be quite useful, especially for sending out
press releases. We could use mailman, but a specialized software would do the
job much better. PHPlist seems to be popular:
http://tincan.co.uk/phplist

Kurt


subject:
[Wikitech-l] ticket system and newsletter software (was:
 Secretlondon's attacks on Jimbo Wales)


body:
Also,  a better way to compress the old files is to take  old_text for
 some number N revisions of an article and compress those together.
Similar idea is storing diffs with a full file every N revisions but I
think compression is easier.

Lots of work will go in to determining N since theres many different
size files and the 30 second limit has to be respected (unless the 30
second rule can be voided for these retrievals).

Also, logarithmic type behaviour should be applied to the size of N
with respect to date of edit and # of edits over blocks of time. eg:
compress as blocks less (or not at all) for newer revisions.

Finally, plenty of work can be done to make this work with the cache.

PS, this will save a lot of space I think.

A simple  and quick test would be to decompress old_text from an
entire small-wiki and compress a few different ways eg (try 5
revisions per block, 20, 50....)

Another good thing to see is analysis of  where the bell (bulk) of a
wiki lies over all revisions. Probably, its in  the popular articles,
which is why I think block compressing is good.

On Mon, 06 Sep 2004 19:35:00 -0700, Brion Vibber <brion at pobox.com> wrote:
> Hunter Peress wrote:
> > Recent Changes.php and user_contributions code are too similar. Schema
> > needs to be changed to support  both of these features running off
> > almost the same code no ?
>
> Recentchanges is distinct for a couple of reasons: first, it uses a
> summary table of the last few days' updates to speed things up rather
> than pulling from cur and old. Second, it includes log entries (upload,
> deletion, protection, etc). In the past these have been
> specially-treated wiki pages -- automatic updates to them didn't save
> anything in the old table (who want ten thousands revisions of an
> ever-growing log page?) so a full set of information would not appear
> when pulling data from cur+old, but every update is included in the
> recentchanges table.
>
> In 1.4 there's now a logging table which records all those log entries,
> and those are listed also in the recentchanges table. Log entries won't
> show up in Contributions (nor do they right now unless by a stroke of
> chance you're the most recent person to have changed anything recorded
> in that log).
>
> > Along these lines, if the above consolidation of code is not good,
> > then some of the same schema changes need be done so that  the diff
> > (not the history of the page as it is now) is linked directly off the
> > user_contributions page.
>
> That's already in 1.4 CVS.
>
>
>
> -- brion vibber (brion @ pobox.com)
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>
>


subject: [Wikitech-l] Re: ticket system and newsletter software

body:
Kurt Jansson wrote:
<snip>
> Another system which has been mentioned is
> http://www.bestpractical.com/rt/

I highly recommend RT. We used it to manage several mailing list with a
traffic of about 3000 mails daily.

--
Ashar Voultoiz


from_name: Sj

subject: [WikiEN-l] Re: Accuracy Heuristics

body:
On 06 Sep 2004 11:26:00 +0200, Erik Moeller <erik_moeller at gmx.de> wrote:
> David-
>
> choose high ratings. These articles then attain a false notion of being
> authoritative. Similarly, controversial articles might never gain such
> status because some people don't like their content.

Yes, an abiding problem with ratings.  I think ratings / flags are
mainly useful as a tool for isolating targets for cleanup, and as a
distributed vehicle for VfD-style comments (it would be nice to
separate out as metadata the review/VfD/controversial status of an
article) .  As for source annotation and fact checking :

> There's an interesting project going on here:
> http://en.wikipedia.org/Wikipedia:WikiProject_Fact_and_Reference_Check

Indeed!

> "??..??" means that this part of the article needs a source. Using CSS,
> all passages marked with "??" could be highlighted or not, depending on
> personal preferences.
>
> or like this:
>
>  ^+The inscription is approximately 15 metres high by 25 metres wide
>  [[Source:Behistun, p.84]]

Or [[Source:Behistun-1992|p. 84, see image caption]], where the
source: reference produces the base of the footnote/reference, and the
rest is specific information to be added at the end of the reference.

> Using a method like this, we have real semantic information about
> individual facts and can easily make statements like
> * 80% of the facts in this article have sources
> * 40% of the sources we cite are of high quality
> * Source X is used in Y articles

also
* 20% of articles with <<NPOV>> tags reference more than one source
* average # of (marked) significant verifiable facts per article

> Of course these claims themselves could be faked. But together with
> stable-revision flagging and a consensus-based peer review process

Well, this gets us closer to a zero-knowledge proof of article validity and
user reliability, as one can very directly and specifically check the accuracy
or sincerity of another's work.

+Sj+


from_name: Anthere

subject: [Wikipedia-l] Re: Wikipedia on the BBC website !!

body:
Nicolas Weeger a ?crit:
> Gerard Meijssen a ?crit :
>
>> http://news.bbc.co.uk/2/hi/technology/3624384.stm
>>
>> :)
>>
>>
>> Thanks,
>>    GerardM
>
>
> Nice, except for that:
>
> They also have around 300 volunteer system administrators who oversee
> entries.
>
> which is plain wrong since sysops don't know everything :)
>
> Nicolas Ry
> o

I guess it is also wrong there are only 300 sysops on the project :-)

But great article otherwise :-) Thanks Jimbo.


body:
Gerard Meijssen wrote:
<snip>
> When there is room for some new database tables, I am working on some
> idea's for wiktionary. These tables would be relational.
>
> I am thinking about these tables and relations
>
> Word table
> Language table
> Meaning table
> WordType table
> Translation table
> Idiom table
> Synonym / Antonym  etc table
>
> A Wiktionary page has one or more Words
> A Word has a Language
> A Word has one or more Meanings
> A Meaning has a WordType
> A Word has one or more Translations
> A Translation may have a Word in another Language, and a defenition in
> the same Language.
> Synonym etc has another Word in the same Language and an indication what
> kind of relation exists.
>
> These are the initial ideas that I have, I am still toying with them. I
> think they will allow one database to contain all words in all
> languages. It will result in a more integrated wiktionary whereby
> efforts will be a benefit within the whole wiktionary environment.
>
> NB At this stage I am thinking about structure; user interface I have
> not yet considered the user interface. The user interface has to be
> intuitive and has to accomodate several languages.
>
> Thanks,
>    GerardM

Hello,

I highly believe that wiktionary should never have been made under
MediaWiki software. We clearly should have create a software to manage a
multilangage dictionary with some wiki capabilities instead of using a
wiki software and try to add features.

The big problem I see, is that we will have to do a lot of development
for the sole purpose of wiktionary whereas MediaWiki is mostly use for
others purpose such as "a wiki website". At least that's how I see
MediaWiki.

I am not sure what is the exact status of MediaWiki ie:

1/ yet another wiki software, eventually used by wikipedia
2/ the WikiMedia projects interface that eventually can be used as a
Wiki website.

If case is #1, let's start new features dedicated to wiktionnary. I am
sure your proposal is a good start.

If case is #2, we might want to fork MediaWiki and build a new project
that could be called "Wiktionary" or something like that with features
that feets the need of a dictionnary but will be useless for a standard
wiki. :o)

-------------------

Now let's have a look at a possible solution.

We can code a metadata system that will allow users to specify their own
tables. When editing an article, a form can be displayed under the text
like:

[Meaning ]    [   ]
[WordType]    [   ]
[Translation] [   ]
[Idiom]       [   ]
[ADD NEW]

[SAVE]

The [ADD NEW] button could then be used to add another field like "synonym".

In the database it could be saved in a table like:

   [Article ID | MetaTag     | MetaValue ]
   ---------------------------------------
   |        25 | Meaning     | something |
   |        25 | WordType    |      noun |
   |        25 | Translation |    <blob> |
   |      3422 | Meaning     |   another |
   ---------------------------------------

The same shema can possibly be used for the template system. Editor will
just have to add the template he want to use like {{city_template}} on
saving then reediting it will show the field available in the template :

  [City name]   [New York ]
  [Population]  [9,245,542]
  [Census year] [     2000]

That can then be saved the same way:
   [Article ID | MetaTag     | MetaValue ]
   ---------------------------------------
   |        39 | City Name   |  New York |
   |        39 | Population  | 9,245,542 |
   |        39 | Census year |      2000 |
   ---------------------------------------

That might be a way to rething the template system and allow an
implementation of Gerard idea with even more capabilities (as editors
can easily add their own fields / tables instead of waiting for
developpers to code things).

cheers,

--
Ashar Voultoiz