subject:
[Wikipedia-l] Re: maybe time for a document project,	sometime
	in the near future?

body:
Karl Eichwalder wrote:
> Steve Vertigo <utilitymuffinresearch at yahoo.com> writes:
>>Its not under the Wikimedia trademark thats what.
>
>
> I thought "wiki" is about dynamic texts, but printed PD books are static
> (okay, you can tweak the layout ad infinitum, but that's something
> different).

The thing that would make a Project Sourceberg worthwhile is wiki-style
annotation of the texts.

Annotations could include cross-links to Wikipedia and Wiktionary as
well as within the document, and we could have a relatively sane system
for linking from Wikipedia and Wiktionary to *particular spots* in the
texts, for instance to provide context for a quote.

Now, that would require some special coding if we want to make it a
clean system (ie, one where visitors can edit annotations but not
original text); or one could just dump Gutenberg's ASCII texts straight
into giant wiki pages and do it all by hand.

-- brion vibber (brion @ pobox.com)


list: wikipedia-l

source: pipermail-mbox

from_name: Steve Vertigo

subject:
[Wikipedia-l] Re: maybe time for a document project,
	sometime in the near future?

body:
Annotations are a brilliant idea. Would simple links
in a page break the concept of a document?  Text in
view mode doesnt copy the links at all, so it should
be fine.

But more basic than that, however would be that people
who are in the process of digitizing a useable book or
other document can do so in the rough, allowing some
minor and methodical prepwork to be done in the wiki
world.  People with similar copies can collaborate,
like Bittorrent transfers. (not to make any
comparisons ;)

Heck -- it could replace the way Gutenberg does its
work (well... theyve got a 25 year head start, but...
) and replace Gutenberg altogether -- which would mean
that they would be free from the confines of their
current existence and take that cruise theyve been
talking about.

-S-

--- Brion Vibber <brion at pobox.com> wrote:
> Karl Eichwalder wrote:
> > Steve Vertigo <utilitymuffinresearch at yahoo.com>
> writes:
> >>Its not under the Wikimedia trademark thats what.
> >
> >
> > I thought "wiki" is about dynamic texts, but
> printed PD books are static
> > (okay, you can tweak the layout ad infinitum, but
> that's something
> > different).
>
> The thing that would make a Project Sourceberg
> worthwhile is wiki-style
> annotation of the texts.
>
> Annotations could include cross-links to Wikipedia
> and Wiktionary as
> well as within the document, and we could have a
> relatively sane system
> for linking from Wikipedia and Wiktionary to
> *particular spots* in the
> texts, for instance to provide context for a quote.
>
> Now, that would require some special coding if we
> want to make it a
> clean system (ie, one where visitors can edit
> annotations but not
> original text); or one could just dump Gutenberg's
> ASCII texts straight
> into giant wiki pages and do it all by hand.
>
> -- brion vibber (brion @ pobox.com)
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikipedia.org
>
http://mail.wikipedia.org/mailman/listinfo/wikipedia-l

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


list: wikitech-l

from_name: Daniel Mayer

subject: [Wikitech-l] Small change in "print page" template needed

body:
Brion wrote:
>Fixed.

Thank you Brion! I guess it was my mistake to make the original request while
you were on vacation... One minor thing though; If it wouldn't be too much
trouble, then it would be great if the "Retrieved from" url text was an
active link. http://www.wikipedia.org/w/wiki.phtml?title=Foo is also a bit
messy;  http://www.wikipedia.org/wiki/Foo would be better (this isn't that
important though).

>'Printable mode' really should be replaced with a
>style sheet, though. It'd save a lot of trouble in the
>code, and people could just hit "print" from the
>regular page and get decent-looking output.

That sounds like a great idea to me.

-- Daniel Mayer (aka mav)


body:
Karl Eichwalder wrote:
>This is of dubious value.  Why don't you trust in
>the reader use wikipedia's search feature?

Uh? The same argument can be made about links in Wikipedia articles to other
Wikipedia articles. Easily accessible links is the whole point of HTML and
the web. Use the Wikipedia search feature indeed.

-- mav


from_name: Brion Vibber

body:
Daniel Mayer wrote:
> Thank you Brion! I guess it was my mistake to make the original request while
> you were on vacation...
 > One minor thing though; If it wouldn't be too much
> trouble, then it would be great if the "Retrieved from" url text was an
> active link. http://www.wikipedia.org/w/wiki.phtml?title=Foo is also a bit
> messy;  http://www.wikipedia.org/wiki/Foo would be better (this isn't that
> important though).

Yeah, it kinda sucks. Right now what it does is it takes the exact URL
you gave it, in this case
http://www.wikipedia.org/w/wiki.phtml?title=Foo&printable=yes, and
removes the &printable=yes.

I've checked a fix into unstable to use the canonical URl for the page,
but hypothetically it may not work in all circumstances, like if you
want a printable version of an old page revision; it wouldn't include
the version number, and we might want that.

Running on test.wikipedia.org.

A related problem, which I dunno how to usefully fix, is that URLs for
pages in non-latin charsets are really REALLY ugly and long. Between
UTF-8 and ASCII-based URL encoding, one character baloons to six or even
nine chars of incomprehensible digits and percent signs. It doesn't much
matter when it's just between your browser and your bookmark file, but
cut-n-paste is painful, and printing is a real problem.

A moderately long title may not even fit within the width of a printed
page, like:

http://ru.wikipedia.org/wiki/2003_%D0%9A%D1%80%D1%83%D0%BF%D0%BD%D0%B0%D1%8F_%D0%B0%D0%B2%D0%B0%D1%80%D0%B8%D1%8F_%D0%B2_%D1%8D%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%BE%D1%81%D0%B5%D1%82%D0%B8_%D0%A1%D0%A8%D0%90_%D0%B8_%D0%9A%D0%B0%D0%BD%D0%B0%D0%B4%D1%8B

We could try to give the URLs without url-encoding (where possible), and
hope that the users are able to type all characters and they'll all be
sent in an encoding the wiki can decypher, but I don't know how reliable
this will be.

-- brion vibber (brion @ pobox.com)


list: textbook-l

subject:
[Textbook-l] [Wikipedia-l] Re: maybe time for a document project,
	sometime in the near future?

body:
Cross posted to Textbook-L

Brion wrote:
>The thing that would make a Project Sourceberg
>worthwhile is wiki-style annotation of the texts.

Yes! Just so everybody knows, we've been talking about annotation for the
Wikibooks project on Textbook-L. See "disappearing/reappearing column-side
notes," "public domain works with marginal notes" and "Re:
disappearing/reappearing column side-notes" at
http://mail.wikipedia.org/pipermail/textbook-l/2003-August/subject.html#start

Here is a hack of what that may look like:
http://www.wikipedia.org/upload/5/56/Sidenote-column.html

The current idea is to have <note> annotation </note> act as the actual
syntax.

>Annotations could include cross-links to Wikipedia
>and Wiktionary as well as within the document, and

Yep. What would really be neat is an optional java-script feature whereby
double clicking on any word in the text will bring-up the corresponding
Wiktionary entry. But that has to wait for Wiktionary to define many tens of
thousands more words first. I was also thinking of wikifying terms within the
public domain source text on Wikibooks to point to their corresponding
Wikipedia articles. Aside: A different color for cross-Wikimedia links would
be nice so that true external links (outside of Wikimedia) are
distinguishable from cross-Wikimedia links (I've suggested green before).

>we could have a relatively sane system for linking
>from Wikipedia and Wiktionary to *particular spots*
>in the texts, for instance to provide context for a quote.

We could use anchors for this now that Wikipedia, Wiktionary and Wikibooks all
have the latest and greatest MediaWiki installed.

>Now, that would require some special coding if we want
>to make it a clean system (ie, one where visitors can edit
>annotations but not original text); or one could just dump
>Gutenberg's ASCII texts straight into giant wiki pages and
>do it all by hand.

I'm not convinced that locking the public domain source text would be the best
option since there is a lot of formatting and Wikifying that can be done with
source text. However, I wouldn't mind blocking anons from editing source text
if that can be coded easily enough (since logged-in users are more likely to
know better about not changing the wording of the source text). But at the
very least, annotations should be open to edit by all.

Oh, and other Wikibooks modules should also have the ability to use the
annotation feature (such as textbooks). So that is something to keep in mind
if/when the annotation system is being worked on.

-- Daniel Mayer (aka mav)


body:
Karl Eichwalder wrote:

>As long as resource problems at wikipedia.org
>are not resolved I'd rather vote not to add new
>projects.

Uh? Wikibooks already exists /and/ part of that project's goal is to annotate
and otherwise add value to public domain source texts. No new project needed.

-- Daniel Mayer (aka mav)


list: wikien-l

subject: [WikiEN-l] Votes for deletion

body:
Rick wrote:
>Anyway, the reason why I keep trying to bring this
>up is because this is a change in policy that was
>never discussed.  Why is it so wrong to make sure
>that everyone knows that this policy was made by
>one person without input from anyone else?

Because after I've answered your question by in one place, I discover you've
posted it in another. Then when I answer the SAME question there, I see that
you had already posted your question elsewhere (etc x 2). It would have been
REAL nice if you had asked the question in ONE place, got a few answers
(which told you EXACTLY what happended) and then state that you are going to
take the issue of policy update procedure to the mailing list. Now that would
have been the courteous thing to do.

-- Daniel Mayer (aka mav)


subject: [Wikitech-l] Print stylesheet

body:
tarquin wrote:
> There is at least one problem however:
> hidden URLs are written out in full in the generated printable version.
> There's probably CSS trickery that allows the HREF attribute to be
> appended to the A element, but.... it probably won't work in IE :(

Aye, but there's the next best thing:

wikistandard.css:
.exturl { display: none } /* redundant on screen */

print.css:
.exturl { display: inline } /* need in print */

html:
foo
(http://blah/)

Yes, lynx and Netscape 4 with JavaScript disabled will see extra URLs.
Tough.

> Incidentally, "Table of contents [showhide <javascript:toggleToc()>]"
> doesn't make much sense in print ... ;)

print.css:
#toc { display: none }

-- brion vibber (brion @ pobox.com)


subject: [Textbook-l] Wikimedia University; name poll

body:
OK, I've decided to buy either WikiU.org/.com or Wikiversity.org/.com in order
to reserve that domain name for the possible future Wikimedia superproject.

Please indicate your preferences here:
http://textbook.wikipedia.org/wiki/Wikibooks:Staff_lounge#Wikiuniversity

-- Daniel Mayer (aka mav)


from_name: james duffy

subject: [WikiEN-l] Votes for deletion

body:
>
>[[Wikipedia:Deletion policy]] seems to have sprouted the following
>language:  "
>
>When you list a page on Wikipedia:Votes for deletion that you think will be
>listed for the entire 7 days -- i.e., a page that won't be deleted
>immediately -- please place the following notice above the page's content:
>
>    ''This page has been listed on [[Wikipedia:Votes for deletion]]. Please
>see that page for justifications and discussion.'' ".
>And [[Wikipedia:Votes for deletion]] now says:
>
>"NOTE: Always indicate on the listed page itself that it is here. See
>Wikipedia:Deletion_policy#Listed_for_deletion_notice. If this is not done,
>then the page will not be deleted. "
>
>Now, I can't say that I DISAGREE with this policy (although I think that
>having to put this notice on every page to be deleted is a tad excessive),
>but when and where was this policy discussed?  Was it ONE PERSON who made
>the decision, UNILATERALLY, that nothing would be deleted unless his/her
>pet boilerplate was put onto the page in question?
>
>Such new policies need to be discussed, not just thrown out as a fait
>accompli.  Other sysops may just go ahead and delete pages without the
>boilerplate, and have the right to do so, since this "policy" is only one
>person's decision, and not the agreement of the users of Wikipedia as a
>whole.
>
>RickK
>
I agree. Who 'decided' this?

JT

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail


subject: [Wikipedia-l] Re: maybe time for a document project,

body:
sometime in the near future?
Date: Sun, 17 Aug 2003 01:54:14 -0700
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200308170154.14868.maveric149 at yahoo.com>
Status: RO
X-Status: Q
X-KMail-EncryptionState:
X-KMail-SignatureState:

Karl Eichwalder wrote:
>I still believe contents is more important;
>all these links, esp. these navigation links
>are superfluous.  A good search engine is
>all you need -- frankly, navigations links are
>a waste of resources (time and bandwidth).
>I admit, it nice to click around but going this
>way you usually will not find the info you are
>looking for.

Ah - a true believer in search engines. As with all true believers, there
isn't any point arguing with you.

--mav


subject: [Wikitech-l] Simultaneous edit conflict partial protection patch

references:
<bhkboe$ked$1@sea.gmane.org> <3F3DBA09.10604@pobox.com>
	<bhkiss$qm0$1@sea.gmane.org> <3F3DD2DA.4040801@pobox.com>
	<bhn2bl$hkj$1@sea.gmane.org> <bhn713$l4t$1@sea.gmane.org>

body:
I've just checked a patch into the unstable branch which changes the
order of save operations a bit in a way which should help protect
against the bug, without adding any transactions or locking or whathaveyou.

The UPDATE to cur is moved up before the INSERT, *and* its WHERE
condition is modified to include the timestamp of the old edit (which
we've been using to detect edit conflicts, after all).

We then ask MySQL how many rows it modified in the UPDATE statement. If
it's zero, we know that there was an edit conflict; we abort the rest of
the save operation and (if I've got it right; I haven't tested it in
actual conflict) show an edit conflict screen.

Patch affects Article.php, EditPage.php, DatabaseFunctions.php.
New code should be running on test.wikipedia.org now.

This isn't complete protection; there are probably scenarios under which
funny things can still happen. This also won't affect simultaneous page
_creation_, though that should be fixed by adding a UNIQUE KEY index on
cur_namespace and cur_title, so the second INSERT attempt would fail
instead of creating an inaccessible phantom entry.

Simultaneous edit scenarios, normal:

      A                B
SELECT cur
                  SELECT cur
UPDATE cur
                  UPDATE cur
                  [report conflict!]
INSERT old

      A                B
SELECT cur
UPDATE cur
                  SELECT cur
                  [report conflict!]
INSERT old

      A                B
SELECT cur
UPDATE cur
INSERT old
                  SELECT cur
                  [report conflict!]

Simultaneous edit scenarios, pathologically slow server:

      A                B
SELECT cur
UPDATE cur
                  [open edit _screen_]
                  SELECT cur
                  [start saving edit]
                  SELECT cur
INSERT old
                  UPDATE cur
                  INSERT old

This actually shouldn't be too wrong. Thread A would save the pre-A edit
into old, B would save A's edit into old, and the history should show
them all in the correct order, even if B'd insert to old actually
happened before A's, they're sorted by timestamp, not insert order and
will show correctly.

Updates of some of the other tables could conceivably end up out of
order or overwriting each other, though.

Simultaneous edit scenarios, pathologically fast editing:

      A                B
                  SELECT cur
                  UPDATE cur
                  INSERT old
SELECT cur
                  SELECT cur
UPDATE cur
[with same timestamp
  as B's previous edit]
                  UPDATE cur
                  [miss conflict due to
                   same-second timestamp,
                   overwrite A's edit]
INSERT old
                  INSERT old
                  [duplicate of B's previous edit]

That could probably be protected against by checking the cur_user_text
field as well as cur_timestamp.

-- brion vibber (brion @ pobox.com)


from_name: Karl Eichwalder

body:
Steve Vertigo <utilitymuffinresearch at yahoo.com> writes:

> Its not under the Wikimedia trademark thats what.

I thought "wiki" is about dynamic texts, but printed PD books are static
(okay, you can tweak the layout ad infinitum, but that's something
different).

> Plust you have to scroll through twenty pages of
> Gutenberg indicia just to start reading your file.
> And there  is no direct linking to files... and....

Yes, that's sometimes annoying.  By now there are search interfaces to
jump directly to file, though.  Once the first 10,000 text are done (end
of the year), they will focus usability issues and switching to XML.

--
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke at suse.de (work) / keichwa at gmx.net (home)               |   (*)/'(*)


body:
Daniel Mayer <maveric149 at yahoo.com> writes:

> Sorry, but some people don't care to read plain text with page after page of
> copyright and disclaimer info in front of it.

By now, many a lot text are available in HTML, too (and if someone
submits an HTMLized text, it wil be accepted, of course).  The spoiler
plate issue will go away, once switching to XML is done.

> Wikibooks plans to host many public domain texts; basically anything in the
> public domain you would expect to buy in a college bookstore or find in a
> university library.

Not a different intention; the PG heads for quite the same goal ;)

> But our focus is on adding value to those texts by wikifying terms to
> point to Wikipedia articles and also adding annotation in the "margin"
> (a feature that is being worked on for Wikibooks).

This is of dubious value.  Why don't you trust in the reader use
wikipedia's search feature?  Writing good annotations is a difficult
job; annotations are mostly "gelehrter Wind" (G. E. Lessing).  At
least, make it possible to switch of the linking and annotation stuff
(cf. the Perseus project).

--
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke at suse.de (work) / keichwa at gmx.net (home)               |   (*)/'(*)


from_name: Vicki Rosenzweig

body:
At 10:11 AM 8/17/03 +0200, Karl Eichwalder wrote:
>Daniel Mayer <maveric149 at yahoo.com> writes:
>
> > Uh? The same argument can be made about links in Wikipedia articles to
> other
> > Wikipedia articles.
>
>No.
>
> > Easily accessible links is the whole point of HTML and the web.
>
>No ;) I still believe contents is more important; all these links,
>esp. these navigation links are superfluous.  A good search engine is
>all you need -- frankly, navigations links are a waste of resources
>(time and bandwidth).  I admit, it nice to click around but going this
>way you usually will not find the info you are looking for.

Google, our best search engine, works only because of all those links
on Web pages.

Within Wikipedia, the links are how people know there's an article on
a subject, sometimes one they wouldn't have thought to consult. They're
also how we keep our articles to a manageable size.

--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


subject: [WikiEN-l] User:Saddam Hussein

body:
At 11:09 PM 8/16/03 -0700, RickK wrote:
>What is the sense of other people about not only the name of Saddam
>Hussein as a User name, but the fact that the User has copied the entire
>content of the [[Saddam Hussein]] article to his/her User page?
>

We could buy a *lot* of servers for the money being offered as a reward
for that man. :-)
--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


references:
<20030816204000.45455.qmail@web11504.mail.yahoo.com>
	<shzni86exd.fsf@tux.gnu.franken.de> <3F3F1E59.40907@pobox.com>

body:
Brion Vibber <brion at pobox.com> writes:

> Annotations could include cross-links to Wikipedia and Wiktionary as
> well as within the document, and we could have a relatively sane system
> for linking from Wikipedia and Wiktionary to *particular spots* in the
> texts, for instance to provide context for a quote.

One can link any "external" resource using the XLink technology;
alt least this should work theoretically -- thus far I never saw it in
real life ;)

As long as resource problems at wikipedia.org are not resolved I'd
rather vote not to add new projects.  First make the core project work:
search features are very limited and available features are disabled
because of resource issues.

--
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke at suse.de (work) / keichwa at gmx.net (home)               |   (*)/'(*)


body:
Daniel Mayer <maveric149 at yahoo.com> writes:

> Uh? The same argument can be made about links in Wikipedia articles to other
> Wikipedia articles.

No.

> Easily accessible links is the whole point of HTML and the web.

No ;) I still believe contents is more important; all these links,
esp. these navigation links are superfluous.  A good search engine is
all you need -- frankly, navigations links are a waste of resources
(time and bandwidth).  I admit, it nice to click around but going this
way you usually will not find the info you are looking for.

--
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke at suse.de (work) / keichwa at gmx.net (home)               |   (*)/'(*)


body:
> Karl Eichwalder wrote:
> >I still believe contents is more important;
> >all these links, esp. these navigation links
> >are superfluous.  A good search engine is
> >all you need...

>Mavwrote:  Ah - a true believer in search engines.
>As with all true believers, there
> isn't any point arguing with you.

Oh Jeez :)

But I love the demo -- the idea, the look,
everything... including the fact that its notion of
*{separate-but-related editable dataspaces} is quite
in line with what we need on the wiki to deal with
*editing IL links {metadata} and anything else people
can think of.  Simple concept -- how hard is it to do?

1. Niggle --> I would like to see a mouseover/mouseoff
toggle option for the annotes.  Or maybe a timer for
closing annotes.  (Call me and forty million other
surfers lazy - we prefer to hover than click, if
possible. :)

Ergonomicist Steve

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: tarquin

subject:
[Wikitech-l] Print stylesheet (was: Small change in "print page"
	template needed)

body:
Brion Vibber wrote:

>
> 'Printable mode' really should be replaced with a style sheet, though.
> It'd save a lot of trouble in the code, and people could just hit
> "print" from the regular page and get decent-looking output.
>
yes, I have been thinking about this.
It would certainly be a more elegant way to do it.

There is at least one problem however:
hidden URLs are written out in full in the generated printable version.
There's probably CSS trickery that allows the HREF attribute to be
appended to the A element, but.... it probably won't work in IE :(

Incidentally, "Table of contents [showhide <javascript:toggleToc()>]"
doesn't make much sense in print ... ;)


subject: [WikiEN-l] User:Saddam Hussein

body:
--- Vicki Rosenzweig <vr at redbird.org> wrote:
> We could buy a *lot* of servers for the money being
> offered as a reward
> for that man. :-)

Yes, and serVANTS, too. :)
-S-

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


body:
> -- brion vibber (brion @ pobox.com) wrote:
> That could probably be protected against by checking
> the cur_user_text
> field as well as cur_timestamp.

You sure checking in/out is a bad idea?

-S-

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [WikiEN-l] Votes for deletion

body:
On 17 Aug 2003, Erik Moeller wrote:
 > > I choose not to follow this policy as I consider
> it unnecessary extra
> > work,

Oliver Pereira <omp199 at ecs.soton.ac.uk> wrote:
 > Hmm. Are you by any chance a supporter of
> [[Wikipedia:Ignore all rules]]?
> I was under the impression that a prerequisite of
> having sysop status was
> agreeing to follow the policies. Somebody correct me
> if I'm wrong. Still,
> even if it isn't, I don't think it sets a good
> example to say that you are
> going to ignore a policy. Perhaps it would be better
> if you were to argue
> for it to be made explicitly optional?

I agree with the sentiments expressed by Oliver here
-- not that I dont understand Eriks comment as tongue
in cheek ;)-- but Erik's recent "unilateral removal"
of RK from nomination was a bit too "unilateral" -- as
such a philosophy of unilateralism tends to contradict
the more general notions of voting, democracy, and so
forth.

That said, his action was only wrong in that it was
too much in good taste (as my attempt was half-baked)
and his comments were the catalyst that caused me to
be more thoughtful about the issue and make a more
serious campain for RK's sysopdom.

Jeez - was Dubya "right" to just go ahead and invade
Iraq after all?
-S-

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Björn Lindqvist

subject: [WikiEN-l] User:Saddam Hussein

body:
 >What is the sense of other people about not only the name of Saddam
 >Hussein as a User name, but the fact that the User has copied the
 >entire content of the [[Saddam Hussein]] article to his/her User page?
 >
 >RickK

Don't feed the trolls...

BL


subject:
[Wikipedia-l] On Interlanguage links and seeding articles on other
	langas.

body:
Conversation from Talk pages:

ANGELA:I've just seen your post to the intlwiki
mailing list. I can't reply there as I'm not currently
subscribing to it and I've forgotten my password to
re-subscribe, so I'll reply here instead. Feel free to
copy this to the list if you want to.

I disagree with creating articles which consist only
of interlanguage links and I tend to delete such pages
from the English Wikipedia. It wastes someone's time
if they follow a link thinking they will get some
useful information, only to find a blank page. It may
be useful for those who want to write articles in
other languages, but frustrating and confusing for
those trying to read Wikipedia. Linking should occur
after the article is written, not before. Angela
21:59, 16 Aug 2003 (UTC)

STEVERTIGO:Paraphrasing what you said,(apologies :) in
a different context: {I disagree with creating stub
articles which consist only of a couple paragraphs and
I tend to delete such pages from the English
Wikipedia. It wastes someone's time if they follow a
link thinking they will get some useful information,
only to find a unprofessional and incomplete article.
It may be useful for those who want to add or
contribute to these articles, but frustrating and
confusing for those trying to read Wikipedia.
Professional quality should be attained before not
after the article is written.} ??sv 22:20, Aug 16,
2003 (UTC)
P.S -- I wrote back to Tarq on
http://mail.wikipedia.org/pipermail/intlwiki-l/2003-August/001999.html

ANGELA:But a stub can contain useful information. IL
links do not. They only tell you that there may or may
not be some info in some other language somewhere. A
blank page is confusing. A page with only a little bit
of info is not. Angela

STEVERTIGO:Bu shi ! A stub can also contain useless
information -- the point is not to generalize what
stubs are and what they are good for. Some stubs are
better than others. -- "IL links do not"-- Bu shi ! If
you look at an page with just a title and an IL
link--and you cant read that language--just hover over
the ILlink! Bingo. You can do it right now on the
ar:wikipedia. Thats one situation (as unusual as it
is) where what you said is not true. There are many
more. Where in the rules does it say you cant put x in
front of X? In fact in some ways its better that
making a whole system and then trying to link them up
in some way -- each should give the other ideas about
how to structure stuff organization. Do you mind if I
load this talk up to the mail? -S- P.s -- mail Walter
to reset your password intlwiki-l-owner AT Wikipedia
DOT org

ANGELA: Hovering over links is only useful if you are
in the encyclopedia of a language you don't read. Why
you be there in the first place? If you are in en:
then a link which tells you the page title in Arabic
won't help. I agree with linking the WPs together, but
linking up a load of blank pages is not useful. The
red links are there to tell you a page does not exist.
If you put a link in, it makes it look like the page
does exist.     re: load this talk up to the mail... I
don't mind. re: mail Walter. I already clicked the
"send me a new password button" but it hasn't done
anything. I shall do as you suggest.

STEVERTIGO:IL links/usefulness - I respectfully
disagree. TBC-

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Rick

subject: [WikiEN-l] Votes for deletion

body:
Oliver Pereira <omp199 at ecs.soton.ac.uk> wrote:On 17 Aug 2003, Erik Moeller wrote:

> I choose not to follow this policy as I consider it unnecessary extra
> work,

Hmm. Are you by any chance a supporter of [[Wikipedia:Ignore all rules]]?
I was under the impression that a prerequisite of having sysop status was
agreeing to follow the policies. Somebody correct me if I'm wrong. Still,
even if it isn't, I don't think it sets a good example to say that you are
going to ignore a policy. Perhaps it would be better if you were to argue
for it to be made explicitly optional?

Oliver

This is not a policy.  This is one person's attempt to dictate policy.

RickK

---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030817/133810c1/attachment.htm


from_name: Daniel Ehrenberg

body:
--- Daniel Mayer <maveric149 at yahoo.com> wrote:
> Here is a hack of what that may look like:
>
http://www.wikipedia.org/upload/5/56/Sidenote-column.html

I really dislike that one because it doesn't work
offline with mozilla. I prefer
http://www.wikipedia.org/upload/d/de/Sidenote-window.html
It takes up a lot less space and looks better.
LDan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [WikiEN-l] Votes for deletion

body:
> I choose not to follow this policy as I consider it
> unnecessary extra
> work, but I don't mind if others add the boilerplate
> notice. (We already
> bend over backwards to inform newbies whenever they
> make a mistake.) Just
> don't remove pages I add to VfD or reset the timer
> because of the missing
> boilerplate.
>
> Regards,
>
> Erik

I agree. Not only is it extra work, but it makes the
article show up in the article count, whereas in a
blank page wouldn't. And a notice like that
discourages people from replacing it with new content.
When I encounter a graffiti page, I don't put a
boilerplate text there and add it to votes for
deletion. Instead, I replace it with a 2 or 3 sentence
stub. This usually takes the same, if not less, and it
makes a lot less work for others who patrol votes for
deletion all the time. Every topic deserves an
article, so why delete it?
LDan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


body:
Steve Vertigo wrote:
>>-- brion vibber (brion @ pobox.com) wrote:
>>That could probably be protected against by checking
>>the cur_user_text
>>field as well as cur_timestamp.
>
>
> You sure checking in/out is a bad idea?

I'm not sure I understand what you're referring to.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Print stylesheet

body:
Brion Vibber wrote:

> wikistandard.css:
> .exturl { display: none } /* redundant on screen */
>
> print.css:
> .exturl { display: inline } /* need in print */
>
> html:
> foo
> (http://blah/)
>
> Yes, lynx and Netscape 4 with JavaScript disabled will see extra URLs.
> Tough.

That would require some change in the page output code. But fair enough :-)

There is another problem -- it seems a bit daft to have to specify a
print version of the stylesheet of each skin.
We could use another LINK in the HTML HEAD for the print stylesheet, but
the problem is then that each skin has different elements that must be
hidden.

I think a global print stylesheet would be best, and to do that we'd
have to specify a basic page architecture common to all skins. This
doesn't need to be more specific than:
* all header content is in DIV id='head'
* all sidebar content is in DIV id='sidebar'
* all footer  ... etc

A reorganisation like this might be easiest to do after we convert to a
template system using "smarty".

While on the subject of stylesheets, I've been pondering something else
lately.
Something like image-floating styles would presumably be the same in all
skin stylesheets -- at least the basics. (some future skin might want
flashing green border, who knows!)
Is it best to:
a) paste the same class into each skin stylesheet. Future skin
stylesheets must then ensure they begin from a template that has the
essential classes
b) create a "global" stylesheet of elements that work across all skins.

On UnrealWiki I went for option b). Particular skin stylesheets can
still add rules to those classes of course, but the core stuff, eg
"float:left;" is set in only one location.
But it does mean every browser downloads 2 stylesheets instead of 1.
Would this be a problem for our server?

if not, this is something I would like to implement.


subject: [WikiEN-l] Votes for deletion

body:
Erik wrote:
> I choose not to follow this policy as I consider it
> unnecessary extra work, but I don't mind if others
> add the boilerplate notice. (We already bend over
> backwards to inform newbies whenever they make
> a mistake.) Just don't remove pages I add to VfD
> or reset the timer because of the missing boilerplate.

What? So you are saying that we can list items on VfD and /not/ make an
attempt to inform the author and readers of the page that it is being
considered for deletion? How are they supposed to know? I've already received
several complaints from newbies who had their pages nuked without notice.

Unnecessary extra work? This type of a lack of due process is very, very
unwiki.

-- Daniel Mayer (aka mav)


from_name: Erik Moeller

subject: [WikiEN-l] Votes for deletion

body:
Rick-

>    ''This page has been listed on [[Wikipedia:Votes for deletion]]. Please
> see that page for justifications and discussion.'' ". And [[Wikipedia:Votes
> for deletion]] now says:

> "NOTE: Always indicate on the listed page itself that it is here. See
> Wikipedia:Deletion_policy#Listed_for_deletion_notice. If this is not done,
> then the page will not be deleted. "

I choose not to follow this policy as I consider it unnecessary extra
work, but I don't mind if others add the boilerplate notice. (We already
bend over backwards to inform newbies whenever they make a mistake.) Just
don't remove pages I add to VfD or reset the timer because of the missing
boilerplate.

Regards,

Erik


from_name: Tim Starling

subject: [Wikitech-l] Re: Using HEAP tables

references:
<bhkboe$ked$1@sea.gmane.org>
	<3F3DBA09.10604@pobox.com><bhkiss$qm0$1@sea.gmane.org>
	<3F3DD2DA.4040801@pobox.com>

body:
Brion wrote:
> Hmm... Here's how the bug works now:
>
> THREAD A                   THREAD B
>  SELECT data from cur       SELECT data from cur
>  check for edit conflict    check for edit conflict
>  UPDATE cur with new data
>                             UPDATE cur with new data
>                             [overwriting what A just did]
>  INSERT prev data to old
>  [the previous one, not B's]
>                             INSERT prev data to old
>                             [second copy of the previous,
>                              not A's]
>
> with the result that neither thread detects an edit conflict, old
> contains two copies of the previous version, and A's edit is gone.

Actually the old INSERT happens before the cur UPDATE, so the problem exists
for the duration of the old query, plus the time it takes to acquire the
lock in the UPDATE query. This means that there are a number of possible
manifestations, for example

  A            B
SELECT
INSERT
            SELECT
            INSERT
UPDATE
            UPDATE

or

  A            B
SELECT
            SELECT
INSERT
            INSERT
UPDATE
            UPDATE

or even

  A            B
SELECT
            SELECT
INSERT
UPDATE
            INSERT
            UPDATE

They all have the same effect: like you say, two copies of the previous
revision in old, and B's version in cur.

>
> Here's how it would work with transactions if I understand it correctly:
>
> THREAD A                   THREAD B
>  BEGIN                      BEGIN
>  SELECT data from cur       SELECT data from cur
>  check for edit conflict    check for edit conflict
>  UPDATE cur with new data   UPDATE cur with new data
>  [not saved yet]            [not saved yet]
>  INSERT prev data to old    INSERT prev data to old
>  [still not saved yet]      [still not saved yet]
>  COMMIT
>  [successfully saves edit]
>                             COMMIT
>                             [transaction is rejected,
>                              mysql reports an auto rollback]
>                             we know something's wrong
>                             start over:
>                             SELECT data from cur
>                             check for edit conflict
>                             display edit conflict screen
>
> with the result that A's edit is saved intact and B can be shown an edit
> conflict screen.

I couldn't find any reference to this sort of behaviour in the MySQL manual,
so I did a couple of tests. It seems transactions work like this:

BEGIN
UPDATE cur... -- gets a lock on the cur table
COMMIT  -- writes to cur regardless of previous activity

I opened up a connection to the test DB in an SSH window, and did something
along the lines of the following:

mysql: set autocommit=0;
mysql: begin;

Then I changed [[Test2]] to "5" using my browser. This worked, because MySQL
hadn't acquired a lock. Then I did this...

mysql: update cur set cur_text="6" where cur_title="Test2";
mysql: commit;

MySQL had no problem with either of the last two queries, successfully
updating cur to 6. When I did this:

mysql: begin;
mysql: update cur set cur_text="hello" where cur_title="Test2";

update in browser...

mysql: commit;

The attempt to update in the browser failed, returning a lock timeout
error -- like that time I told you to flush the tables when you were already
doing it. So having PHP threads die on us in the middle of transactions is
currently very, very bad. Perhaps we should use register_shutdown_function()
to rollback any active transactions. Or kill on timeout like in my scheme.
Killing a thread which is serving an unrelated legitimate query is really
much better than attempting to contact someone with root access in the
middle of the US night.

Note that using register_shutdown_function() will effectively disable user
aborts -- see chapter 20 of the PHP manual.

-- Tim Starling.


from_name: JFrost8401 at aol.com

subject: [WikiEN-l] Votes for deletion

body:
The new Policy should at least ensure that VfD never gets below 70k.
Personally, I'd rather stop deleting (ggod news folks) than put the boilerplate on
automatically.

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030817/e49e5937/attachment.htm


subject: [Wikipedia-l] Exciting new statistics!

body:
Okay, I think I've managed to semi-automate this now. In the future,
updates should appear within a day of new backup dumps going up.

http://www.wikipedia.org/wikistats/EN/Sitemap.htm

This is generated from the backup dumps by Erik Zachte's processing
scripts: http://members.chello.nl/epzachte/Wikipedia/Statistics/

(To change the language of the page, change the "EN" to "NL" etc. Most
languages are not translated yet; contact Erik for info. All versions
should show the same data set.)

Erik: I made some slight tweaks to support filtering the data through
bzip2 as it reads; I don't know if that will work on Windows, though it
ought to. Patch attached.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stats-bzip.diff
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030817/667b0bf7/attachment.diff


subject: [Wikitech-l] Exciting new statistics!

body:
Okay, I think I've managed to semi-automate this now. In the future,
updates should appear within a day of new backup dumps going up.

http://www.wikipedia.org/wikistats/EN/Sitemap.htm

This is generated from the backup dumps by Erik Zachte's processing
scripts: http://members.chello.nl/epzachte/Wikipedia/Statistics/

(To change the language of the page, change the "EN" to "NL" etc. Most
languages are not translated yet; contact Erik for info. All versions
should show the same data set.)

Erik: I made some slight tweaks to support filtering the data through
bzip2 as it reads; I don't know if that will work on Windows, though it
ought to. Patch attached.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stats-bzip.diff
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030817/667b0bf7/attachment.ksh>


subject: [Wikitech-l] Re: Using HEAP tables

body:
Just replying to my own message again. I didn't say what I think will happen
to this bug, with transactions implemented. Here is my current
understanding:

  A            B
SELECT
            SELECT
BEGIN
            BEGIN
INSERT
            INSERT waits for lock...
UPDATE      ...
            ...
COMMIT      ...
            INSERT returns
            UPDATE
            COMMIT

So the end result is exactly the same. The danger period is still the
duration of the INSERT plus part of the UPDATE.

-- Tim Starling <tstarlingphysicsunimelbeduau>


subject: [Wikipedia-l] Exciting new statistics!

body:
Brion wrote:
>Okay, I think I've managed to semi-automate this now.
>In the future, updates should appear within a day of new
>backup dumps going up.
>
>http://www.wikipedia.org/wikistats/EN/Sitemap.htm

Sweet! I guess this renders obsolete many of our human edited stats pages
(those were hard to maintain anyway).

--mav


from_name: sgilbert at nbnet.nb.ca

body:
Karl Eichwalder wrote:

> Daniel Mayer <maveric149 at yahoo.com> writes:
>>
> > Easily accessible links is the whole point of HTML and the web.
>
> No ;) I still believe contents is more important; all these links,
> esp. these navigation links are superfluous.  A good search engine is
> all you need -- frankly, navigations links are a waste of resources
> (time and bandwidth).  I admit, it nice to click around but going this
> way you usually will not find the info you are looking for.

I think you may be working on the wrong project, Karl. It sounds
like you're looking for Gopherpedia. ;-)

Seriously, one of the reasons wikis work so well is the ease of
linking and cross-referencing. Are you arguing that if a person is
reading the article on Mexico, and then wants to read about the
history of the country in more detail, he should have to do a search
to find our History of Mexico article?

However, I would love to see our searching capabilities improved.
That's not a complaint, dear developers, just a little wistful thinking.
:)

Stephen G.


subject: [Wikipedia-l] Re: encyclopedia

body:
Merritt L. Perkins wrote:
>
> What is an encyclopedia?

Larry Sanger, Wikipedia's former project leader, spend some time
pondering this question. Specifically, he wrote "The elements of an
encyclopedia project", which you can find at
http://meta.wikipedia.org/wiki/The_elements_of_an_encyclopedia_pr
oject . There are other essays at http://meta.wikipedia.org/ that
you might enjoy as well. Feel free to post your own thought on the
subject!

Stephen G.


subject: [Wikipedia-l] New statistics and Wikimedia's first press release

body:
If this is going to be updated each time the databases are backed up, then I
think it would be a great idea to add a link to
http://www.wikipedia.org/wikistats/EN/Sitemap.htm on each wiki's
Special:Statistics page (translations will be needed though). These stats are
awesome!

I've already added a link to this page on our next press release. Speaking of
which, we still need to set-up the Wikimedia Foundation website and the
paypal (or whatever) service to accept donations. Has anything been done
along these lines yet? I'm willing to help but I don't know where to start...

The stats are also very useful in that we can now estimate with some degree of
accuracy, a range of dates we might hit the 300,000 article milestone; in my
estimation that will happen somewhere between 35 to 50 days from Aug 14,
depending on how fast our growth rate increases (this assumes no significant
bot activity). So we still have time to set everything up (including the new
hardware Jimbo is buying; Thanks Jimbo!) if we start now.

Just another reminder: Swedish, Danish, and Dutch are specifically mentioned
and linked to in the press release but so far nobody has volunteered to
translate the press release into those languages. Please see:
http://meta.wikipedia.org/wiki/Talk:Wikimedia's_first_press_release#Translators_needed

Also, French, Polish, Swedish, and Danish are all mentioned and linked to in
the press release but so far nobody has volunteered to be the press contact
coordinators for those languages. Please see:
http://meta.wikipedia.org/wiki/Talk:Wikimedia's_first_press_release#Ambassadors_needed

Of course, the more languages the press release is translated into, and the
more languages that are represented by a press contact coordinator, the
better.

-- Daniel Mayer (aka mav)


subject: [WikiEN-l] Votes for deletion

body:
> What? So you are saying that we can list items on
> VfD and /not/ make an
> attempt to inform the author and readers of the page
> that it is being
> considered for deletion? How are they supposed to
> know? I've already received
> several complaints from newbies who had their pages
> nuked without notice.
>
> Unnecessary extra work? This type of a lack of due
> process is very, very
> unwiki.
>
> -- Daniel Mayer (aka mav)

At Usemod wiki (that means some of the older
wikipedias) pages can be deleted and restored by
anyone. And most wikis use Usemod. It can't be unwiki
to do that.

LDan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [WikiEN-l] Votes for deletion

body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:
> The only thing you will accomplish with this RK
> sysop nomination nonsense
> (which he himself never asked for) is yet another
> flamewar because you
> know exactly from the initial reaction that there is
> strong opposition to
> this nomination. I consider your actions harmful to
> the community and
> counter-productive. If RK wants to apply for sysop
> status, let him. But
> there's no reason for you to nominate specifically
> controversial
> Wikipedians. This kind of behavior reminds me very
> much of the
> troublemaking that got Lir banned. Not only do you
> insist on starting this
> flamewar, you also spammed many user talk pages to
> make sure that the
> maximum number of people get involved in the
> flamewar. Great thinking
> there! Here's a selection of your recent edits:
>
> # 01:25, Aug 17, 2003 User talk:Danny
> # 01:24, Aug 17, 2003 User talk:Cyp (top) [rollback]
> # 01:24, Aug 17, 2003 User talk:Cprompt
> # 01:23, Aug 17, 2003 User talk:Camembert
> # 01:23, Aug 17, 2003 User talk:Dante Alighieri
> (top) [rollback]
> # 01:22, Aug 17, 2003 User talk:Delirium (top)
> [rollback]
> # 01:22, Aug 17, 2003 User talk:The Epopt (top)
> [rollback]
> # 01:21, Aug 17, 2003 User talk:Fred Bauder (top)
> [rollback]
> # 01:20, Aug 17, 2003 User talk:Goatasaur (top)
> [rollback]
> # 01:20, Aug 17, 2003 User talk:Hephaestos (top)
> [rollback]
> # 01:19, Aug 17, 2003 User talk:Infrogmation (top)
> [rollback]
> # 01:19, Aug 17, 2003 User talk:JeLuF (top)
> [rollback]
> # 01:19, Aug 17, 2003 User talk:Karen Johnson (top)
> [rollback]
> # 01:18, Aug 17, 2003 User talk:Maveric149
> # 01:16, Aug 17, 2003 User talk:LittleDan (top)
> [rollback]
> # 01:16, Aug 17, 2003 User talk:Evercat (top)
> [rollback]
> # 01:13, Aug 17, 2003 User talk:Jtdirl
> # 01:11, Aug 17, 2003 User talk:AntonioMartin (top)
> [rollback]
> # 01:10, Aug 17, 2003 User talk:Andre Engels
> # 01:09, Aug 17, 2003 User talk:Anthere (top)
> [rollback]
> # 01:09, Aug 17, 2003 User talk:Brion VIBBER
> # 01:08, Aug 17, 2003 User talk:Olivier (top)
> [rollback]
> # 01:06, Aug 17, 2003 User talk:The Cunctator (top)
> [rollback]
> # 01:06, Aug 17, 2003 User talk:Maveric149
> # 01:05, Aug 17, 2003 User talk:Deb (top) [rollback]
> # 01:05, Aug 17, 2003 User talk:Ed Poor (top)
> [rollback]
> # 01:04, Aug 17, 2003 User talk:Eloquence
> # 01:01, Aug 17, 2003 User talk:Jtdirl
> # 01:00, Aug 17, 2003 User talk:Lee Daniel Crocker
> (top) [rollback]
> # 00:59, Aug 17, 2003 User talk:Slrubenstein
> # 00:59, Aug 17, 2003 User talk:Tim Starling (top)
> [rollback]
> # 00:58, Aug 17, 2003 User talk:Tim Starling (form
> letter)
> # 00:55, Aug 17, 2003 User talk:Angela (2 messages
> -- gotta run)
> # 00:54, Aug 17, 2003 User talk:Mbecker (top)
> [rollback]
> # 00:52, Aug 17, 2003 User talk:MyRedDice
> # 00:40, Aug 17, 2003 User talk:Angela
> # 00:20, Aug 17, 2003 User talk:Angela
>
> Frankly, I am increasingly convinced that you are
> deliberately trolling.
> Maybe you could concentrate on writing articles for
> a change.
>
> Regards,
>
> Erik

I agree that those comments were unnecessary, and
maybe even annoying, but it was not trolling.
LDan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [WikiEN-l] Wikipedia Shepherds

body:
> Wikipedia Storm Watchers?

No, they're not a storm. That again implies
destructiveness.
LDan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [WikiEN-l] Votes for deletion

body:
--- JFrost8401 at aol.com wrote:
> The new Policy should at least ensure that VfD never
> gets below 70k.
> Personally, I'd rather stop deleting (ggod news
> folks) than put the boilerplate on
> automatically.
>
> Jim

I really think we have no reason to delete at all,
unless there's something wrong with the title. If the
title is good, a stub should be made.
LDan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [WikiEN-l] Votes for deletion

body:
LDan wrote:
>I really think we have no reason to delete at all,
>unless there's something wrong with the title. If the
>title is good, a stub should be made.

Then monitor VfD daily and make those stubs! There is a /reason/ why we have
different link colors to distinguish live vs edit links; If no useful content
is on the page at all then the page title should show up as a red link.
Otherwise readers and writers cannot be reasonably sure if a particular link
leads to a page with useful information on it.

-- mav


subject: [WikiEN-l] Votes for deletion

body:
--- Rick <giantsrick13 at yahoo.com> wrote:
>
> [[Wikipedia:Deletion policy]] seems to have sprouted
> the following language:  "
>
> When you list a page on Wikipedia:Votes for deletion
> that you think will be listed for the entire 7 days
> -- i.e., a page that won't be deleted immediately --
> please place the following notice above the page's
> content:
>
>    ''This page has been listed on [[Wikipedia:Votes
> for deletion]]. Please see that page for
> justifications and discussion.'' ".
> And [[Wikipedia:Votes for deletion]] now says:
>
> "NOTE: Always indicate on the listed page itself
> that it is here. See
>
Wikipedia:Deletion_policy#Listed_for_deletion_notice.
> If this is not done, then the page will not be
> deleted. "
>
> Now, I can't say that I DISAGREE with this policy
> (although I think that having to put this notice on
> every page to be deleted is a tad excessive), but
> when and where was this policy discussed?  Was it
> ONE PERSON who made the decision, UNILATERALLY, that
> nothing would be deleted unless his/her pet
> boilerplate was put onto the page in question?
>
> Such new policies need to be discussed, not just
> thrown out as a fait accompli.  Other sysops may
> just go ahead and delete pages without the
> boilerplate, and have the right to do so, since this
> "policy" is only one person's decision, and not the
> agreement of the users of Wikipedia as a whole.
>
> RickK

I like the policy before you changed it better.
LDan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [WikiEN-l] Votes for deletion

body:
Daniel Ehrenberg wrote:
>>What? So you are saying that we can list items on
>>VfD and /not/ make an
>>attempt to inform the author and readers of the page
>>that it is being
>>considered for deletion? How are they supposed to
>>know? I've already received
>>several complaints from newbies who had their pages
>>nuked without notice.
>>
>>Unnecessary extra work? This type of a lack of due
>>process is very, very
>>unwiki.
>>
>>-- Daniel Mayer (aka mav)
>
>
> At Usemod wiki (that means some of the older
> wikipedias) pages can be deleted and restored by
> anyone. And most wikis use Usemod. It can't be unwiki
> to do that.

Yes, but deletion there works completely differently. It works by
putting a notice on the page to be deleted. If the notice isn't removed
after so many days, the page is deleted automatically.

-- brion vibber (brion @ pobox.com)


subject: [WikiEN-l] Votes for deletion

body:
Richard Grevers wrote:
>"But the plans have be available at the
>regional works office at Alpha Centauri

Exactly! So you Earthlings have no reason to complain that we destroyed your
world to build a hyperspace bypass!

>From The Hitchhikers Guide to the Galaxy:

[Commander of the Vogon Constructor Fleet]:
"There's no point in acting  all surprised about it
All  the planning  charts  and  demolition orders
have been on display in your local planning
department on Alpha  Centauri for fifty of your
Earth  years,  so  you've  had  plenty of time to
lodge any formal complaint and it's far too late to
start  making a fuss about it now."
....

"What do you mean  you've  never  been  to  Alpha
Centauri?  For heaven's  sake mankind, it's only four
light years away you know. I'm sorry, but if you can't
be bothered to take an interest in local affairs that's
your own lookout."

"Energize the demolition beams!"

Replace "Alpha Centauri" with "Wikipedia:Votes for deletion" and "demolition
beams" with "deletion." The last thing we need is for our Admins to be
perceived as Vogons who are "not actually evil, but bad tempered,
bureaucratic, officious and callous."

-- Daniel Mayer (aka mav)


from_name: Matthew Woodcraft

subject: [Wikipedia-l] Possible database corruption

body:
The history of the page
http://www.wikipedia.org/wiki/Philosophy_of_mathematics
shows two edits by user Chinju at 16:47, 6 Aug 2003. The next edit was
today (17 Aug).

The revision resulting from the second Chinju edit, as currently
displayed in the history, contains garbage. I believe I looked at the
page between the 6th and 17th of August, and it did not contain garbage.
I expect someone else would have noticed in 11 days, too.

I'm worried that this might be database corruption.

-M-


from_name: Oliver Pereira

subject: [WikiEN-l] Votes for deletion

body:
On 17 Aug 2003, Erik Moeller wrote:

> I choose not to follow this policy as I consider it unnecessary extra
> work,

Hmm. Are you by any chance a supporter of [[Wikipedia:Ignore all rules]]?
I was under the impression that a prerequisite of having sysop status was
agreeing to follow the policies. Somebody correct me if I'm wrong. Still,
even if it isn't, I don't think it sets a good example to say that you are
going to ignore a policy. Perhaps it would be better if you were to argue
for it to be made explicitly optional?

Oliver

+-------------------------------------------+
| Oliver Pereira                            |
| Dept. of Electronics and Computer Science |
| University of Southampton                 |
| omp199 at ecs.soton.ac.uk                    |
+-------------------------------------------+


subject: [WikiEN-l] Votes for deletion

body:
Oliver-
> On 17 Aug 2003, Erik Moeller wrote:

>> I choose not to follow this policy as I consider it unnecessary extra
>> work,

> Hmm. Are you by any chance a supporter of [[Wikipedia:Ignore all rules]]?

To some extent, yes.

> I was under the impression that a prerequisite of having sysop status was
> agreeing to follow the policies.

I use the word policy very liberally above. Truthfully, there are
relatively few policies which are set in stone (NPOV, Wikiquette etc.),
and the boilerplate recommendation is certainly not among them.

> Somebody correct me if I'm wrong. Still,
> even if it isn't, I don't think it sets a good example to say that you are
> going to ignore a policy. Perhaps it would be better if you were to argue
> for it to be made explicitly optional?

I don't care enough about this policy to argue about it. I have, however,
edited VfD to say that a missing boilerplate notice is not grounds for
removal of a page from the VfD listing.

Regards,

Erik


subject: [WikiEN-l] Votes for deletion

body:
Steve-
> I agree with the sentiments expressed by Oliver here
> -- not that I dont understand Eriks comment as tongue
> in cheek ;)-- but Erik's recent "unilateral removal"
> of RK from nomination was a bit too "unilateral" -- as
> such a philosophy of unilateralism tends to contradict
> the more general notions of voting, democracy, and so
> forth.

The only thing you will accomplish with this RK sysop nomination nonsense
(which he himself never asked for) is yet another flamewar because you
know exactly from the initial reaction that there is strong opposition to
this nomination. I consider your actions harmful to the community and
counter-productive. If RK wants to apply for sysop status, let him. But
there's no reason for you to nominate specifically controversial
Wikipedians. This kind of behavior reminds me very much of the
troublemaking that got Lir banned. Not only do you insist on starting this
flamewar, you also spammed many user talk pages to make sure that the
maximum number of people get involved in the flamewar. Great thinking
there! Here's a selection of your recent edits:

# 01:25, Aug 17, 2003 User talk:Danny
# 01:24, Aug 17, 2003 User talk:Cyp (top) [rollback]
# 01:24, Aug 17, 2003 User talk:Cprompt
# 01:23, Aug 17, 2003 User talk:Camembert
# 01:23, Aug 17, 2003 User talk:Dante Alighieri (top) [rollback]
# 01:22, Aug 17, 2003 User talk:Delirium (top) [rollback]
# 01:22, Aug 17, 2003 User talk:The Epopt (top) [rollback]
# 01:21, Aug 17, 2003 User talk:Fred Bauder (top) [rollback]
# 01:20, Aug 17, 2003 User talk:Goatasaur (top) [rollback]
# 01:20, Aug 17, 2003 User talk:Hephaestos (top) [rollback]
# 01:19, Aug 17, 2003 User talk:Infrogmation (top) [rollback]
# 01:19, Aug 17, 2003 User talk:JeLuF (top) [rollback]
# 01:19, Aug 17, 2003 User talk:Karen Johnson (top) [rollback]
# 01:18, Aug 17, 2003 User talk:Maveric149
# 01:16, Aug 17, 2003 User talk:LittleDan (top) [rollback]
# 01:16, Aug 17, 2003 User talk:Evercat (top) [rollback]
# 01:13, Aug 17, 2003 User talk:Jtdirl
# 01:11, Aug 17, 2003 User talk:AntonioMartin (top) [rollback]
# 01:10, Aug 17, 2003 User talk:Andre Engels
# 01:09, Aug 17, 2003 User talk:Anthere (top) [rollback]
# 01:09, Aug 17, 2003 User talk:Brion VIBBER
# 01:08, Aug 17, 2003 User talk:Olivier (top) [rollback]
# 01:06, Aug 17, 2003 User talk:The Cunctator (top) [rollback]
# 01:06, Aug 17, 2003 User talk:Maveric149
# 01:05, Aug 17, 2003 User talk:Deb (top) [rollback]
# 01:05, Aug 17, 2003 User talk:Ed Poor (top) [rollback]
# 01:04, Aug 17, 2003 User talk:Eloquence
# 01:01, Aug 17, 2003 User talk:Jtdirl
# 01:00, Aug 17, 2003 User talk:Lee Daniel Crocker (top) [rollback]
# 00:59, Aug 17, 2003 User talk:Slrubenstein
# 00:59, Aug 17, 2003 User talk:Tim Starling (top) [rollback]
# 00:58, Aug 17, 2003 User talk:Tim Starling (form letter)
# 00:55, Aug 17, 2003 User talk:Angela (2 messages -- gotta run)
# 00:54, Aug 17, 2003 User talk:Mbecker (top) [rollback]
# 00:52, Aug 17, 2003 User talk:MyRedDice
# 00:40, Aug 17, 2003 User talk:Angela
# 00:20, Aug 17, 2003 User talk:Angela

Frankly, I am increasingly convinced that you are deliberately trolling.
Maybe you could concentrate on writing articles for a change.

Regards,

Erik


from_name: cprompt

subject: [WikiEN-l] Wikipedia Shepherds

body:
On Fri, 2003-08-08 at 23:01, Toby Bartels wrote:
> Daniel Mayer wrote:
>
> >Toby Bartels wrote:
>
> >>For those worried that "firefighter" tends to imply
> >>that a wave of newbies is a problem (a raging fire),
> >>just remember that it was originally the Wikipedia "militia".
>
> >The fires created are not the newbies themselves, but the damage a small part
> >of them do (either intentional or not).
>
> So we don't think of them as fires but rather as potential arsonists?
> I don't mean to say that the term /is/ inherently insulting,
> but any term that suggests that newbies may cause trouble (and they may)
> will be capable of being taken the wrong way.
> (I personally find "firefighter" acceptable.)

Wikipedia Storm Watchers?


from_name: Tomos at Wikipedia

subject: [Wikitech-l] access counter - an error?

body:
Brion-

Thanks for the explanation. But I think the access counter is behaving a bit
differently than I understood from your posting.

*When I (as a logged-on user) refresh a page, either using F5 or Refresh
button on IE, it does increase the count.
*When I (logged-on) open a new window with IE, it displays the same page as
the existing window, but the count increases.
*When I (logged-on) open a linked page in a new window twice, the newly
opened two windows show the same page (of course), but the access count
increases.

*When I do those things without logging-on, count never increases (because
there is no change made)

So the logged-on users' part seems to be different from what you explained.
Is this an error?

I personally (not speaking on behalf of other Japanese Wikipedians) feel
that counting unique views would make more sense. If I am understanding the
way things are, it would be approximately:

[# of times a server cache is sent (to logged-on or IP users)] + [# of times
a page is cashed to a server (=# of changes made)]

So, for example, is it feasible to add the [# of time a server cache is
sent] to [the counter value] whenever someone makes an edit to a page?

Tomos

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


subject: [Wikitech-l] Print stylesheet

body:
tarquin wrote:
> A reorganisation like this might be easiest to do after we convert to a
> template system using "smarty".
...
> b) create a "global" stylesheet of elements that work across all skins.
...
> this is something I would like to implement.

Yes, please work on this!

-- brion vibber (brion @ pobox.com)


subject:
[Wikitech-l] Re: Simultaneous edit conflict partial protection
	patch

references:
<bhkboe$ked$1@sea.gmane.org> <3F3DBA09.10604@pobox.com>
	<bhkiss$qm0$1@sea.gmane.org> <3F3DD2DA.4040801@pobox.com>
	<bhn2bl$hkj$1@sea.gmane.org> <bhn713$l4t$1@sea.gmane.org>
	<3F3F72BD.9030002@pobox.com> <bho36o$i7a$1@sea.gmane.org>

body:
Tim Starling wrote:
> You're a legend Brion. Don't ever leave us, okay?

<blush>
Well, don't go lauding me until we know whether this thing helps in
practise. ;)

Having seen no "this will never work you fool!" messages, I'm checking
this into stable and installing it as an emergency bug fix.

-- brion vibber (brion @ pobox.com)


in_reply_to:
<3F3FB5D1.26067.3F94CD3@localhost> (sgilbert@nbnet.nb.ca's
	message of "Sun, 17 Aug 2003 17:05:21 -0300")

body:
sgilbert at nbnet.nb.ca writes:

> Seriously, one of the reasons wikis work so well is the ease of
> linking and cross-referencing. Are you arguing that if a person is
> reading the article on Mexico, and then wants to read about the
> history of the country in more detail, he should have to do a search
> to find our History of Mexico article?

This of course is perfectly okay: for more info see [[History of Mexico]].
But linking arbitrary [[term]]s is of dubious value.

> However, I would love to see our searching capabilities improved.
> That's not a complaint, dear developers, just a little wistful
> thinking.

Yes, users and writers have the right to list missing features; if
developers cannot stand it they should feel free to take a break.

--
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke at suse.de (work) / keichwa at gmx.net (home)               |   (*)/'(*)


from_name: Ray Saintonge

subject: [Wikipedia-l] Exciting new statistics!

body:
Daniel Mayer wrote:

>Brion wrote:
>
>>Okay, I think I've managed to semi-automate this now.
>>In the future, updates should appear within a day of new
>>backup dumps going up.
>>
>>http://www.wikipedia.org/wikistats/EN/Sitemap.htm
>>
>
>Sweet! I guess this renders obsolete many of our human edited stats pages
>(those were hard to maintain anyway).
>
It looks great!  As one of those who spends time with Wiktionary, I
would really love it if it could be included.

Ec


subject: [Wikitech-l] Re: Simultaneous edit conflict partial protection patch

references:
<bhkboe$ked$1@sea.gmane.org>
	<3F3DBA09.10604@pobox.com><bhkiss$qm0$1@sea.gmane.org>
	<3F3DD2DA.4040801@pobox.com><bhn2bl$hkj$1@sea.gmane.org>
	<bhn713$l4t$1@sea.gmane.org> <3F3F72BD.9030002@pobox.com>

body:
"Brion Vibber" wrote:
> I've just checked a patch into the unstable branch which changes the
> order of save operations a bit in a way which should help protect
> against the bug, without adding any transactions or locking or
whathaveyou.
>
> The UPDATE to cur is moved up before the INSERT, *and* its WHERE
> condition is modified to include the timestamp of the old edit (which
> we've been using to detect edit conflicts, after all).
>
> We then ask MySQL how many rows it modified in the UPDATE statement. If
> it's zero, we know that there was an edit conflict; we abort the rest of
> the save operation and (if I've got it right; I haven't tested it in
> actual conflict) show an edit conflict screen.

You're a legend Brion. Don't ever leave us, okay?

-- Tim Starling <tstarlingphysicsunimelbeduau>


from_name: Brion Vibber

subject: [Wikitech-l] Re: Exciting new statistics!

body:
Tim Starling wrote:
>>http://www.wikipedia.org/wikistats/EN/Sitemap.htm
>
> Perhaps the statistics should only go up to last month, not this month.
> Otherwise it looks like we've had a sudden drop in new wikipedians, active
> wikipedians, edits per month, etc. I assume that's what happened, anyway.

Well, it'd be extra fun if the current month data were extrapolated to a
  full month and both to-date and extrapolated figures shown.

But I'll leave programming that to Erik... :)

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] access counter - an error?

body:
Tomos at Wikipedia wrote:
> Brion-
>
> Thanks for the explanation. But I think the access counter is behaving a
> bit differently than I understood from your posting.
>
> *When I (as a logged-on user) refresh a page, either using F5 or Refresh
> button on IE, it does increase the count.

I assure you it works as I described in Mozilla 1.3 for FreeBSD:

* first logged-in visit increases counter
* second load does not
* reload does not
* force reload does
* new view of page after editing does increase count
* reload after does not

> *When I do those things without logging-on, count never increases
> (because there is no change made)

Right.

> So the logged-on users' part seems to be different from what you
> explained. Is this an error?

Yes. Either IE is sending the wrong headers, or we're not understanding
what it's sending, or it's not understanding what we're sending. Could
you specify exactly which version of IE, on what operating system,
you're using? Hopefully this can be tracked down...

(Anyone know of a convenient tool for sniffing the headers out of an
HTTP connection? I need to be able to see what PHP+Apache actually send
out, as it's not always the same as we instructed it...)

> I personally (not speaking on behalf of other Japanese Wikipedians) feel
> that counting unique views would make more sense.

Yes, it would. The page count system is poorly designed to begin with,
and interacts poorly with caching at present.

> If I am understanding
> the way things are, it would be approximately:
>
> [# of times a server cache is sent (to logged-on or IP users)] + [# of
> times a page is cashed to a server (=# of changes made)]
>
> So, for example, is it feasible to add the [# of time a server cache is
> sent] to [the counter value] whenever someone makes an edit to a page?

We'd have to store the value somewhere for that to happen. At that
point, may as well just move the counter increment to before the cache
send).

-- brion vibber ( brion @ pobox.com )


from_name: Nicholas Knight

subject: [WikiEN-l] Votes for deletion

body:
On Sunday 17 August 2003 18:30, Daniel Mayer wrote:
> Replace "Alpha Centauri" with "Wikipedia:Votes for deletion" and
> "demolition beams" with "deletion." The last thing we need is for our
> Admins to be perceived as Vogons who are "not actually evil, but bad
> tempered,
> bureaucratic, officious and callous."

This latest effort at increasing the amount of work one has to do to get
anything useful done is just helping that perception along. Every time I turn
around there's another largely political detail I have to be aware of, and
it's doing anything but encourage me to contribute to Wikipedia.

I've had to put up with pointless procedures on volunteer projects before. I'm
not about to do it again.


from_name: Jimmy Wales

subject: [Wikipedia-l] Wikipedia v. Britannica

body:
According to their website, Britannica's Deluxe Edition 2004 CD
has 75,000 articles.

http://store.britannica.com/escalate/store/DetailPage?pls=britannica&bc=britannica&clist=158032f0dd&pc=B_2004DLX&cc=allcats

Presumably, many of these are longer and of higher quality than our
150,000 English-language articles.

>From our groovy new stats tool, we know that the average Wikipedia
article is 2,115 bytes.  Perhaps of greater interest, 53% of our
articles, or right around 75,000, are longer than 1,500 bytes.

So a question naturally comes to mind - how do our 75,000 >1,500 byte
articles stack up again Britannica's 75,000 articles?

I ask because I continue to work on a plan for a drive to Wikipedia
1.0, and a big part of that plan involves getting a realistic
assessment of what a Wikipedia 1.0 will look like, relative to
Britannica.

If I end up setting a 'target date' for Wikipedia 1.0 of 1 year in the
future, what might we realistically expect to achieve?  What if I set
the 'target date' for 2 years in the future?

What I'd like to find out is that we have a realistic chance of having
a Wikipedia 1.0 release 1 year from now that rivals Britannica.  But
there's no need to hurry, if it will take 2 years or 5 years, that's
how long it will take.

But I'd be very interested in getting some feedback and help on how to
make that determination realistically.

--Jimbo


subject: [Wikipedia-l] Wikipedia v. Britannica

body:
As a quick followup, Britannica also claims that the 32 volume print
encyclopedia has 44 million words.

I just picked a random article of 2,245 bytes, which was also 376
words.  That implies just under 6 bytes per word.  This statistic
could be improved by checking more articles, but the article looks
pretty normal to me, so I think it's basically a sensible ballpark
figure for now.

150,000 articles averaging 2,126 bytes means 318,900,000 bytes total
or just over 53 million words.

Considering *just* the 75,000 articles over 1500 bytes and assuming
conservatively that these are all *only* 1500 bytes long (manifestly
untrue), we are looking at 18,750,000 words for just those longer
articles.

It seems clear to me that we are already "in the ballpark" of the size
of Britannica.  Quality is, of course, an entirely different question.
I think we are often superior and often drastically inferior.  I
susppect that our coverage contains strange and conspicuous 'holes' if
we went through it via a "top down" approach, i.e. take lists of major
topics and see if we've covered them.

--Jimbo


from_name: Fred Bauder

subject: [WikiEN-l] Votes for deletion

body:
on 8/18/03 7:41 AM, Nicholas Knight at nknight at runawaynet.com wrote:

> On Sunday 17 August 2003 18:30, Daniel Mayer wrote:
>> Replace "Alpha Centauri" with "Wikipedia:Votes for deletion" and
>> "demolition beams" with "deletion." The last thing we need is for our
>> Admins to be perceived as Vogons who are "not actually evil, but bad
>> tempered,
>> bureaucratic, officious and callous."
>
> This latest effort at increasing the amount of work one has to do to get
> anything useful done is just helping that perception along. Every time I turn
> around there's another largely political detail I have to be aware of, and
> it's doing anything but encourage me to contribute to Wikipedia.
>
> I've had to put up with pointless procedures on volunteer projects before. I'm
> not about to do it again.

But its not pointless, careless and arbitrary deletions can lead to serious
trouble with contributors who may very well "vote with their feet"

Fred Bauder

http://www.internet-encyclopedia.org


subject: [WikiEN-l] Votes for deletion

body:
Daniel-
> Erik wrote:
>> I choose not to follow this policy as I consider it
>> unnecessary extra work, but I don't mind if others
>> add the boilerplate notice. (We already bend over
>> backwards to inform newbies whenever they make
>> a mistake.) Just don't remove pages I add to VfD
>> or reset the timer because of the missing boilerplate.

> What? So you are saying that we can list items on VfD and /not/ make an
> attempt to inform the author and readers of the page that it is being
> considered for deletion?

I'm saying that an individual user does not *have* to add the boilerplate
notice for the page to be listed on VfD. It's already great if the user
goes to the length of listing a problematic page on the often very long
VfD page. 7 days are more than enough for interested parties to verify
whether the page should indeed be deleted and if it is, it is almost
certainly useless. Of course, someone else may add the notice when they
see it missing.

If you want to make sure users are informed, you'd have to leave a message
on their talk page as well. Certainly this kind of information is helpful,
but from the perspective of Wikipedia as an encyclopedia, the deletion
process can work without it, as it has for many months prior to this
guideline (and I note that many users, including anons, have figured out
that their pages were listed on VfD before we added the notice). It is
similar to other boilerplate notices like "This article is a stub" or
"This is a disambiguation page" -- these are not mandatory, but simply
added by users when they notice them missing.

Making things optional and not mandatory is more wiki-like; it encourages
others to jump in and add the missing text, while not forcing anyone to do
anything. Yesterday I already noticed that you put a comment on someone's
talk page: "You *must* say 'Listed on Votes for deletion' on the page you
are listing. Otherwise the page will not get deleted." (Emphasis yours.)
This kind of admonishment for violation of "rules" should IMHO be kept at
a minimum.

Regards,

Erik


subject: [Wikitech-l] Print stylesheet

body:
tarquin wrote:
> so each page have 2 stylesheets attached instead of 1 is ok -- I keep
> hearing about problems with Apache having too many connections -- won't
> this add to that?

HTTP connections can transfer more than one file. They'll go in the same
lump.

-- brion vibber (brion @ pobox.com)


from_name: Richard Grevers

subject: [WikiEN-l] Votes for deletion

body:
On Sun, 17 Aug 2003 14:43:29 -0700, Daniel Mayer <maveric149 at yahoo.com>
gave utterance to the following:

> Erik wrote:
>> I choose not to follow this policy as I consider it
>> unnecessary extra work, but I don't mind if others add the boilerplate
>> notice. (We already bend over backwards to inform newbies whenever they
>> make a mistake.) Just don't remove pages I add to VfD or reset the timer
>> because of the missing boilerplate.
>
> What? So you are saying that we can list items on VfD and /not/ make an
> attempt to inform the author and readers of the page that it is being
> considered for deletion? How are they supposed to know? I've already
> received several complaints from newbies who had their pages nuked
> without notice.
>
"But the plans have be available at the regional works office at Alpha
Centauri for the past nine hundred years!"

--
Richard Grevers
I'm not lost - I'm directionally challenged


from_name: Jason Richey

subject: [Wikitech-l] New Mailman :-(

in_reply_to:
<bhl6j9$f8m$1@sea.gmane.org>;
	from walter@wikipedia.be on Sat, Aug 16, 2003 at 12:03:53PM +0000

body:
I'm the one who upgraded the mailing list without warning about when I
was going to do it.  I apologize.

Jason Richey

Walter Vermeir wrote:

> I have now noticed, when i approved a posting, that there is a new version
> new in use of mailman.
>
>
> It is good there a update of mailman but why are the listadmins not
> informed about this? Or a least a warning on Wikitech-l?
>
> I have put a lot of work in modifying the look of the listpages so the
> where not so ugly. Now this is al gone.
>
>
> --
> Contact: walter AT wikipedia.be
> Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
> http://www.wikipedia.be
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l

--
"Jason C. Richey" <jasonr at bomis.com>


subject: [Wikitech-l] New Mailman :-(

body:
Jason Richey wrote:
> I'm the one who upgraded the mailing list without warning about when I
> was going to do it.  I apologize.

To be fair, you _did_ warn us you were going to upgrade, but that was a
couple weeks ago. The exact timing was a fun surprise. :)

-- brion vibber (brion @ pobox.com)


from_name: Andre Engels

subject:
[Wikipedia-l] Re: maybe time for a document project, sometime
	in the near future?

body:
On Sat, 16 Aug 2003, Steve Vertigo wrote:

> Annotations are a brilliant idea. Would simple links
> in a page break the concept of a document?  Text in
> view mode doesnt copy the links at all, so it should
> be fine.
>
> But more basic than that, however would be that people
> who are in the process of digitizing a useable book or
> other document can do so in the rough, allowing some
> minor and methodical prepwork to be done in the wiki
> world.  People with similar copies can collaborate,
> like Bittorrent transfers. (not to make any
> comparisons ;)

There already exists something to allow people to cooperate in
creating books for PG - see http://www.pgdp.net/c/default.php

Andre Engels


from_name: Andreas Hoerstemeier

subject: [WikiEN-l] Re: Votes for deletion

body:
Erik Moeller wrote:
> anything. Yesterday I already noticed that you put a comment on someone's
> talk page: "You *must* say 'Listed on Votes for deletion' on the page you
> are listing. Otherwise the page will not get deleted." (Emphasis yours.)
I guess that was my talk page. I doubt it will make any difference for
the page it was about ([[Klosterquelle]]), as it was the one and only
contribution of User:Highelf - so I doubt he will notice that "his" page
is about to be deleted, regardless on wether it is written in the
article or only in VfD.

> This kind of admonishment for violation of "rules" should IMHO be kept at
> a minimum.
I did not take it as a admonishment, only as a hint to do better next
time, which I certainly will.

Bye,
    Andy


subject: [Wikipedia-l] Wikipedia v. Britannica

body:
Jimmy Wales wrote:

>So a question naturally comes to mind - how do our 75,000 >1,500 byte
>articles stack up again Britannica's 75,000 articles?
>
Really, how important is it that we be always looking over our shoulders
to see what Britannica is doing?  IIRC it was in the Landy/Bannister
Miracle Mile race in the 1950s where the leader missed the record
because he looked over his shoulder to see how his competitor was doing;
that action affected his momentum.  Britannica's 75,000 is relatively
static compared to our more dynamic and more adaptable collection.  To
the extent that we have the inferior article on a subject, we also have
the greater flexibility for improvement

>I ask because I continue to work on a plan for a drive to Wikipedia
>1.0, and a big part of that plan involves getting a realistic
>assessment of what a Wikipedia 1.0 will look like, relative to
>Britannica.
>
Again, never mind "relative to Britannica".  It may be more important to
know who our target audience is going to be, and what kind of
markettiing strategy will reach that audience.  What retail price will
the public find acceptable, and how does that relate to our costs of
production and shipping?  What infrastructure do we need to support the
sales that we do get?

I believe that our deficiencies can be turned into marketting assets.
 WP1.0 would be a "snapshot" of what Wikipedia is at a given point in
time to which is added a promise of improvement.  Instead of the cash
rebate that Britannica offers,  we can offer some number of revised
disks to be mailed in the future .

>If I end up setting a 'target date' for Wikipedia 1.0 of 1 year in the
>future, what might we realistically expect to achieve?  What if I set
>the 'target date' for 2 years in the future?
>
>What I'd like to find out is that we have a realistic chance of having
>a Wikipedia 1.0 release 1 year from now that rivals Britannica.  But
>there's no need to hurry, if it will take 2 years or 5 years, that's
>how long it will take.
>
I think the target date for WP1.0 is largely arbitrary.  It should be
chosen for the best market impact.

Ec


subject: [Wikipedia-l] [Announce-l] New mailman

body:
Hello,

The mailing list software at Wikipedia has been upgraded.  Though
there seem to still be some problems with new subscribers, everything
should work reasonable well for all of the current listmembers.

I realize it would have been more prudent of me to say "I'll be
upgrading the mailing list software on Friday, between 2pm and 8pm
PST", and I'd like to apologize to anyone who was adversely affected by the
upgrade for my lack of notification.  I'll be more considerate in the future.

--
"Jason C. Richey" <jasonr at bomis.com>

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


subject: [Wikitech-l] [Announce-l] New mailman


subject: [Wikipedia-l] Wikipedia v. Britannica

body:
Ray Saintonge wrote:
> >So a question naturally comes to mind - how do our 75,000 >1,500 byte
> >articles stack up again Britannica's 75,000 articles?
> >
> Really, how important is it that we be always looking over our shoulders
> to see what Britannica is doing?

Not very important!  However, it's a nice yardstick and until we leave
them in the dust, which we will, it's the gold standard to which we
aspire.  :-)

> Again, never mind "relative to Britannica".  It may be more
> important to know who our target audience is going to be, and what
> kind of marketing strategy will reach that audience.  What retail
> price will the public find acceptable, and how does that relate to
> our costs of production and shipping?  What infrastructure do we
> need to support the sales that we do get?

Well, the beauty of free software is that we really don't have to give
such issues a lot of thought.  Linus lets RedHat worry about that sort
of thing.  I'll let someone else worry about it.  That's a
half-facetious answer, but really, our goal in producing 1.0 isn't
tied much to marketing issues.

> I think the target date for WP1.0 is largely arbitrary.  It should be
> chosen for the best market impact.

Well, I certainly sympathize with what you're saying, but I think we
should think long-term.  I'd rather wait 5 years before calling
something 1.0 and releasing it for print publication and so on, and
get it right, than to rush something out the door now.  We don't face
pressure from the marketing department to deliver early, and that's a
good thing.

--Jimbo


subject: [Wikipedia-l] Wikipedia v. Britannica

body:
Jimmy Wales wrote:

>As a quick followup, Britannica also claims that the 32 volume print
>encyclopedia has 44 million words.
>
44,000,000 / 75,000 = 586 words per article

>It seems clear to me that we are already "in the ballpark" of the size
>of Britannica.  Quality is, of course, an entirely different question.
>I think we are often superior and often drastically inferior.  I
>susppect that our coverage contains strange and conspicuous 'holes' if
>we went through it via a "top down" approach, i.e. take lists of major
>topics and see if we've covered them.
>
We already have many "List of ... topics" articles, as well as many
other lists that can serve as most wanted lists.  We already have a
mechanically generated list of "Wanted pages" that works sometimes.  A
human generated most wanted list would also be very welcome if it's not
allowed to become so long that it's useless.

When I first joined Wikipedia I made extensive use of the "Wanted pages"
just to find things to do.  A more experienced Wikipedian never runs
short of things to do, but even then looking at the Wanted pages for
something a little different can break monotonous habits.   In other
words "Wanted pages" is a lot more important to newbies than to
veterans; nothing works better for retaining new contributors than to
feel that they can contribute something that somebody else wants.  It
would be nice to see that feature working a little better than has been
the case in recent months.

As I said in my previous response, I see a CD edition as a snapshot of
WP at a given moment in time.  I would suggest that there be a tag for a
"print approved" version of any article  This is a version that has been
reviewed for such things as liabellous comments, copyright infringements
or adherence to NPOV.  The snapshot would be a collection of all the
latest print approved  versions stripped of dead links.  WP1.0 will
clearly be much smaller than its successors, but that's fine too because
we can continue with a maintainable promise for better things to come.

Try as we might it is inevitable that unwanted material will creep into
the published versions.  This could be minimized by having a lot of paid
staff to do nothing but checking for this stuff, but this is not a
cost-effective strategy consistent with our volunteer nature.  To
minimize the damage from such incidents, I would recommend short
production runs that would ensure that supplies would be exhausted
before the expiry of any safe harbor periods.  The next production run
would have the formally questioned material excised while the matter is
being reviewed; it can always be re-inserted at a later time if the
challenge turns out to be groundless.  Being seen as acting quickly on
these problems is a lot more important than going to extraordinary
lengths to remove things where we only guess that it '''may''' be
offending.   Obviously offending material would still regularly be excluded.

Ec


subject: [Wikipedia-l] Re: Exciting new statistics!

body:
Erik Zachte wrote:
> I will add this, except for active wikipedians. Their number is not
> twice as high in four weeks than in two weeks, so no forecast possible.

Not directly, but it is possible to do so indirectly.  Doing it well
might be complex, but a rough guess could be gleaned from looking at
'new actives per day' and extrapolating for the month.

Of course, 'new actives per day' for a given month is probably very
high on the first day, and lower through the month, as all the
regulars are eventually 'accounted for'.

Well, anyway, it's easy for us to ask for MORE when you've given us
such a great GIFT already!  I, for one, really appreciate everything
that you've done here, it's really amazing.  :-)

--Jimbo


subject:
[Wikitech-l] http://**.wikipedia.com/tarballs/wiki.tar.gz (Not
	available) ???

in_reply_to:
<007c01c363af$540d4bd0$72befdd0@impressario>;
	from jjbowks@adam.cheshire.net on Sat, Aug 16, 2003 at 12:31:56AM
	-0400

body:
Sorry for the late response...

we have a script running which is supposed to update tarballs for
wikis in these languages:
ca de eo es fr he it ja nl pl pt ru sv zh

Several of these have moved to non-UseMod and would thus have
non-useful tarballs (though they are likely still in place).  The
others should have tarballs in XX.wikipedia.com/tarballs/wiki.tar.gz.

This is only true of those subdomains that resolve to 130.94.122.195.

Jason Richey

Jay Bowks wrote:

> Hey, Jason,
> Brion suggested I ask you the question...
>
> Where are the backups for the languages
> still in the http://**.wikipedia.com domain
> kept? Are they downloadable?
>
> Thanks in advance for info you can
> send my way...
> w/ regards,
> Jay B.
>
> ----- Original Message -----
> From: "Brion Vibber" <vibber at sal-sun012.usc.edu>
> To: <wikipedia-l at wikipedia.org>
> Sent: Friday, August 15, 2003 5:58 PM
> Subject: Re: [Wikipedia-l] Wiktionary backups
>
>
> > On Fri, 15 Aug 2003, Jay Bowks wrote:
> > > Hey Brion,
> > > Just a question about backup dumps...
> > > Where are the backups for the languages
> > > still in the http://**.wikipedia.com domain
> > > kept? Are they downloadable?
> >
> > Where they exist, they should be at
> > http://**.wikipedia.com/tarballs/wiki.tar.gz
> >
> > I don't have access to that server, so until such time as they are
> > converted, ask Jason about any problems.
> >
> > -- brion vibber (brion @ pobox.com)
> >
> > _______________________________________________
> > Wikipedia-l mailing list
> > Wikipedia-l at wikipedia.org
> > http://www.wikipedia.org/mailman/listinfo/wikipedia-l
> >
> ----- Original Message -----
> From: "Jason Richey" <jasonr at bomis.com>
> To: "Wikipedia Technical Mailing List" <wikitech-l at wikipedia.org>
> Sent: Friday, August 15, 2003 8:20 PM
> Subject: [Wikitech-l] test
>
>
> > This is a test of the upgraded mailman.
> >
> > --
> > "Jason C. Richey" <jasonr at bomis.com>
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikipedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l

--
"Jason C. Richey" <jasonr at bomis.com>


from_name: J. Noel Chiappa

subject: [WikiEN-l] Votes for deletion

body:
     Erik wrote:

     > I choose not to follow this policy as I consider it unnecessary extra
     > work, but I don't mind if others add the boilerplate notice.

Umm, everyone, this is a computer we're dealing with here. It's good at
repetitive, mindless tasks. (And, yes, I know some poor overworked soul is
going to have to write the code... :-)

Why not add a button that i) adds said notice to the top of the page, and ii)
adds the page to the bottom of VfD? You could go through an intermediate
screen that offers a little edit window for you to add whatever message to
the listing, if any, you feel is appropriate, and has Confirm/Cancel buttons.
That'll make everybody's life even easier than it is now, even.

This doesn't address the policy questions, but we should be able to dispose
of the practical ones.

         Noel


from_name: tarquin

subject: [Wikitech-l] Print stylesheet

body:
Brion Vibber wrote:

> tarquin wrote:
>
>> A reorganisation like this might be easiest to do after we convert to
>> a template system using "smarty".
>
implementing smarty is beyond my capabilities -- I'm not good enough
with PHP, and I don't have a test version of Wikipedia running becuase
I'm on Windows.
If another developer is able to work on the PHP side of this, I can take
care of converting our current skins to templates.
(and I'm looking into setting up a linux box :) -- though I appreciate
our PHP gurus are busy with 1001 other things. What's happened to
Lighting, who first suggested this? (
http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/005004.html )

>> b) create a "global" stylesheet of elements that work across all skins.
>
> this is something I would like to implement.
>
> Yes, please work on this!

so each page have 2 stylesheets attached instead of 1 is ok -- I keep
hearing about problems with Apache having too many connections -- won't
this add to that?

I've set up a page on meta for all this sort of thing:
http://meta.wikipedia.org/wiki/Skins
if anyone can think of things that could be usefully moved to a global
stylesheet, please add it to the list there.


from_name: Delirium

subject: [Wikipedia-l] Wikipedia v. Britannica

body:
Jimmy Wales wrote:

>I ask because I continue to work on a plan for a drive to Wikipedia
>1.0, and a big part of that plan involves getting a realistic
>assessment of what a Wikipedia 1.0 will look like, relative to
>Britannica.
>
>If I end up setting a 'target date' for Wikipedia 1.0 of 1 year in the
>future, what might we realistically expect to achieve?  What if I set
>the 'target date' for 2 years in the future?
>
>
 From this and another of your posts that suggested 'retail' (or was
that someone else's post?) am I right in inferring that WP1.0 is
something along the lines of the "Sifter" project that was proposed
earlier?  Or is it instead just a marker for the current Wikipedia?  The
latter would seem unsuited to freezing as a 1.0 though -- you wouldn't
want to ever publish a print encyclopedia that contained even one
article whose entire contents are "dskafldsafkjhdanz" or "i like ham",
and the live Wikipedia invariably has a few of these.  You wouldn't even
really want to put that sort of thing on a CD-ROM.  You wouldn't want to
put blatantly factually incorrect information on a CD-ROM either, which
is a bit of a problem (I've found plenty of Wikipedia articles with
wrong dates and such).

Part of the advantage of Britannica is that you can be reasonably sure
that when you read an article that states a fact, that fact is correct,
or at least at the time of publication was believed to be correct by the
experts in the field (no one can account for future discoveries, of
course).  If it is intended to rival Britannica, WP1.0 will have to have
a similar level of reliability -- when it says someone was born on
January 7, 1845, they better have actually been born on that date --
not, say, January 7, 1854.  And when something is mentioned as a
mainstream physics topic, it had better actually be one, not a fringe
theory.

This is really what I see as the major obstacle in rivalling Britannica
-- the sheer amount of information is a problem that will fix itself
given some time.  But to have *reliable* information is more difficult.
Right now I use Wikipedia as a way to find out about topics I didn't
know about, but not as an authoritative source -- I always check
everything of importance (whether factual information or discussion of,
say, philosophical topics) with another encyclopedia or a book before
taking it as true.  This is somewhat diminished on major articles -- I
can be reasonably sure that the WW2 article is accurate, as it is
high-profile enough and has enough people reading it.  But for the
articles on less high-profile topics, I'm not nearly as confident.

-Mark