subject: [Wikipedia-l] Re: Parsing

body:
On Sat, Jul 27, 2002 at 07:43:22AM -0700, Toby Bartels wrote:
> Jan Hidders raved (I assume he meant "ranted"):

Er, yes, I did. That's one of my problems when I start ranting; I get
inarticulate. :-)

> The question isn't how easy "'''" is to learn.
> The question is how easy "" is to learn.
> The answer to that is, it's pretty darned easy;
> therefore, since people will try it, it should be allowed.

Just for clarity, I wasn't arguing that simple HTML like  is more
difficult than ''', but just reacting to the suggestion of the reverse. It's
when people start using
 and complex
s and <VAR> and
when things start becoming harder to understand and edit for the average
user. Other than that there are also technical reasons such as the
simplicity of the parser and the control that we would have over the HTML
that we send to the browsers of the reader.

-- Jan Hidders


list: wikipedia-l

source: pipermail-mbox

from_name: Daniel Mayer

subject: [Wikipedia-l] Re: multi-headed VANDALS + PANIC button

body:
On Monday 29 July 2002 12:01 pm, you wrote:
> I actually do already have a "lock the database" button available
> to developers; maybe I should make that available to sysops as well
> (as long as "unlock" is as well, of course)?
>
> I also need to start thinking about some back-end stuff like the cron
> job for making more frequent backups.

Cool. This would of course have to be approved by our benevolent dictator,
er, benefactor Jimbo. Is this feature bug-free enough to trust mere sysops
with?

Hopefully such a panic button will /never/ have to be used.  But having a
"protect all pages" button will give me, and I suspect others, some peace of
mind.

However, there will have to be severe limitations on any use of this function
though. If a sysop and the community can reasonably keep up with such an
attack this feature should /not/ be used. But 10 vandalized articles or more
a minute over multiple minutes would begin to be very taxing, esp. if a bunch
of different IPs are being used by the vandal.

--mav


list: wikitech-l

from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] rsync for mirroring

body:
Could you make international wikis available via rsync ?
It will be much easier to make local mirrors in that case,
and it will be possible to sync more often than once a day.


from_name: Neil Harris

subject: [Wikipedia-l] Proposal: new Cologne Blue final

body:
Dear all,

This is my latest, and I hope final, mock-up  rendition of Cologne Blue
that I  intend to offer to replace the existing implementation of
Cologne Blue.

I enclose a mock-up page: this represents the final look intended in
standard-compliant CSS browsers like Mozilla and IE 6, but will probably
not work properly in non-CSS-aware browsers yet. There's still lots to
do, but the only way to find out is not to build a better mock-up, but
to write the working code.

I realise that this design is not perfect, but it is probably
nicer-looking than the existing implementation, and I'm reading the code
for the new software to see how to make the changes in an evolutionary
way will work with cross-browser support.

I'm also considering the idea of doing a version of this with tables
alone for old browsers that ignore or munge CSS.
If I do the CSS right, the CSS version should work OK for browsers like
Lynx.

Can anyone help me with how to go about contributing code, and where and
how to test it? The first thing I'll need to do is just to clone an
existing style, and call it something like "Cologne Beta", prior to
changing it step-wise into real code.

Once I have something up and running, then we can start voting for
features. As all code will of course be GPL, if you dislike it enough,
you'll be able to change it yourself.

Regards,

Neil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020729/f0397e8a/attachment.html


subject: [Wikitech-l] Proposal: new Cologne Blue final

body:
Dear all,

This is my latest, and I hope final, mock-up  rendition of Cologne Blue
that I  intend to offer to replace the existing implementation of
Cologne Blue.

I enclose a mock-up page: this represents the final look intended in
standard-compliant CSS browsers like Mozilla and IE 6, but will probably
not work properly in non-CSS-aware browsers yet. There's still lots to
do, but the only way to find out is not to build a better mock-up, but
to write the working code.

I realise that this design is not perfect, but it is probably
nicer-looking than the existing implementation, and I'm reading the code
for the new software to see how to make the changes in an evolutionary
way will work with cross-browser support.

I'm also considering the idea of doing a version of this with tables
alone for old browsers that ignore or munge CSS.
If I do the CSS right, the CSS version should work OK for browsers like
Lynx.

Can anyone help me with how to go about contributing code, and where and
how to test it? The first thing I'll need to do is just to clone an
existing style, and call it something like "Cologne Beta", prior to
changing it step-wise into real code.

Once I have something up and running, then we can start voting for
features. As all code will of course be GPL, if you dislike it enough,
you'll be able to change it yourself.

Regards,

Neil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20020729/f0397e8a/attachment.html>


from_name: Jimmy Wales

subject: [Wikipedia-l] multi-headed VANDALS

in_reply_to: <20020728042014.OCWN24728.rwcrmhc51.attbi.com@there>; from maveric149@yahoo.com on Sat, Jul 27, 2002 at 09:14:13PM -0700

body:
Daniel Mayer wrote:
> Jimbo you are an ISP owner, what do you think?

Well, we're more of a search engine.  The closest I have to "customers" are you
folks.  :-)

--Jimbo


subject: [Wikipedia-l] Copyright question

in_reply_to: <3D443C43.5040003@telus.net>; from saintonge@telus.net on Sun, Jul 28, 2002 at 11:47:31AM -0700

body:
Ray Saintonge wrote:
> Copyright in photographs also links to the ownership of the original
> negative or plate.  Two independently photographed images of the "Mona
> Lisa" would not impinge on each other's copyrights.  If I remember
> correctly  the Louvre does not ban photography, but does ban flash
> equipment and tripods.

I don't like such policies, but I do understand them.  The museums say
a lot of sanctimonious tripe about wanting to protect the public from
poor reproductions, but that's code from "protect ourselves from
someone selling high quality reproductions without paying us".

But, for our encyclopedic purposes, a pretty decent photo is really
all we need.  We're not really the right place to serve as a
repository of GFDL extreme-high-quality digital photos of
not-copyrighted art, although such a thing should exist and I would be
excited to hear about it if it did.

But, we're doing something different I think.

--Jimbo


from_name: The Cunctator

body:
On 7/29/02 2:51 PM, "Neil Harris" <usenet at tonal.clara.co.uk> wrote:
> I agree that hard security leads to an arms race. But leaving the
> Wikipedia as a "soft target" with apparently magical self-healing
> properties should make the experience no fun for script kiddies:
> * they see that "vandalism" is easy, and no challenge
> * they should also see (eventually) that it is futile
>
I strongly agree.


from_name: Ray Saintonge

body:
Neil Harris wrote:

> This is my latest, and I hope final, mock-up  rendition of Cologne
> Blue that I  intend to offer to replace the existing implementation of
> Cologne Blue.
>
> Can anyone help me with how to go about contributing code, and where
> and how to test it? The first thing I'll need to do is just to clone
> an existing style, and call it something like "Cologne Beta", prior to
> changing it step-wise into real code.
> Neil

It looks better already.  You might even get some of us Luddites to
change over.  The serifed type face is indeed easier to read.

In view of the page you used for a sample, the name "Cologne
Enlightened" has a ring to it. :-))

Eclecticology


body:
Vicki Rosenzweig wrote:

> At 03:34 PM 7/29/02 +0100, you wrote:
>
>> Dear all,
>>
>> This is my latest, and I hope final, mock-up  rendition of Cologne
>> Blue that I  intend to offer to replace the existing implementation
>> of Cologne Blue.
>>
>> I enclose a mock-up page: this represents the final look intended in
>> standard-compliant CSS browsers like Mozilla and IE 6, but will
>> probably not work properly in non-CSS-aware browsers yet. There's
>> still lots to do, but the only way to find out is not to build a
>> better mock-up, but to write the working code.
>
>
> I don't like using so much of the screen for editing-related stuff
> before the reader gets to
> the content of the article. I'd take at least "special pages" to the
> bottom or one side. Ideally,
> I'd have one row of links along the top, something like
>
> Find | Browse | Main page | Recent changes | Random page | Current
> events | * Edit this page * |My settings
>
> and move the rest to the bottom or one side.
>
> (If I should have posted this earlier, I apologize.)
>
> For the record, I'm looking at things in Netscape 6, with CSS and Java
> but not Javascript.
>
> --
> Vicki Rosenzweig
> vr at redbird.org
> http://www.redbird.org <http://www.redbird.org/>

Ah. That shouldn't happen in the finished version. I think you're seeing
the alternate rendering: almost all the menus should appear at the left.
I've sent you a screenshot of the intended rendering.

Neil


subject: [Wikitech-l] rsync for mirroring

body:
On Mon, Jul 29, 2002 at 02:50:20PM +0200, Lars Aronsson wrote:
> On Mon, 29 Jul 2002, Tomasz Wegrzanowski wrote:
> > Could you make international wikis available via rsync ?
>
> An exciting idea.  Would you even try Unison for this?
> Is there any benefit to using Unison over rsync for this kind of
> uni-directional application?
>
> http://www.cis.upenn.edu/~bcpierce/unison/

It doesn't seem to have any advantage and is less popular,
so I'd rather choose rsync.


from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] Interesting bug report

body:
Thought you guys might be amused by this bug
report I just received:

  From the look of the Wikipedia web site, it seems
  that any visitor can edit the content!
  That can't be correct!


body:
lcrocker at nupedia.com wrote:

>>What I do fear is some script kiddy with a couple dozen rotating
>>proxies and a ship-load of bots flooding the database with junk and
>>overwriting 20 articles a minute. A panic button to lock-down the
>>site would then be nice (Sorry, I can't protect pages fast enough).
>>Then that would give a sysop the time needed to block all the IPs
>>of the vandal. But again, I don't think we are at that point yet.
>>
>>
>
>I actually do already have a "lock the database" button available
>to developers; maybe I should make that available to sysops as well
>(as long as "unlock" is as well, of course)?
>
>I also need to start thinking about some back-end stuff like the cron
>job for making more frequent backups.
>
>
>
Whilst I was filling the database up with crud, I noticed that it still
took days and days to reach 100,000 articles, even running several
submit processes in parallel. Providing that sysops have powerful tools
ready for rolling back changes, they will have plenty of time to react.

I agree that hard security leads to an arms race. But leaving the
Wikipedia as a "soft target" with apparently magical self-healing
properties should make the experience no fun for script kiddies:
* they see that "vandalism" is easy, and no challenge
* they should also see (eventually) that it is futile

Neil


subject: [Wikitech-l] Supporting horrible browsers

body:
Supporting old, horrible browsers.

I have some current stats that suggests that IE 4.x and Netscape 4.x now
represent 2% and 3% of users, respectively.

Here's what I propose to do with Cologne Blue.

1. Browser-sniffing: detect these, and only these, broken browsers, at
the webserver.
2. For these browsers alone, generate an XHTML page using tables for
layout, and minimal CSS for typography and colours.
3. For all other browsers, generate an XHTML page using CSS for layout,
and typography, and colours. (Oh, and a table for the header, but that's
OK).

Then:
1. Modern standards-compliant browsers will show the site as intended.
2. Very old browsers, text-only browsers, web spiders, and accessibility
systems will show the site in the best backwards-compatible rendition
possible, as the site will use nice old-fashioned HTML codes inside all
the fancy layout stuff, ignoring the CSS completely.
3. The brain-dead browsers listed above will show a reasonable rendition
of the site, for as long as it takes for their market share to fall near
zero.

I think that 90% of the layout code can be re-used in a single skin
file, provided that I can get an indication if the browser is one of the
broken ones.

Does this seem like a reasonable approach? And does anyone have any
GPL'd user-agent parsing PHP code?

Neil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20020730/3858b03e/attachment.html>


from_name: Brion VIBBER

subject: [Wikitech-l] <nowiki>

body:
Jan.Hidders wrote:

>Are the <nowiki> tags still needed in the script? I'm asking this because
>1. I'm having trouble getting them into the formal syntax
>
Of course they're still needed! How else are we supposed to include wiki
markup as text in a wikipage that's not overly burdenson? (ie, using
numeric character entities instead of  special wiki symbols.)

>2. They are a bit of a security risc because the allow users to get things
>like javascript on a page.
>
If that's the case, that's a serious bug. <nowiki> should mean no *wiki*
markup interpretation, not no *HTML* safeguarding.

-- brion vibber (brion @ pobox.com)


from_name: Stephen Gilbert

subject: [Wikipedia-l] Re: Parsing

body:
--- "Jan.Hidders" <hidders at uia.ua.ac.be> wrote:
> On Sat, Jul 27, 2002 at 04:24:17PM +0100, tarquin
> wrote:
> >
> > I would hesitate before deprecating  and  in
> wiki markup, but I
> > change those to the equivalent ' whenever I see
> them, and I don't think
> > they should be encouraged.
>
> I would not hesitate here. If you have two notations
> for the same thing
> people who want to write have to know them both
> because they are going to
> encounter them and therefore have to know what they
> mean and if they are the
> same or not. Having one notation is simpler for
> everybody.
>
> -- Jan Hidders

What if you want a bold italic font? I know of only
three ways to do it on Wikipedia, and none are pure
wiki syntax: ''Bold italic'', '''Bold
italic''', or Bold italic.

Stephen G.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


from_name: Fred Bauder

subject: [Wikipedia-l] ISBN links

body:
On the page [[Native American]] one of the books in '''Further Reading'''
has an external link which takes you to this page:

http://www.pricescan.com/books/bookDetail.asp?isbn=0838903533

(Only give a header and a blank page now but in the past has had a list of
bookstores and prices.)

When you edit the page you don't see any code that would generate that link.

If I were to put in a link to find a book I would probably do one for an
Addall search or an ABEbooks search since I find those work best.

http://www.addall.com generates income by being an affiliate of bookstores
as pricescan probably does too.

http://dogbert.abebooks.com is a used book listing service.

So what's going on and what do we want to go on?

Fred Bauder


body:
> I agree that hard security leads to an arms race.
> But leaving the
> Wikipedia as a "soft target" with apparently magical
> self-healing
> properties should make the experience no fun for
> script kiddies:
> * they see that "vandalism" is easy, and no
> challenge
> * they should also see (eventually) that it is
> futile
>
> Neil

I completely agree. The people over at MeatballWiki
have spent a lot of time developing and discussing
wiki security:

http://www.usemod.com/cgi-bin/mb.pl?SoftSecurity
http://www.usemod.com/cgi-bin/mb.pl?OnWikisAndSecurity

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] Interesting bug report

body:
--- lcrocker at nupedia.com wrote:
> Thought you guys might be amused by this bug
> report I just received:
>
>   From the look of the Wikipedia web site, it seems
>   that any visitor can edit the content!
>   That can't be correct!

My god! Lee, you idiot! Lock that down quick!
"Improved software" indeed...

Stephen G.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] Interesting bug report

in_reply_to: <200207300048.g6U0mQA22842@ross.bomis.com>; from lcrocker@nupedia.com on Mon, Jul 29, 2002 at 05:48:26PM -0700

body:
Now *that's* funny.  :-)

lcrocker at nupedia.com wrote:

> Thought you guys might be amused by this bug
> report I just received:
>
>   From the look of the Wikipedia web site, it seems
>   that any visitor can edit the content!
>   That can't be correct!
>
>
>
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] ISBN links

body:
At the present time, no ISBN links on the wikipedia are generating any income
for the Wikipedia.  Perhaps in the future that should change, but we have to
be very careful about such things, and in my experience, the amount of money from
such links is so low that it isn't really that important... not important enough to
damage our independent reputation.

Fred Bauder wrote:

> On the page [[Native American]] one of the books in '''Further Reading'''
> has an external link which takes you to this page:
>
> http://www.pricescan.com/books/bookDetail.asp?isbn=0838903533
>
> (Only give a header and a blank page now but in the past has had a list of
> bookstores and prices.)
>
> When you edit the page you don't see any code that would generate that link.
>
> If I were to put in a link to find a book I would probably do one for an
> Addall search or an ABEbooks search since I find those work best.
>
> http://www.addall.com generates income by being an affiliate of bookstores
> as pricescan probably does too.
>
> http://dogbert.abebooks.com is a used book listing service.
>
> So what's going on and what do we want to go on?
>
> Fred Bauder
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
> From milkeggs at inMail.sk () Tue Jul 30 02:44:24 2002


subject: [taw@users.sourceforge.net: Re: [Wikitech-l] rsync for mirroring]

body:
Any opinions from wikitech-l about this?

----- Forwarded message from Tomasz Wegrzanowski <taw at users.sourceforge.net> -----

From: Tomasz Wegrzanowski <taw at users.sourceforge.net>
Date: Tue, 30 Jul 2002 04:08:53 +0200
To: Jimmy Wales <jwales at bomis.com>
Subject: Re: [Wikitech-l] rsync for mirroring

On Mon, Jul 29, 2002 at 03:40:12PM -0700, Jimmy Wales wrote:
> What do we need to do on our end?

This is just one of many ways of doing it.
You should probably play with logs, connection limits,
running on lower permisions and stuff like that later,
but it should work without this.

Obviously you should add all Wikipedias to list (i have only 3 here)
and use correct paths.

1. install rsync
2. ensure that /etc/services contains this line (if not either add
   this line or write port in /etc/inetd.conf numerucally):
rsync           873/tcp                         # rsync
3. create /etc/rsyncd.conf containing something like that:
read only = yes

[pl]
path = /home/taw/local/tmp/wiki-pl/
comment = Polish Wikipedia

[de]
path = /home/taw/local/tmp/wiki-de/
comment = German Wikipedia

[eo]
path = /home/taw/local/tmp/wiki-eo/
comment = Esperanto Wikipedia
4. put following line in /etc/inetd.conf
rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon
5. restart inetd

Now to check:

$ rsync localhost::
pl              Polish Wikipedia
de              German Wikipedia
eo              Esperanto Wikipedia
$ rsync localhost::pl
drwxrwxr-x         288 2002/01/09 22:22:50 .
-rw-rw-r--          19 2001/09/26 16:23:32 .htaccess
drwxrwxr-x         112 2001/10/02 13:07:29 RCS
-rw-rw-r--         302 2000/07/18 20:40:13 hos.png
-rw-rw-r--         235 2001/09/26 17:49:14 index.html
drwxrwxr-x          72 2001/10/18 01:37:30 lib-http
-rwxrwxr-x          67 2001/09/26 18:05:02 showtr
drwxrwxr-x          72 2002/01/12 20:26:36 temp
-rwxrw-r--        1160 2001/04/08 18:34:10 umtrans.pl
drwxrwxr-x         592 2001/11/24 09:52:33 wiki
$

----- End forwarded message -----


from_name: wojtek pobratyn

subject: [Wikipedia-l] Interesting bug report

body:
----- Original Message -----
From: <lcrocker at nupedia.com>
To: <wikipedia-l at nupedia.com>
Sent: Tuesday, July 30, 2002 2:48 AM
Subject: [Wikipedia-l] Interesting bug report

| Thought you guys might be amused by this bug
| report I just received:
|
|   From the look of the Wikipedia web site, it seems
|   that any visitor can edit the content!
|   That can't be correct!

I've been trying to point this out for over a year
now and no one has been listening to me;-)

WojPob


from_name: Poor, Edmund W

subject: [Wikipedia-l] Script Kiddies/Panic Button

body:
Hi, everybody. I thought it's about time I joined the list.

Instead of just a lockout button, why not also provide admins with the
ability to:

a)       Limit edits to logged-in users, or

b)       Limit the frequency of edits to "one edit per minute" for any
given user or any given IP

(You could adjust the time value of one minute in option B above.)

--Ed Poor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020730/9d0ed4b5/attachment.htm


from_name: Anthere

subject: [Wikipedia-l] Deletion and copyrighted issues

body:
 We have a little issue on the fr.wikipedia, and I wondered whether that kind of pb already occurred to you (probably did), and what you would do about it.
Some time ago, a new user, Mulot, joined us. She started many articles all related to religion. These articles were apparently results of collaborations between her and other people she is related to. Very valuable stuff imho. However, it appears that she doesnot fit with the wiki project very well (hum, she got pretty hot with our comments and modifications, though frankly light). Today, she just blew the lid off (so to speak, would you say that ?). Put all her articles in the list ?to be deleted?. And said she wanted all of them to be deleted, as well as the talk pages.

When she said she would delete all if we did not do it (tomorrow, Paris time 10:41, LOL)., Aoineko answered of course she was not the owner of the articles, so (beside the technical issue of deletion) she had no ?right? upon them. She, then, threatened that the articles could ?reveal? themselves copyrighted.

This afternoon, she started to delete 5 pages, her personal one, her discussion page, three discussion pages and an article. Aoineko, fortunately, reverted the vandalism.

So the questions I would ask

-         what rights does she have on pages ?
I specifically think of her personal page. Is a personal page somebody?s property ? Intuitively, I would say yes, and I would say someone has the right to delete his own page as well as the talk page attached. What is the policy about that ?
What is the ?policy? about discussion pages ? Is one?s content of a discussion page personal or not ?

-         what can we do against a deletion campaign ? Is there a solution other than Aoineko keeping restoring pages until she gets tired ? (in case you ask, she is probably not on a fixed IP)

-         what about the threat of the articles finally revealing themselves copyrighted ?

 To say the least, I am very troubled

---------------------------------
Do You Yahoo!?
Yahoo! Health - Feel better, live better
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020730/8866b601/attachment.htm


subject: [Wikipedia-l] Re: [Intlwiki-l] Deletion and copyrighted issues

body:
Anthere wrote:
>  We have a little issue on the fr.wikipedia, and I wondered whether that
> kind of pb already occurred to you (probably did), and what you would do
> about it.
>
> Some time ago, a new user, Mulot, joined us. She started many articles
> all related to religion. These articles were apparently results of
> collaborations between her and other people she is related to. Very
> valuable stuff imho. However, it appears that she doesnot fit with the
> wiki project very well (hum, she got pretty hot with our comments and
> modifications, though frankly light). Today, she just blew the lid off
> (so to speak, would you say that ?). Put all her articles in the list
> ?to be deleted?. And said she wanted all of them to be deleted, as well
> as the talk pages.
[...]
> So the questions I would ask
>
> -         what rights does she have on pages ?

Under US copyright law, anything you write is your intellectual property
and the copyright is owned by you unless you explicitly give or sell it
away. I believe EU copyright law is the same in this respect, so there
oughtn't to be any strange complications due to location of the author
vs location of the server.

BUT... for anything she submitted to Wikipedia, she implicitly agreed to
license it under the GFDL by not ignoring this message:

   IMPORTANT : Toutes les contributions Wikipedia sont publies sous la
   license "GNU Free Documentation License". Si vous n'acceptez pas que
   votre article soit modifi et redistribu sans votre autorisation, ne
   nous l'envoyez pas. Vous nous promettez galement d'tre l'auteur de cet
   article, ou de l'avoir recopi d'une source de donnes du domaine
   public. N'UTILISEZ PAS SANS PERMISSION DES DONNEES PROTEGEES PAR DES
   DROITS D'AUTEUR !!

The license can't really be withdrawn as far as I can tell; she can
still do whatever she wants with her original text, but can't legally
force Wikipedia to remove her material *unless she can prove that the
license was not valid*. (Ie, that she did in fact not own the copyright
and thus could not license it under GFDL, or possibly that the
click-through license notice was not really binding.)

I'm not a lawyer, though.

> I specifically think of her personal page. Is a personal page somebody?s
> property ? Intuitively, I would say yes, and I would say someone has the
> right to delete his own page as well as the talk page attached. What is
> the policy about that ?
> What is the ?policy? about discussion pages ? Is one?s content of a
> discussion page personal or not ?

Technically, personal and discussion pages are under the same GFDL
license as the rest of the site. Someone duplicating Wikipedia (say,
mirroring the site or pressing CD-ROM versions) would be free to include
that material, or even reuse and modify it.

But as they're not _encyclopedia articles_ and are outside the primary
purpose of the encyclopedia, I say it's perfectly fine if someone wants
to delete their own personal page or their contributions on talk pages.
(Whereas deleting an _article_ is detrimental to the project, and
therefore rude and controversial.)

> -         what can we do against a deletion campaign ? Is there a
> solution other than Aoineko keeping restoring pages until she gets tired
> ? (in case you ask, she is probably not on a fixed IP)
>
> -         what about the threat of the articles finally revealing
> themselves copyrighted ?
>  To say the least, I am very troubled

If she in fact did not own the copyright and was not legally able to
license her contributions under GFDL, we can't keep them. Of course,
that would be equally true if she were still in love with the project!

If there's really doubt in the matter, it might be worthwhile to rewrite
the articles from scratch using the originals only as sources of
information. This should both be unambiguously legal and soothe her anger.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Sysop status

body:
tarquin wrote:
> Before I too jump on the application bandwagon ;) -- what can sysops do
> that mortals can't?

As I wrote recently on [[User talk:Sjc]]

? ...if this isn't already documented in a central and accessible place,
please feel free to do so. The "sysop" powers are:

     * Block and unblock IPs
     o Related to this, ability to see the last octet of IP addresses in
edits by anonymous users, which is normally hidden to discourage random
people haX0ring your IP. (No ability to see the IP address of logged-in
users, as this is not stored in the database -- compare with the old
usemod wiki software, where both anonymous and logged-in users had their
full unfettered hostnames listed to any scmuck who wandered by.)
     * Delete pages (there's an etiquette to this, see policy pages; but
people do sometimes take shortcuts, deleting empty pages with no history
more freely)
     * Delete uploaded files
     o There's also a revert-to-previously-uploaded-version feature, I'm
not sure if this is sysop or everybody.
     * Move/rename pages preserving the edit history (planned to be
allowed for all or most users, I prefer all)
     * Protect and unprotect pages (locking them against edit by other
users who are not also logged in as sysops). Traditionally this was in
fact used only on the main page, but some of the policy pages are also
locked, which I'm not sure I approve of. Here are all the pages
currently protected:
           o Wikipedia:Upload_log
           o Wikipedia:Article_deletion_log
           o Wikipedia:What_Wikipedia_is_not
           o Main_Page
           o Wikipedia:Neutral_point_of_view
           o Wikipedia:Copyrights
           o Wikipedia:Policies_and_guidelines
           o United_States_Constitution/Article_One (I'm a little
confused by this one; I've since unprotected it. It's just a redirect
anyway...)
           o Wikipedia:IP_probation_watchlist
           o Wikipedia:Most_common_Wikipedia_faux_pas
           o Wikipedia:Wikipedia_policy_on_permanent_deletion_of_pages
           o Wikipedia:Blocked_IPs
           o Wikipedia:Naming_conventions
           o Wikipedia:Administrators
           o Wikipedia:Policy

If I left any "powers" out, it's by accident.

There are also a handful of 'developer' features available only to a few
of the programmers for purposes of finding and fixing bugs: database
queries, showing the PHP configuration variables, and enabling/disabling
a read-only mode to prevent edits to the database in the middle of
certain upgrades. --Brion VIBBER ?

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Re: Parsing

body:
On 7/30/02 8:37 AM, "Steve Callaway" <sjc at easynet.co.uk> wrote:

> Tarquin,
>
> I (and probably most people I know (yeah, I live a sad life among the SGML,
> XML and HTML communities)) would disagree strongly with Wiki markup on a
> number of grounds. Firstly it's quirky and non-standard. The whole point of
> the standard mark-up languages is that they're not difficult to learn and
> carry both visual and informational order. H1, H2, H3 cannot be replicated
> by wiki markup in any sense. We are also really going to need these once we
> get to really large articles which require structure to the substance.

I don't understand. What about the
= Header 1 =,
== Header 2 ==, and
=== Header 3 === etc.
markup?


body:
Anthere wrote:

> So the questions I would ask
>
> - what rights does she have on pages ?
> I specifically think of her personal page. Is a personal page
> somebody's property ? Intuitively, I would say yes, and I would say
> someone has the right to delete his own page as well as the talk page
> attached. What is the policy about that ?
> What is the "policy" about discussion pages ? Is one's content of a
> discussion page personal or not ?
>
> - what can we do against a deletion campaign ? Is there a solution
> other than Aoineko keeping restoring pages until she gets tired ? (in
> case you ask, she is probably not on a fixed IP)
>
> - what about the threat of the articles finally revealing themselves
> copyrighted ?
>
As the above related to a problem in the French Wikipedia, it seemed
appropriate to answer in French.

Il me semble que tous nous qui contribuons ? Wikipedia en n'importe
quelle langue sommes pr?ts ? ?tre s?v?rement critiqu?s et ?dit?s, m?me
par des idiots. On abandonne l'espoir comme ? la porte de l'enfer.

En contribuant on accepte la condition qu'on abandonne tous les droits
d'auteur, tout en proclamant qu'on a le droit de contribuer ce qu'on
contribue. La renonciation des droits d'auteur inclus donner le droit
aux autres de changer ou critiquer selon leurs gr?s. Si ses
contributions sonts collaboratives, on doit pr?sumer que ses
collaborateurs savaient ? quoi serviraient leurs collaborations, et
qu'ils ?taient d'accord avec ce que faissait Mulot.

Les droits d'auteur seraient aussi abandonn?s sur la page personnelle;
cette page aussi appartient au grand public. Quand c'est une question de
supprimer telle ou telle page, elle a le m?me droit de suppression que
tout le monde et tout le monde a le m?me droit de restorer la page. Pour
une page personnelle la question est plutot si ?a vaut la peine de la
garder. Pour la "talk page" qui l'accompagne on parle ici des
contributions des autres; le contributeur ne les commence gu?re
soi-m?me. Si Mulot reclame quoi-que-soit des droits sur ces articles, ?a
suit qu'elle doit respecter les droits d'auteur de ces critiques.

Au niveau pratique tout participant a les moyens d'effacer les pages de
tous les autres - (? l'exception seul de quelques pages essentielles au
bon fonctionement du syst?me). Dans une bataille de suppression contre
restoration, c'est souvent le plus tenace qui gagne. C'est encore plus
?vident quand il n'y a qu'une personne pour representer chaque point de
vu. Alors la solution est plus claire quand plusieurs membres de la
communaut? s'occupent de restorer les suppressions.

Pour le moment je ne peus consid?rer la menace de r?v?ler les copyrights
de ses articles que des cries d'un tigre sans dents. Bien entendu, ?a
peut ouvrir un grand nombre de questions, dont la plupart remonte sur la
question de si elle violait elle-m?me les droits de quelqu'un d'autre.
Aussi, si les doutes sont port?es sur les articles, les Wikip?diens qui
consid?rent que ces articles contiennent de bonnes informations peuvent
toujours les r??crire d'une fa?on qui ne violera plus les droits
d'auteur de personne. Il faut toujours se rappeler que les copyrights
n'ont rien ? faire ? l'information, mais ? la fa?on de l'exprimer.

Eclecticology


subject: [Wikipedia-l] Sysop status

body:
> I wanted to apply for sysop status and mailed Jimbo Wales, as
> mentioned on the page concerning the topic; he referred me to
> the list, however. Can any of you sysops judge if my "application"
> is valid? And then also fix the page concerning the topic?

I need to do some more work to the software to organize this process,
so we don't really have a formal process at the moment.  I remember
your name from several bug reports you've filed (thanks), and you
participate on the list and have a valid email address, so if you'll
confirm for me that you are wiki user "Jheijmans", and I'll fix you
up.

P.S. I also looked at your contributions page, and it's over half
Talk pages.  While they're certainly a necessary part of what goes on
here, we also have an informal tradition here (it was stated
somewhere once, maybe I need to put it into the policy pages) that if
you do a lot or "meta" stuff you should at least do a bit of work on
real articles to balance it out--edit some random articles, add a
short bio of someone, etc.  Sysops ought to set an example here.


subject: [Wikipedia-l] Interesting bug report

body:
lcrocker at nupedia.com wrote:

>Thought you guys might be amused by this bug
>report I just received:
>
>  From the look of the Wikipedia web site, it seems
>  that any visitor can edit the content!
>  That can't be correct!
>
It looks like one big guest book!
Ec


subject: [Wikipedia-l] Sysop status

body:
> Before I too jump on the application bandwagon ;) -- what can
> sysops do that mortals can't?

Just a few "dangerous" functions that we don't want to give to
the general public: permanently deleting articles and history from
the database; querying the database in SQL; moving articles to
a new name with history (we'll probably make that one more
available after a bit more testing and debugging); blocking the
IP address of vandals.


subject: [Wikipedia-l] Sysop status

body:
>I, too, would like to apply for sysop status if I am eligible.
>Danny

I'm afraid I don't remember you--what's your Wiki username?
I'll try hard not to hold the AOL address against you :-)


subject: [Wikipedia-l] ISBN links

body:
Jimmy Wales wrote:

>At the present time, no ISBN links on the wikipedia are generating any income
>for the Wikipedia.  Perhaps in the future that should change, but we have to
>be very careful about such things, and in my experience, the amount of money from
>such links is so low that it isn't really that important... not important enough to
>damage our independent reputation.
>
Mindful of all the hazards of such things, this is certainly one of the
less obtrusive financial aids that might be available should the
situation ever call for it.
Eclecticology


subject: [Wikipedia-l] Sysop status

body:
> * Delete uploaded files
> o There's also a revert-to-previously-uploaded-version feature,
> I'm not sure if this is sysop or everybody.

Anybody can revert, and anybody can delete a single old revision;
but only sysops can delete the whole image and its description.

> * Protect and unprotect pages (locking them against edit by other
> users who are not also logged in as sysops).

Forgot about that one.

> Traditionally this was in fact used only on the main page, but
> some of the policy pages are also locked, which I'm not sure I
> approve of. Here are all the pages  currently protected:

>           o Wikipedia:Upload_log
>           o Wikipedia:Deletion_log

These are a special case: the software requires that they be in
a special format so that it can add to them.  While it would be OK
to make certain edits (adding text, etc.), some would break things,
so this is just a safety precaution.

>           o Wikipedia:What_Wikipedia_is_not
>           o Main_Page
>           o Wikipedia:Neutral_point_of_view
>           o Wikipedia:Copyrights
>           o Wikipedia:Policies_and_guidelines
>           o United_States_Constitution/Article_One (I'm a little
> confused by this one; I've since unprotected it. It's just a
> redirect anyway...)
>           o Wikipedia:IP_probation_watchlist
>           o Wikipedia:Most_common_Wikipedia_faux_pas
>           o
Wikipedia:Wikipedia_policy_on_permanent_deletion_of_pages
>           o Wikipedia:Blocked_IPs
>           o Wikipedia:Naming_conventions
>           o Wikipedia:Administrators
>           o Wikipedia:Policy

I think some of these may have had a history of vandalism, but I'm
with you that most of them should be unprotected.  Anyone else
remember more details here--they seem to have been protected when
my head was buried in software, so I missed a lot of discussion.

> There are also a handful of 'developer' features available only
> to a few of the programmers for purposes of finding and fixing
> bugs: database queries, showing the PHP configuration variables,
> and enabling/disabling a read-only mode to prevent edits to the
> database in the middle of certain upgrades. --Brion VIBBER ?

Sysops can do "SELECT" queries on the database.  Only developers
can do updates and deletes.


subject: [Wikipedia-l] Refactoring of Naming, Projects, etc

body:
> I volunteered ages ago to try & reorganise naming conventions,
> and tie them in with things like presentation conventions, Wiki
> Projects and "basic topic" pages.
> I'm still mulling it over, and I'e got to the point where I'd like
> to start laying out ideas.
> There's no way this can be cleanly refactored overnight, so I'm
> thinking of using the Meta wiki, to first set out a page scheme and
> then start refactoring. That way "normal service" (!) won't be
> disturbed on the wikipedia: namespace.
> Any objections if I discreetly set up in a corner of MetaWikipedia?

That would be a good way to do it; another method that Mav used for
some of the element pages is to create a page ".../Temp", do all of
the editing there, and then delete it (after moving it to its final
spot).  This wasn't an anticipated use of the delete feature, but I
think its a good one.

I rather like the way my reorganization of all the policy pages came
out; you might use that as a model for reoganizing naming conventions.


subject: [Wikitech-l] <nowiki>

body:
Are the <nowiki> tags still needed in the script? I'm asking this because
1. I'm having trouble getting them into the formal syntax
2. They are a bit of a security risc because the allow users to get things
like javascript on a page.

-- Jan Hidders


subject: [Wikitech-l] <nowiki>

body:
On Tue, Jul 30, 2002 at 02:38:07AM -0800, Brion VIBBER wrote:
> Jan.Hidders wrote:
>
> >Are the <nowiki> tags still needed in the script? I'm asking this because
> >1. I'm having trouble getting them into the formal syntax
> >
> Of course they're still needed! How else are we supposed to include wiki
> markup as text in a wikipage that's not overly burdenson? (ie, using
> numeric character entities instead of  special wiki symbols.)

So we only need them for the FAQs? :-) But I see your point.

> >2. They are a bit of a security risc because the allow users to get things
> >like javascript on a page.
> >
> If that's the case, that's a serious bug. <nowiki> should mean no *wiki*
> markup interpretation, not no *HTML* safeguarding.

Yup, I tried it on my Sandbox, look at the bottom:

  http://www.wikipedia.com/wiki/User:Jan_Hidders/Sandbox

At the moment I don't understand Lee's code enough to say if there is any
HTML safeguarding going on in the <nowiki> parts, but as far as I can tell
there isn't.

But this can be remedied fairly easy, just replace all the <'s and >'s with
their corresponding entities in the <nowiki> parts. That's even correct in
some sense because we consider HTML as part of the wiki markup. :-/

Lee, should I make a bug report of this?

-- Jan Hidders


from_name: Toby Bartels

subject: [Wikipedia-l] Re: Controversy flag on articles.

body:
Vicki Rosenzweig wrote in part:

>Toby Bartels wrote:

>>Neil Harris wrote:

>>>(Name of issue here) is a [[controversial issue]], with widely differing
>>>points of view...  &c.

>>"'''Evolution''' is a [[controversial issue]],
>>with widely differing points of view."

>Also, of course, "'''God''' is a [[controversial issue]], with widely
>differing points of view",

>Seriously. Evolution isn't half as controversial as whether Jesus is God.

That's kind of the point;
[[Evolution]] shouldn't be flagged but it *will* be (my prediction),
rendering the flag largely useless.

That said, [[God]] probably shouldn't be flagged either --
although I haven't looked at that article, so ?who knows?.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


from_name: Steve Callaway

subject: [Wikipedia-l] Re: Parsing

body:
It occurs to me that there is going to be an awful lot of reworking if we
ever do go to an XML format Wikipedia (and this definitely needs discussion
at some point soon). I would have said that HTML is a more generally
accepted standard and that Wiki formatting is a highly localised phenomenon.
You can do a lot more with HTML format than you ever can with Wiki
formatting.

----- Original Message -----
From: "Stephen Gilbert" <canuck_in_korea2002 at yahoo.com>
To: <wikipedia-l at nupedia.com>
Sent: Tuesday, July 30, 2002 12:18 PM
Subject: Re: [Wikipedia-l] Re: Parsing

>
> --- "Jan.Hidders" <hidders at uia.ua.ac.be> wrote:
> > On Sat, Jul 27, 2002 at 04:24:17PM +0100, tarquin
> > wrote:
> > >
> > > I would hesitate before deprecating  and  in
> > wiki markup, but I
> > > change those to the equivalent ' whenever I see
> > them, and I don't think
> > > they should be encouraged.
> >
> > I would not hesitate here. If you have two notations
> > for the same thing
> > people who want to write have to know them both
> > because they are going to
> > encounter them and therefore have to know what they
> > mean and if they are the
> > same or not. Having one notation is simpler for
> > everybody.
> >
> > -- Jan Hidders
>
> What if you want a bold italic font? I know of only
> three ways to do it on Wikipedia, and none are pure
> wiki syntax: ''Bold italic'', '''Bold
> italic''', or Bold italic.
>
> Stephen G.
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] Re: Parsing

body:
Tarquin wrote:

>Toby Bartels wrote:

>>The question isn't how easy "'''" is to learn.
>>The question is how easy "<b>" is to learn.
>>The answer to that is, it's pretty darned easy;
>>therefore, since people will try it, it should be allowed.
>>If having two ways to write the same thing is bad,
>>then honestly "'''" should go before "<b>" does.

>>(Note the "if"; I think that "'''" is great -- easier to type.
>>In fact, it should actually be rendered as <strong>,
>>which is even harder to type but is almost always more correct.)

>Or <em> maybe?

''' = <strong>, '' = <em>.

>Many people comne to wikipedia completely ignorant of HTML. Many people
>on the net don't even know what HMTL is -- really! Some of them are my
>friends! Many people *with websites* use Dreamweaver or some such and
>have no idea what <b> means.

I don't see the relevance of that.
It's not like they know what ''' means either before they arrive.
Surely *more* people will know <b> than ''' before coming here,
and most of these people won't be ace programmers either.

>I think the most important point is that wiki must be easily readable in
>both raw & rendered formats. The eye skims over ''' very easily, whereas
><b> and </b> arrest the flow.

This I think *is* relevant.
Since I don't believe that we need only one method for every purpose,
I would keep both <b> and ''' but still prefer '''
(barring making a distinction between them as suggested below).

>I would hesitate before [removing support for] <b> and <i> in wiki markup, but I
>change those to the equivalent ' whenever I see them, and I don't think
>they should be encouraged.

I do the same changes myself, except in very special cases
where <b> is actually more appropriate than <strong>.
Then one day when I convince y'all to render ''' as <strong> instead of <b>,
then everything will be perfect!
I'm not about to get upset if you change by <b> to ''', however,
and could be convinced to follow your lead exactly if you work at it;
I'll only get upset if you mess with <var>, as explained in another post
(not yet made, or look on Jan's page).

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Sysop status

body:
lcrocker at nupedia.com wrote:

>>There are also a handful of 'developer' features available only
>>to a few of the programmers for purposes of finding and fixing
>>bugs: database queries, showing the PHP configuration variables,
>>and enabling/disabling a read-only mode to prevent edits to the
>>database in the middle of certain upgrades. --Brion VIBBER ?
>>
>>
>
>Sysops can do "SELECT" queries on the database.  Only developers
>can do updates and deletes.
>
There had been some discussion a while ago of changing that and
restricting all direct DB access to developers; I guess I got it mixed
up with the implementation in my memory. As I recall the points of
contention were:

1) Users' passwords were stored in the database in plaintext. (Since
changed; hashes are now stored so they aren't much good if you get them.)

2) The number of 'sysop's is rapidly rising, and the chances of somebody
accidentally (or maliciously) performing a slow, complex query that tied
up the database for a long time would increase.

-- brion vibber (brion @ pobox.com)


from_name: daniwo59 at aol.com

subject: [Wikipedia-l] Sysop status

body:
I, too, would like to apply for sysop status if I am eligible.

Danny


subject: [Wikipedia-l] Re: Contoversy flag on articles.

body:
Hr. Daniel Mikkelsen wrote:

>My idea with the "controversial issue" flag/page-link would be to use it for
>articles that are still "contested" at Wikipedia. Many articles that in
>themselves regard controversial issues have been splendidly NPOVed, and
>wouldn't need to be flagged.

>But others, where people bicker back and forth, or where someone still doesn't
>consider the article to be NPOVed, would benefit from it.

First, I don't think that this should be encouraged just because
a reader doesn't think that an article is NPOV but hasn't time to fix it.
Although you can't vote automatically from a page anymore,
the listing at [[Wikipedia:Votes for NPOVing]] serves this purpose.
You apparently think that this won't be used widely
because there's a threshold of trouble involved;
but adding "This is a [[controversial issue]]."
at the end of the introductory paragraph is quite easy,
and it's hard to justify removing it if the statement is literally true.
Listing on [[Wikipedia:Votes for NPOVing]] is a more reasonable threshold IMO.

However, the pages where people bicker back and forth
could reasonably stand be flagged for the benefit of casual readers
(or to calm down the authors, although I don't think that that will work).
But casual readers won't be tipped off by a link to [[controversial issue]].
The only way that I think that this will work is an entire paragraph,
placed after the introductory paragraph in Wikipedia's patented '', say:

''This is a [[controversial issue]], and the authors of Wikipedia
have yet to come to a consensus on the best way to present it
from a [[neutral point of view]]. Please bear that in mind while reading,
and if you wish, help us to craft this article in a way
that will be fair to all viewpoints.''

Since the existence of bickering is fairly clear cut,
people can easily justify including or removing this.
Even the bickering authors of the article know that they're bickering,
even if each does think that said bickering is all the other side's fault.
(A computer script to determine whether there's bickering might be better,
except that I have no idea how this could be implemented.
Lots of edits is no evidence; even lots of reverts could just be vandalism.)
People that just jumped in from Google are told up front what's going on,
and a page like [[Wikipedia:Controversial issues]] (redirected to from
[[controversial issue]] for ease of linking) will explain the policy,
not serve as a list (although a list would appear on "What links here").

I'm not convinced that this is necessary at all, but if it is,
then I think that it'll work better out front like this
than as a subtle flag that only insiders will notice.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


from_name: tarquin

subject: [Wikipedia-l] Re: Parsing

body:
Steve Callaway wrote:

>It occurs to me that there is going to be an awful lot of reworking if we
>ever do go to an XML format Wikipedia (and this definitely needs discussion
>at some point soon). I would have said that HTML is a more generally
>accepted standard and that Wiki formatting is a highly localised phenomenon.
>You can do a lot more with HTML format than you ever can with Wiki
>formatting.
>
Au contraire. The beauty of Wiki Markup is that is is independent of
what is sent to the browser.
When XML finally (!) hits the road, all it will take is a few tweaks to
the script so '' is converted to a different tag instead of <I>, and we
can go on writing wiki markup as before.
If anything, XML is another reason for preferring wiki markup to HTML.
Another good reason, from http://c2.com/cgi/wiki?WhyWikiWorks, is:
 > It's an intelligence test of sorts to be able to edit a wiki page.
It's not rocket science, but it doesn't appeal to the VideoAddicts
<http://c2.com/cgi/wiki?VideoAddicts>. If it doesn't appeal, they don't
participate, which leaves those of us who read and write to get on with
rational discourse.


subject: [Wikipedia-l] Sysop status

body:
>>Sysops can do "SELECT" queries on the database.  Only developers
>>can do updates and deletes.

> There had been some discussion a while ago of changing that and
> restricting all direct DB access to developers; I guess I got it
> mixed up with the implementation in my memory. As I recall the
> points of contention were:

> 1) Users' passwords were stored in the database in plaintext.


subject: [Wikipedia-l] Re: Parsing

body:
> Then one day when I convince y'all to render ''' as (strong)
> instead of (b), then everything will be perfect!

'' and ''' are already rendered as (em) and (strong).

I'll have a more detailed reply later, but for now let me
say that I'm definitely on the side of removing the _need_ for
HTML as much as possible, but I'm open to allowing it.


subject: [Wikipedia-l] Re: Parsing

body:
Jan Hidders wrote for the most part:

>Toby Bartels wrote:

>>The question isn't how easy "'''" is to learn.
>>The question is how easy "" is to learn.
>>The answer to that is, it's pretty darned easy;
>>therefore, since people will try it, it should be allowed.

>Just for clarity, I wasn't arguing that simple HTML like  is more
>difficult than ''', but just reacting to the suggestion of the reverse.

I do disagree with you there, thinking that ''' is more difficult,
although *only* because more newbies will know  to begin with --
they are inherently of pretty much the same complexity
(I see two minor arguments each for relative simplicity).
This is minor, and the difference will probably only lessen with time.

My major disagreement with you in these matters
is your desire to find a nonHTML wiki markup for
every one of the HTML tags that's reasonable to implement,
and your ultimate goal to discontinue HTML support at all.
I argue that the HTML tag itself is the best wiki markup for most of these.
It's just a few situations where we have something better,
or where the HTML is so complicated that we *need* something better.
Then I'm with you; I just wish that this weren't an antiHTML crusade.

>It's
>when people start using
 and complex
s and <VAR> and
>when things start becoming harder to understand and edit for the average
>user. Other than that there are also technical reasons such as the
>simplicity of the parser and the control that we would have over the HTML
>that we send to the browsers of the reader.

Well, Lee has just informed me that  and  are taken care of;
it was only Phase II that rendered ''' and '' suboptimally as  and .
We're discussing <var> on your user subpage, and people are working on
.

, even when used on regular web pages, is almost never appropriate,
and I could see disallowing it (but maybe someone else knows why we need it).
So I think that we're closer to agreement than it appears at first;
I don't object to the practical results that you're likely to achieve,
only to the fundamental philosophy that underlies your efforts ^_^.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Re: Parsing

body:
Stephen Gilbert wrote:

>What if you want a bold italic font? I know of only
>three ways to do it on Wikipedia, and none are pure
>wiki syntax: ''Bold italic'', '''Bold
>italic''', or Bold italic.

''''' gives bold italic (more precisely, ),
but this is buggy on some browsers.
If you find that it makes a difference to your browser
exactly how you go about specifying the effect,
then you might consider reporting that to Lee;
he could choose the rendering method that bugs the fewest browsers.
(But I suspect that he would give this very low priority ^_^.)

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Re: Parsing

body:
Tarquin,

I (and probably most people I know (yeah, I live a sad life among the SGML,
XML and HTML communities)) would disagree strongly with Wiki markup on a
number of grounds. Firstly it's quirky and non-standard. The whole point of
the standard mark-up languages is that they're not difficult to learn and
carry both visual and informational order. H1, H2, H3 cannot be replicated
by wiki markup in any sense. We are also really going to need these once we
get to really large articles which require structure to the substance.

If you're worried about simplicity why not get a markup editor built into
the Wikipedia interface. Are there any wiki markup editors out there? None
that I've seen. Plenty of HTML markup editors though + source freely
available. No need to reinvent the wheel for HTML.

There is also no way (AFAIK) of escaping Wiki Markup other than by using
HTML <nowiki> xxx </nowiki> Ironic, huh?

The Wiki markup language varies from Wiki site to site. It is not uniform.
It will become ever more disparate until it becomes a total nonsense. (Think
I'm joking? have a crawl around some of the Wiki variants which are
springing up on a daily basis.)

"Ooh, we need a markup to do x!"
"Yes, we'll do that with fourteen asterisks and an exclamation mark..."
er.....

I can see why you like it. I hope you can see why I find it both inelegant
and limited.

rgds

Steve

----- Original Message -----
From: "tarquin" <tarquin at planetunreal.com>
To: <wikipedia-l at nupedia.com>
Sent: Tuesday, July 30, 2002 12:55 PM
Subject: Re: [Wikipedia-l] Re: Parsing

> Steve Callaway wrote:
>
> >It occurs to me that there is going to be an awful lot of reworking if we
> >ever do go to an XML format Wikipedia (and this definitely needs
discussion
> >at some point soon). I would have said that HTML is a more generally
> >accepted standard and that Wiki formatting is a highly localised
phenomenon.
> >You can do a lot more with HTML format than you ever can with Wiki
> >formatting.
> >
> Au contraire. The beauty of Wiki Markup is that is is independent of
> what is sent to the browser.
> When XML finally (!) hits the road, all it will take is a few tweaks to
> the script so '' is converted to a different tag instead of <I>, and we
> can go on writing wiki markup as before.
> If anything, XML is another reason for preferring wiki markup to HTML.
> Another good reason, from http://c2.com/cgi/wiki?WhyWikiWorks, is:
>  > It's an intelligence test of sorts to be able to edit a wiki page.
> It's not rocket science, but it doesn't appeal to the VideoAddicts
> <http://c2.com/cgi/wiki?VideoAddicts>. If it doesn't appeal, they don't
> participate, which leaves those of us who read and write to get on with
> rational discourse.
>
>
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


from_name: Lars Aronsson

subject: [Wikipedia-l] Re: Parsing

body:
Stephen Gilbert wrote:
> What if you want a bold italic font? I know of only
> three ways to do it on Wikipedia, and none are pure
> wiki syntax: ''Bold italic'', '''Bold
> italic''', or Bold italic.

Did you try '''''Bold italic''''' ?

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik
  Teknikringen 1e, SE-583 30 Linuxk?ping, Sweden
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikipedia-l] Re: Parsing

in_reply_to: <00ac01c237bb$8e73a1f0$0100a8c0@Kraftwerk>; from sjc@easynet.co.uk on Tue, Jul 30, 2002 at 12:23:39PM +0100

body:
On Tue, Jul 30, 2002 at 12:23:39PM +0100, Steve Callaway wrote:
> It occurs to me that there is going to be an awful lot of reworking if we
> ever do go to an XML format Wikipedia (and this definitely needs discussion
> at some point soon).

Well, I would prefer an XML-free format but either is going to be nog very
difficult if we have a formal description of the grammar of the mark-up in a
form that is understood by Yacc. (I'm working on that at the moment, we need
such a grammar anyway.) Then we can do an automatic conversion of old
mark-up to new mark-up and probably even detect the few cases where
formatting is likely to be broken.

> You can do a lot more with HTML format than you ever can with Wiki
> formatting.

That's actually a good reason *not* to use HTML. When you start doing "a lot
more" it will also be "a lot more" difficult to understand and rewrite what
you wrote. WIkipedia is not just about you writing but about you writing and
others rewriting it. :-)

-- Jan Hidders


subject: [Wikipedia-l] Re: Parsing

body:
Jan Hidders wrote:

>Steve Callaway wrote:

>>nevertheless. HTML is //much// simpler.

>That is simply not true. One of the reasons that the WikiWiki mark-up was
>invented is exactly because HTML didn't work well and was seen as
>unecessarily difficult.

I don't see how you can establish this in any objective manner.
Even a survey would only shows that most people feel that one as simpler,
which is not at all the same thing as one's actually *being* simpler.
Myself, I think that <h6> is simpler than ======,
because it's simpler to read the "6" than to count the "="s.
But == is simpler than <h2>, because I don't have to count the "="s there.
We can do psychological testing to determine when simplicity switches,
but other people will switch it at slightly different times.
Best all around to allow both methods.

You know, this is like allowing both American and Commonwealth spellings.
I find it difficult to remember to write "analyze" or "spelt",
but it's easy as pie to learn to read them.
Similarly, if Steve has trouble writing ===, he can still read it,
and if you have trouble writing <h3>, then you can still read that too.
It's just that here the reading is occuring on the edit page
rather than in the text of the article directly.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


from_name: Tom Parmenter

subject: [Wikipedia-l] Re: Parsing

body:
Resent after bounce, change in subscriber name.
- ------- Start of forwarded message -------

|From: tarquin <tarquin at planetunreal.com>
|Date: Tue, 30 Jul 2002 12:55:57 +0100
|
|Steve Callaway wrote:
|
|>It occurs to me that there is going to be an awful lot of reworking if we
|>ever do go to an XML format Wikipedia (and this definitely needs discussion
|>at some point soon). I would have said that HTML is a more generally
|>accepted standard and that Wiki formatting is a highly localised phenomenon.
|>You can do a lot more with HTML format than you ever can with Wiki
|>formatting.
|>
|Au contraire. The beauty of Wiki Markup is that is is independent of
|what is sent to the browser.
|When XML finally (!) hits the road, all it will take is a few tweaks to
|the script so '' is converted to a different tag instead of <I>, and we
|can go on writing wiki markup as before.
|If anything, XML is another reason for preferring wiki markup to HTML.
|Another good reason, from http://c2.com/cgi/wiki?WhyWikiWorks, is:
| > It's an intelligence test of sorts to be able to edit a wiki page.
|It's not rocket science, but it doesn't appeal to the VideoAddicts
|<http://c2.com/cgi/wiki?VideoAddicts>. If it doesn't appeal, they don't
|participate, which leaves those of us who read and write to get on with
|rational discourse.
|

My markup experience goes back to 1978, when Runoff was a pup found on
the doorstep by the FAA in Oklahoma City, and goes on through the
various *ROFFS, DEC's own RNO, Symbolics Concordia (where I was doc
manager), VAX Document (whose development group I managed), HTML, XML
(a disastrous experience with Arbortext products), and a couple of
others I can't now recall, as well as Framemaker and other word
processors, so it is with some authority that I can say that Wiki
Markup is the best, most comfortable, pound-for-pound most functional
markup language I have ever used.

It is simple, easy to learn, and provides almost all that any writer
needs to do the job of putting words in order.  Tables are dreadful,
but they almost always are.  Some kind of simple table specifier that
would permit creation of two-column and three-column tables is about
the only thing I miss.  Even there, you can do most of what you want
just by putting a blank space at the beginning of a line.

The ability to sneak out into HTML is handy, but prone to non-wikiness
if the next person to come along can't figure out some arcanely nested
construction.  A back door to XML would be a mistake in my opinion
because you can do *anything* with XML and I don't think we want to be
able to *anything*, we want *anyone* to be able to edit a page.

Implement in XML, sure, but hide it, because I don't ever want to code
in it.  I don't really want to code at all, and Wiki Markup gives me
the impression that I'm not coding and I don't have to.

Ortolan88
- ------- End of forwarded message -------


subject: [Wikipedia-l] Re: Parsing

body:
> We can do psychological testing to determine when simplicity
> switches, but other people will switch it at slightly different
> times. Best all around to allow both methods.

This I have to disagree with totally.  Leaving in a mix of both is
horrible.  Our markup here serves a different purpose than other
markup languages. It /must/ be editable by novices.  Wikitext that
produces a nice page, but can't be edited, is bad wikitext.  For an
extreme example, see the article "Duesseldorf"--this is precisely the
kind of abomination that allowing too much HTML produces.  It might
be a fine article, but it will never be improved because it's
impossible to edit.  That's fine for web page, but not for a wiki.

As comfortable as all of us are with HTML, /we/ aren't the kind of
people we want editing articles (except maybe those on computer
subjects).  We want Bridge players writing about Bridge, and cat
breeders writing about cats, and campers writing about camping--the
kind of people who have never even heard of HTML are the kind of
people we want most to attract and make use of.  We computer nerds
are used to dealing with special syntaxes; it is we who should adapt
to them, not the other way around.


subject: [Wikipedia-l] Re: Parsing

body:
--- Lars Aronsson <lars at aronsson.se> wrote:
> Stephen Gilbert wrote:
> > What if you want a bold italic font? I know of
> only
> > three ways to do it on Wikipedia, and none are
> pure
> > wiki syntax: ''Bold italic'', '''Bold
> > italic''', or Bold italic.
>
> Did you try '''''Bold italic''''' ?

No, I quite stupidly did not. Someone demonstrated on
my page, though.

Am I the only one who found that counter-intuitive? If
so, I withdraw any objections.

Stephen G.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] Re: Parsing

body:
Tarquin wrote:

>TMTOWTDY I suppose...

What does that mean?

>Toby Bartels wrote:

>>I'm not about to get upset if you change by  to ''', however,
>>and could be convinced to follow your lead exactly if you work at it;
>>I'll only get upset if you mess with <var>, as explained in another post
>>(not yet made, or look on Jan's page).

>I change  around the article title in the first sentence.

I do that too.

>I haven't changed any <var> tags, though I have created formulae myself
>with '' around variables, because I'd seen it done like that.
>The $$ for <var> idea is interesting, but I don't think it will make
>formulae significantly easier on the eye in raw form.

I don't think that the '' version is easy on the eye either.
Easy on the eye would be a limited implementation of TeX
that would render the wiki input $$x^2 y = z_1$$ into HTML as
<var>x</var>2<var>y</var>?= <var>z</var>1.
But that opens up its own whole new can of worms.
OTOH, $$x$$2$$y$$?= $$z$$1 would be an improvement,
and $$x$$^^2^^$$y$$?= $$z$$__1__ would be even better.
(This won't quite work, since ^^ and __ can't be interpreted as toggles,
but I'm not sure how to deal with that right now.)

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


body:
--- tarquin <tarquin at planetunreal.com> wrote:
> I volunteered ages ago to try & reorganise naming
> conventions, and tie
> them in with things like presentation conventions,
> Wiki Projects and
> "basic topic" pages.
> I'm still mulling it over, and I'e got to the point
> where I'd like to
> start laying out ideas.
> There's no way this can be cleanly refactored
> overnight, so I'm thinking
> of using the Meta wiki, to first set out a page
> scheme and then start
> refactoring. That way "normal service" (!) won't be
> disturbed on the
> wikipedia: namespace.
> Any objections if I discreetly set up in a corner of
> MetaWikipedia?
>
> tarquin

Have you seen some of the stuff that's over there?
Please, feel free to set up something useful and don't
bother being discreet!

Stephen G.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] Sysop status

body:
--- lcrocker at nupedia.com wrote:
>
> >I, too, would like to apply for sysop status if I
> am eligible.
> >Danny
>
> I'm afraid I don't remember you--what's your Wiki
> username?
> I'll try hard not to hold the AOL address against
> you :-)

I'll vouch for Danny. He's been trying to add some
NPOV to some controversial issues as I recall.

Stephen G.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] Parsing

body:
Lee Crocker wrote in part:

>Toby Bartels wrote:

>>We can do psychological testing to determine when simplicity
>>switches, but other people will switch it at slightly different
>>times. Best all around to allow both methods.

>This I have to disagree with totally.  Leaving in a mix of both is
>horrible.  Our markup here serves a different purpose than other
>markup languages. It /must/ be editable by novices.  Wikitext that
>produces a nice page, but can't be edited, is bad wikitext.  For an
>extreme example, see the article "Duesseldorf"--this is precisely the
>kind of abomination that allowing too much HTML produces.  It might
>be a fine article, but it will never be improved because it's
>impossible to edit.  That's fine for web page, but not for a wiki.

That example's not fair, of course.
First, it's not fine for a web page; the HTML is badly written anyway.
Next, disallowing HTML doesn't necessarily fix that;
see the first version, which had HTML that we didn't parse.
Now, that got fixed in a few minutes, so not parsing HTML discourages it.
In that vein, let me note that I agree that some HTML shouldn't be parsed.
So I grant your implicit claim that we allow too much HTML
(especially since Jan successfully put JavaScript inside a <nowiki>!),
but not your implicit claim (given the context) that <h1> is too much.

In fact, here would be a nice start at culling unallowable HTML
that Jan and I can both get behind (I hope): go to
http://www.w3.org/TR/1999/REC-html401-19991224/index/elements.html
and get rid of everything labelled "deprecated" (or not there at all).
This takes care of half of the problem with [[Duesseldorf]], which is <font>.
(I saw a talk or meta page somewhere that said that we might want <font>
in an article on a font itself in order to provide an example.
But somebody else replied quite rightly that an image would be superior.)

The other half of the problem is the table, which is completely inappropriate,
but we wouldn't be much better off if they used wiki syntax for it instead.
If we allow tables at all, and there are good reasons to do so,
then we'll have to deal with people using them inappropriately;
the computer nerds like us just need to rewrite them whenever we see them.

I don't for a moment think that we need to allow all HTML.


subject: [Wikipedia-l] Re: Parsing

body:
> > I don't understand. What about the
> > = Header 1 =,
> > == Header 2 ==, and
> > === Header 3 === etc.
> > markup

er. and H4 - H8? I can see why you want it. It's very idiosyncratic,
nevertheless. HTML is //much// simpler. And the stuff you learn is
//portable//. The way the wikis are going, you're going to need to know a
raft of different flavours of markup.

----- Original Message -----
From: "Jan.Hidders" <hidders at uia.ua.ac.be>
To: <wikipedia-l at nupedia.com>
Sent: Tuesday, July 30, 2002 5:17 PM
Subject: Re: [Wikipedia-l] Re: Parsing

> On Tue, Jul 30, 2002 at 10:52:32AM -0400, The Cunctator wrote:
> > On 7/30/02 8:37 AM, "Steve Callaway" <sjc at easynet.co.uk> wrote:
> >
> > > Tarquin,
> > >
> > > I (and probably most people I know (yeah, I live a sad life among the
SGML,
> > > XML and HTML communities)) would disagree strongly with Wiki markup on
a
> > > number of grounds. Firstly it's quirky and non-standard. The whole
point of
> > > the standard mark-up languages is that they're not difficult to learn
and
> > > carry both visual and informational order. H1, H2, H3 cannot be
replicated
> > > by wiki markup in any sense. We are also really going to need these
once we
> > > get to really large articles which require structure to the substance.
> >
> > I don't understand. What about the
> > = Header 1 =,
> > == Header 2 ==, and
> > === Header 3 === etc.
> > markup?
>
> Indeed. So these guys have learned SGML, HTML1, 2, 3 and 4, and probably
> type it by hand for a living, but learning the Wiki mark-up, wow, that is
> asking just too much. :-)
>
> -- Jan Hidders
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] Re: Parsing

body:
>
>
>Indeed. So these guys have learned SGML, HTML1, 2, 3 and 4, and probably
>type it by hand for a living, but learning the Wiki mark-up, wow, that is
>asking just too much. :-)
>
>
I do actually agree with a lot of what Steve says, but not entirely with
the conclusions. There are so many flavours of wiki, and the fusspot
within me itches to see it standardized. Yet it also allows each
individual wiki to have its own feel -- more reasons below....
The quirkiness is also seen generally as a strength, not a hindrance.
Simplicity is debateable. I find it easier to hit ' repeatedly (I'm a
pianist...) that to fiddle with < and / -- one needs SHIFT and the other
doesn't. For me, that's a guaranteed typo every time.
At least with wiki I don't need to worry about what works on IE6 /
Netscape 4.x / Opera / Mozilla ... and then MacIE, *nix browsers etc --
except of course on my own wiki where I decide what HTML tags the wiki
tags are parsed to.
I'm actually a lurker on the W3C CSS list, and it's very depressing to
see all the great ideas for CSS3 that come up, yet all the while I can't
even get CSS2 to work reliably. pot, kettle, black & so on ... ;-)

Anyway, before this wiki markup vs. HTML debate clogs the list, may I
suggest that, as far as generalities of the topic go, we <gruff northern
voice>take it outside</> to Meatball:
http://www.usemod.com/cgi-bin/mb.pl?WikiSyntax ,
http://www.usemod.com/cgi-bin/mb.pl?RawHtmlWiki
and (you're so not gonna like this one...)
http://www.usemod.com/cgi-bin/mb.pl?HtmlIsAssembler


subject: [Wikipedia-l] Re: Parsing

in_reply_to: <B96C2070.23E4%cunctator@kband.com>; from cunctator@kband.com on Tue, Jul 30, 2002 at 10:52:32AM -0400

body:
On Tue, Jul 30, 2002 at 10:52:32AM -0400, The Cunctator wrote:
> On 7/30/02 8:37 AM, "Steve Callaway" <sjc at easynet.co.uk> wrote:
>
> > Tarquin,
> >
> > I (and probably most people I know (yeah, I live a sad life among the SGML,
> > XML and HTML communities)) would disagree strongly with Wiki markup on a
> > number of grounds. Firstly it's quirky and non-standard. The whole point of
> > the standard mark-up languages is that they're not difficult to learn and
> > carry both visual and informational order. H1, H2, H3 cannot be replicated
> > by wiki markup in any sense. We are also really going to need these once we
> > get to really large articles which require structure to the substance.
>
> I don't understand. What about the
> = Header 1 =,
> == Header 2 ==, and
> === Header 3 === etc.
> markup?

Indeed. So these guys have learned SGML, HTML1, 2, 3 and 4, and probably
type it by hand for a living, but learning the Wiki mark-up, wow, that is
asking just too much. :-)

-- Jan Hidders


body:
uh-oh. A Wiki Mind Wipe. :(
I can't see anything in the GFDL about retraction of works, nor on
http://meta.wikipedia.com/wiki.phtml?title=Wikipedia_and_copyright_issues
If edits have been made to pages created by Mulot, then they're no
longer only hers.
Given the nature of the GFDL it is unrealistic to think that one can
retract a work -- there's no way of keeping track of all the adaptations
of it.
I would say a personal page is personal property -- but all wikipedia
pages are GDFL, even personal pages, presumably -- so the "personal
property" thing there is more a matter of etiquette.


body:
I thank all of you for your answers and advices. I
really appreciated.

I indicated (again !) the adress of the mailing list
archives on a special page for discussion on the
fr.wiki.

I gave my point of view on the fr.wiki, and hope
french people that followed the debate will do the
same :-)

We do have a vandalism page, because of an anarchist
who played a little bit with us some time ago. Problem
is the people that care to "weed" the place are not
very numerous, and some are on holidays. Which will be
my case tomorrow (so I will not be able to help,
whatever the solution decided).

As for copyright issues, I believe it is mostly a blow
in water. But maybe not entirely. It may be she cited
some people she knows (some of the other
collaborators), people that agreed to let her use some
of their writings, but that could decide not to
anymore. If we keep the pages, we'll see about that. I
made a copy of the pages "just in case". If only
because some of us did some work (even if light) on
these articles.

And...my opinion is that a personal page is a personal
page. She gave some personal information on it, nobody
edited it. It may be covered by our license, but I
consider it a basic question of respect toward her to
let her delete it. just my opinion.

Thanks again

>On abandonne l'espoir comme ? la porte de l'enfer.
Ce qui est particuli?rement adapt? ? la situation
d'une th?ologienne amateur (telle qu'elle se d?finit).
C'?tait trop chaud !!!

Anth?re

--- Ray Saintonge <saintonge at telus.net> wrote:
> Anthere wrote:
>
> > So the questions I would ask
> >
> > - what rights does she have on pages ?
> > I specifically think of her personal page. Is a
> personal page
> > somebody's property ? Intuitively, I would say
> yes, and I would say
> > someone has the right to delete his own page as
> well as the talk page
> > attached. What is the policy about that ?
> > What is the "policy" about discussion pages ? Is
> one's content of a
> > discussion page personal or not ?
> >
> > - what can we do against a deletion campaign ? Is
> there a solution
> > other than Aoineko keeping restoring pages until
> she gets tired ? (in
> > case you ask, she is probably not on a fixed IP)
> >
> > - what about the threat of the articles finally
> revealing themselves
> > copyrighted ?
> >
> As the above related to a problem in the French
> Wikipedia, it seemed
> appropriate to answer in French.
>
> Il me semble que tous nous qui contribuons ?
> Wikipedia en n'importe
> quelle langue sommes pr?ts ? ?tre s?v?rement
> critiqu?s et ?dit?s, m?me
> par des idiots. On abandonne l'espoir comme ? la
> porte de l'enfer.
>
> En contribuant on accepte la condition qu'on
> abandonne tous les droits
> d'auteur, tout en proclamant qu'on a le droit de
> contribuer ce qu'on
> contribue. La renonciation des droits d'auteur
> inclus donner le droit
> aux autres de changer ou critiquer selon leurs gr?s.
> Si ses
> contributions sonts collaboratives, on doit pr?sumer
> que ses
> collaborateurs savaient ? quoi serviraient leurs
> collaborations, et
> qu'ils ?taient d'accord avec ce que faissait Mulot.
>
> Les droits d'auteur seraient aussi abandonn?s sur la
> page personnelle;
> cette page aussi appartient au grand public. Quand
> c'est une question de
> supprimer telle ou telle page, elle a le m?me droit
> de suppression que
> tout le monde et tout le monde a le m?me droit de
> restorer la page. Pour
> une page personnelle la question est plutot si ?a
> vaut la peine de la
> garder. Pour la "talk page" qui l'accompagne on
> parle ici des
> contributions des autres; le contributeur ne les
> commence gu?re
> soi-m?me. Si Mulot reclame quoi-que-soit des droits
> sur ces articles, ?a
> suit qu'elle doit respecter les droits d'auteur de
> ces critiques.
>
> Au niveau pratique tout participant a les moyens
> d'effacer les pages de
> tous les autres - (? l'exception seul de quelques
> pages essentielles au
> bon fonctionement du syst?me). Dans une bataille de
> suppression contre
> restoration, c'est souvent le plus tenace qui gagne.
> C'est encore plus
> ?vident quand il n'y a qu'une personne pour
> representer chaque point de
> vu. Alors la solution est plus claire quand
> plusieurs membres de la
> communaut? s'occupent de restorer les suppressions.
>
> Pour le moment je ne peus consid?rer la menace de
> r?v?ler les copyrights
> de ses articles que des cries d'un tigre sans dents.
> Bien entendu, ?a
> peut ouvrir un grand nombre de questions, dont la
> plupart remonte sur la
> question de si elle violait elle-m?me les droits de
> quelqu'un d'autre.
> Aussi, si les doutes sont port?es sur les articles,
> les Wikip?diens qui
> consid?rent que ces articles contiennent de bonnes
> informations peuvent
> toujours les r??crire d'une fa?on qui ne violera
> plus les droits
> d'auteur de personne. Il faut toujours se rappeler
> que les copyrights
> n'ont rien ? faire ? l'information, mais ? la fa?on
> de l'exprimer.
>
> Eclecticology
>
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go
> here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


from_name: Jeroen Heijmans

subject: [Wikipedia-l] Sysop status

body:
Hi,

I wanted to apply for sysop status and mailed Jimbo Wales, as mentioned on the page concerning the topic; he referred me to the list, however. Can any of you sysops judge if my "application" is valid? And then also fix the page concerning the topic?

Thanks,

Jeroen Heijmans


body:
I volunteered ages ago to try & reorganise naming conventions, and tie
them in with things like presentation conventions, Wiki Projects and
"basic topic" pages.
I'm still mulling it over, and I'e got to the point where I'd like to
start laying out ideas.
There's no way this can be cleanly refactored overnight, so I'm thinking
of using the Meta wiki, to first set out a page scheme and then start
refactoring. That way "normal service" (!) won't be disturbed on the
wikipedia: namespace.
Any objections if I discreetly set up in a corner of MetaWikipedia?

tarquin


subject: [Wikipedia-l] Sysop status

body:
Before I too jump on the application bandwagon ;) -- what can sysops do
that mortals can't?

daniwo59 at aol.com wrote:

>I, too, would like to apply for sysop status if I am eligible.
>
>Danny
>[Wikipedia-l]
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
>
>


from_name: Hr. Daniel Mikkelsen

subject: [Wikipedia-l] Re: Parsing

body:
On Tue, 30 Jul 2002, Steve Callaway wrote:

> > > I don't understand. What about the
> > > = Header 1 =,
> > > == Header 2 ==, and
> > > === Header 3 === etc.
> > > markup
>
> er. and H4 - H8? I can see why you want it. It's very idiosyncratic,
> nevertheless. HTML is //much// simpler. And the stuff you learn is
> //portable//. The way the wikis are going, you're going to need to know a
> raft of different flavours of markup.

I disagree that HTML is simpler at all. At my company, we've adopted wiki like
syntax for letting people/customers edit simple articles at web applications,
because it's easier for them to learn, and easier for them to type.

(We export to both HTML, XML and RTF, btw.)

Also, by using HTML, you create an expecation that a full set of HTML markup is
supported. Which we can't have, of course, if we ever want to export to XML.

The concept of a limited markup is important for Wikipedia, exactly because the
content counts, not the presentation. Wikipedia and other wikis represent the
original dream of the web - marred by foul extensions to HTML and proprietary
plugins. Wiki syntax must stay.

Using HTML for markup at Wikipedia is like pissing in your pants to keep warm.

-- Daniel


from_name: Daniel Mayer

body:
On Tuesday 30 July 2002 10:18 am, you wrote:
> Hi, everybody. I thought it's about time I joined the list.
>
> Instead of just a lockout button, why not also provide admins with the
> ability to:
>
> a) ? ? ? Limit edits to logged-in users, or
>
> b) ? ? ? Limit the frequency of edits to "one edit per minute" for any
> given user or any given IP
>
> (You could adjust the time value of one minute in option B above.)
>
> --Ed Poor

This seems like a reasonable alternative and should be considered -- however
this would probably require more work than allowing mere admins the ability
to use the existing database block feature now only available to developers.

But I digress... There has been several well reasoned posts about /not/
starting an arms race with vandals. Which would mean:

1) This feature would have to be given to admins in a hush-hush mannor and
act as a "secrete weapon" to use only as a last resort (however, any script
kiddy vandal with half a brain will scan all the mailing lists to find out
security details and will quickly find out about such a "weapon" and mount
counter-measures to circumvent it)

2) Or, this feature would be announced and open to act as some type of
deterrence to a script kiddy vandal (which is also would fail due to the
above).

I oftentimes (all-the-time?) overthink things and look too far ahead. So I
leave this debate to saner minds than mine for now. Do what you think is best
for the security of Wikipedia.

Maybe all we need is daily database snapshots sent to a few different secure
locations (perhaps more often if it doesn't become a performance issue).
Heck, send me a script to automate the process and I will download a daily
snapshot -- I have bandwidth to spare.

--mav


subject: [Wikipedia-l] Re: Parsing

body:
On Tue, Jul 30, 2002 at 05:38:54PM +0100, Steve Callaway wrote:
> > > I don't understand. What about the
> > > = Header 1 =,
> > > == Header 2 ==, and
> > > === Header 3 === etc.
> > > markup
>
> er. and H4 - H8?

Guess. It works up to ======. If you need more you are probably writing an
article that should be split up anyway.

> nevertheless. HTML is //much// simpler.

That is simply not true. One of the reasons that the WikiWiki mark-up was
invented is exactly because HTML didn't work well and was seen as
unecessarily difficult.

-- Jan Hidders


subject: [Wikipedia-l] Sysop status

body:
On Tuesday 30 July 2002 10:18 am, you wrote:
> Hi,
>
> I wanted to apply for sysop status and mailed Jimbo Wales, as mentioned on
> the page concerning the topic; he referred me to the list, however. Can any
> of you sysops judge if my "application" is valid? And then also fix the
> page concerning the topic?
>
> Thanks,
>
> Jeroen Heijmans

On Tuesday 30 July 2002 10:18 am, you wrote:
> I, too, would like to apply for sysop status if I am eligible.
>
> Danny

I say Jeroen and Danny would make a great sysops. However I know Jeroen used
to use the "vote for deletion" feature of phase II Pedia Wiki a lot and at
least several of the entries submitted had to be removed from the deletion
queue as not being valid for administrative removal. But I still trust that
Jeroen will /not/ abuse the delete page sysop feature and when there is /any/
question that a page should be removed that that page be first placed on the
vote for deletion page for a day or two -- which is the general policy anyway.

Unfortunately, LDC never got around to porting the promote/demote feature of
Phase II to Phase III, so Jimbo (possibly a developer) will have to promote
you two. I'm sure nobody will object to your promotion.

Again I would like to restate my proposal to have an 'old hand' status that
would allow users that have been around a while and are generally trusted to
move pages and edit protected pages. Not everyone wants to have to keep up
with the mailing list or have the burden of being seen as some type of cop
just to have the ability to do stuff like moving pages or editing the Front
Page. These things can't really be entrusted to totally green users that
signed-up 5 minutes before and are totally unaware of our editing policies
and naming conventions but I see no reason to deny this to longtime users.

Aside.... Is the name "Pedia Wiki" used anymore? Or does our wikiware have no
name? :-(

--mav


subject: [Wikipedia-l] Re: Parsing

body:
Steve Callaway wrote:
> > > === Header 3 === etc.
> er. and H4 - H8? I can see why you want it. It's very idiosyncratic,
> nevertheless. HTML is //much// simpler. And the stuff you learn is

Frankly, when did you ever use H4 or even H8?  Having more than 3
levels of headings must be considered poor information structure.  It
might happen in technical reports and documentation (although more
by poor tradition than by good design), but hardly in wiki articles.
The people who designed H4-H8 into HTML should be prosecuted, but
they would probably be believed if they'd plead insanity.

Wiki markup is simplicity.  XML is simplicity when compared to SGML,
but it isn't radical enough for manual text editing.  The exact
details of wiki markup can be discussed, but essentially it is the
same plain text that we use in email.  At first I would have expected
*boldface* and _italics_, which is the email/Usenet tradition, but
'''boldface''' and ''italics'' is fine with me.

If the web browser HTML form textarea editor was a nice WYSIWYG
editor, that would have been a step forward.  But given the browsers
as they are, wiki markup is the optimal solution, if you ask me.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik
  Teknikringen 1e, SE-583 30 Linuxk?ping, Sweden
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


from_name: Neil Harris

subject: [Wikipedia-l] Re: Parsing

body:
Hr. Daniel Mikkelsen wrote:

>I disagree that HTML is simpler at all. At my company, we've adopted wiki like
>syntax for letting people/customers edit simple articles at web applications,
>because it's easier for them to learn, and easier for them to type.
>
>(We export to both HTML, XML and RTF, btw.)
>
>Also, by using HTML, you create an expecation that a full set of HTML markup is
>supported. Which we can't have, of course, if we ever want to export to XML.
>
>The concept of a limited markup is important for Wikipedia, exactly because the
>content counts, not the presentation. Wikipedia and other wikis represent the
>original dream of the web - marred by foul extensions to HTML and proprietary
>plugins. Wiki syntax must stay.
>
>Using HTML for markup at Wikipedia is like pissing in your pants to keep warm.
>
>-- Daniel
>
I agree completely. The correct way to an XML hyper-wikipedia is through
simple wiki markup.

Neil

>
>
>


body:
On Tuesday 30 July 2002 12:01 pm, you wrote:
> I volunteered ages ago to try & reorganise naming conventions, and tie
> them in with things like presentation conventions, Wiki Projects and
> "basic topic" pages.
> I'm still mulling it over, and I'e got to the point where I'd like to
> start laying out ideas.
> There's no way this can be cleanly refactored overnight, so I'm thinking
> of using the Meta wiki, to first set out a page scheme and then start
> refactoring. That way "normal service" (!) won't be disturbed on the
> wikipedia: namespace.
> Any objections if I discreetly set up in a corner of MetaWikipedia?
>
> tarquin

If you are planning on doing major work then I also suggest that you do as
Lee indicated and make a /Temp page so that everybody can monitor the process
and help out easily (especially me since I promised to do the exact same
thing). However, if you are doing work that will not really leave the page
looking incomplete or messy during the process then I say we just un-protect
the page and let you go at it (I can't remember, are your a sysop? We have so
many now...).

Aside....

Frankly, I really don't know why we still have a metapedia -- it is mainly a
repository of junk from the main site and has never really served its
intended purpose of meta discussion, random chit chat about the project and
working on projects.

In my opinion having two separate RecentChanges for Wikipedia and Metapedia
is why activity is comatose on the meta. But then I would be uncomfortable
about having something like a meta namespace unless the display of meta pages
in RecentChanges were turned off by default for users -- we are first an
encyclopedia not a social club.

--mav


subject: [Wikipedia-l] Re: Parsing

body:
On Tuesday 30 July 2002 10:18 am, you wrote:
> That's actually a good reason *not* to use HTML. When you start doing "a
> lot more" it will also be "a lot more" difficult to understand and rewrite
> what you wrote. WIkipedia is not just about you writing but about you
> writing and others rewriting it. :-)
>
> -- Jan Hidders

I  couldn't agree more.-- we are here to write an encyclopedia, not win
prizes of nifty looking and complex webpages. Let's keep are focus people.

<hint>WikiTable parsing</hint>
(Sorry, there is no wiki equivalent of that tag ;-)

--mav


subject: [Wikipedia-l] Re: Parsing

body:
On Tuesday 30 July 2002 07:37 pm, LDC wrote:
> As comfortable as all of us are with HTML, /we/ aren't the kind of
> people we want editing articles (except maybe those on computer
> subjects). ?

I agree.

>We want Bridge players writing about Bridge, and cat
> breeders writing about cats, and campers writing about camping--the
> kind of people who have never even heard of HTML are the kind of
> people we want most to attract and make use of. ?We computer nerds
> are used to dealing with special syntaxes; it is we who should adapt
> to them, not the other way around.

Wow... LDC you just beautifully crystalized the issue. Something like the
above paragraph should be on the editing policy page.

--mav


subject: [Wikipedia-l] Re: Parsing

body:
Toby Bartels wrote:

>>Many people comne to wikipedia completely ignorant of HTML. Many people
>>on the net don't even know what HMTL is -- really! Some of them are my
>>friends! Many people *with websites* use Dreamweaver or some such and
>>have no idea what <b> means.
>>
>>
>
>I don't see the relevance of that.
>
>
not hugely relevant. I was refuting the statement earlier that "we all
know <b>". There's also the opinion that ''' is easier to learn than B.
It's less scary to the non-technically-minded. A LOT less scary. Most
people on this list are hardened to HTML. I hand-code my HTML and CSS in
Textpad :) -- but I also know how people who just use the web to surf
regard this sort of thing. To the casual websurfer < and > are like car
headlights to rabbits.

>>I think the most important point is that wiki must be easily readable in
>>both raw & rendered formats. The eye skims over ''' very easily, whereas
>><b> and </b> arrest the flow.
>>
>>
>
>This I think *is* relevant.
>Since I don't believe that we need only one method for every purpose,
>I would keep both <b> and ''' but still prefer '''
>(barring making a distinction between them as suggested below).
>
TMTOWTDY I suppose...

>I'm not about to get upset if you change by <b> to ''', however,
>and could be convinced to follow your lead exactly if you work at it;
>I'll only get upset if you mess with <var>, as explained in another post
>(not yet made, or look on Jan's page).
>
I change <b> around the article title in the first sentence.
I haven't changed any <var> tags, though I have created formulae myself
with '' around variables, because I'd seen it done like that.
The $$ for <var> idea is interesting, but I don't think it will make
formulae significantly easier on the eye in raw form.


subject: [Wikipedia-l] Parsing

body:
Jan Hidders wrote at last:

>This discussion is probably coming out of everybodies noses by now, so I
>suggest we wrap it up, or continue it by e-mail.

I want to answer you, and I don't want to leave the public forum,
so I'll reply at [[User talk:Jan Hidders/HTML-free mark-up]].
See you there!

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


from_name: Michael R. Irwin

subject: [Wikipedia-l] User Contribution Tracking

body:
Hi All,

I have been inactive a while.  Can someone tell me whether the user
contribution page is going to return to listing contributions or is it
going to stick with the recent changes format of within last 30 days?
Was this change due to a performance issue or as a result of refactoring
the wiki software?

Personally I found the old format extremely useful in quickly browsing
to subjects that I had previously found interesting and was able to
contribute to.  It was also fun/useful to be able to see a list of my
contributions without me having to build and maintain a list manually.
Easier to find skimpy entries or augment articles of interest with
additional information.

It was also useful on the occasion a few months ago when I was labeled
<b>TROLL</b>.  In response to my defensive reaction to this offensive
allegation, Rgamble actually looked up a few of my contributions and
affirmed that he/she thought I was contributing more than I was damaging
and that he/she therefore did not consider me a troll.

As things stand right now on the contribution page he/she would have
been unable to respond semi-quantitatively due to an inability to easily
audit a random sampling of past contributions.

mirwin


subject: [Wikipedia-l] Help from a sys admin requested

body:
Hi,

During the password scare a few weeks/months ago I changed my password
on my account.  Somehow in the last few weeks/months the cookie on my
portable has gotten messed up and I cannot remember/hack the current
password phrase for the wikipedia site.   My meta account still works
fine, apparently I never changed the password phrase there.

Would it be possible for a sys admin to assign a new pass phrase to the
main site account and email it to me or must I start a new account and
request the old to be deleted?

Thanks,
mirwin