subject: [Wikitech-l] Re: Phase IV

body:
Erik Moeller wrote:
> Timwi-
>
> Please do take a look at the Wookee parser module that Tarquin pointed to.
> It uses a syntax very similar to Wikipedia's.
> http://wiki.beyondunreal.com/wiki/Wookee

Aw! You're taking all the fun out!

How about I write my own first, and if you don't like it, we can still
change it to Wookee?

>>Yes, point taken, but I don't expect the switch to happen soon :-) In
>>fact, I don't really /expect/ the switch to happen at all, I regard it
>>all as an experiment. Even if Wikipedia won't ever use my software, it
>>was still a lot of fun and very educational to write it.
>
> Sure. And if it's a decent wiki, you can add it to
> http://c2.com/cgi/wiki?WikiEngines
> and hope that people use it for other purposes.

Whoa. I didn't know there were so many Wiki engines already. Does none
of them meet your needs better than Phase-3? (I guess not, because
otherwise you probably would have switched, no?)

>>>>I think it's better to store them in a database.
>>>
>>>I never understood this approach.
>>
>>I suppose you're thinking there's an increased risk of data corruption
>>because the database is all one file, and you're thinking if one bit of
>>the file gets corrupted, it's all gone.
>
> Not necessarily. But if the database file is corrupted, the database may
> no longer process the table correctly, in which case the binary data would
> have to be hand-extracted to rescue it.

But if the directory structure gets corrupted, the file system may no
longer process the directory correctly, in which case the binary data
would have to be hand-extracted to resue it.

> If you see the database as another
> layer on top of the file system, and argue that the same risks apply to
> the DB as to the filesystem, then you have doubled your risks by adding a
> DB layer.

So far I was only talking about the effects of a failure, not the causes
of them. It is not a given that the possible causes or their probability
are doubled by adding a DB layer.

The most likely cause is a hardware failure. Quite obviously, the
probability of this happening does not increase with the addition of a
DB layer, nor does the amount of damage it can do.

Another possible cause is a bug in the software. Of course, the extra DB
layer adds the risk of there being a bug in the RDBMS, but since the
whole database is just one file, it reduces the risk of a bug in the
OS's file system somewhat.

>>The "reduced performance" argument is something I don't know anything
>>about; it is possible that this is a good argument, but I'm not convinced.
>
> Well, then test it. Throw some 10 megabyte files into the database and
> compare the reading performance with multiple threads to direct Apache
> server access.

I've thought about something. In order to change one image into another,
in the DB you just use one REPLACE query. With a DB/file system hybrid
as you are suggesting, you would have to
1) write the new version of the image to a new file
2) change the filename in the database
3) delete the old file

But yeah, I'll test this somehow (I'm not a real expert at performance
testing either...)

>>Now to your question, "What exactly is the disadvantage of just storing
>>a pointer to the local filesystem in the DB?" - The disadvantage is that
>>it is more difficult to maintain a consistent state, i.e. a database
>>without "dead links" and a file system free of orphans.
>
> Sure, but given that you only have to deal with create, move, delete
> implementation complexity is minimal, and the associated risks should be
> low.

That list is not quite complete - I have listed other uses that you seem
to have ignored. Taking a backup (of a consistent state) would be
difficult. Splitting the database into several (clustering) would be
difficult. It would make replication difficult. Of course these are all
administrative issue that the user never comes in contact with ...

> In addition, I *like* being able to just zip the entire image
> directory instead of having to extract the files from a MySQL table.

That is, of course, one possible advantage, but I'm not quite convinced
this possibility/feature is so widely and often needed.

> Check out perldoc perltoot for details.

Thank you.

Greetings,
Timwi


list: wikitech-l

source: pipermail-mbox

from_name: steve vertigo

subject: [Wikitech-l] RE: Phase IV (Python whitespace, namecalling)

body:
While ts not necessary to decend into namecalling
(moronism) --  it was certianly necessary for Tomasz
to call Hunter's comments "language propaganda" --
sometimes we forget to direct our comments at the
right people -- and I think this is why Hunter was
getting buggy in replying to Tarq....

Just Clarifying
-S-

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


list: textbook-l

from_name: Tomasz Wegrzanowski

subject: [Textbook-l] No new wikis

body:
On Sat, Jul 26, 2003 at 05:40:00AM +0200, Erik Moeller wrote:
> Toby-
> >> Anyone is of course free to start their own project on their own servers,
> >> but a Wikimedia brand project should have support from a substantial
> >> number of, er, Wikimedians. We're not a wiki hosting provider.
>
> > Since when does Wikimedia take votes to make these decisions?
>
> We never did. I proposed that we should start.

There is no consensus to switch from using consensus to using voting.


subject: [Wikitech-l] RE: Phase IV (Python whitespace, namecalling) (correction)

body:
While ts not necessary to decend into namecalling
(moronism) --  it was certianly NOT necessary for
Tomaszto call Hunter's comments "language propaganda"....

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


list: wikien-l

from_name: viajero at quilombo.nl

subject: [WikiEN-l] Wikipedia: Warehouse or Pyramid?

body:
Hi all,

I am fairly new to Wikipedia and I would like to ask the advice of some
of the more experienced wikipidians.

To begin with, I am impressed with the high quality of the writing of
some of the articles. But there are also plenty which need lots of
work, and I enjoy wrestling with these ungainly creatures, restructuring
them, chopping out redundancies, tightening up the prose, adding
sub-headings and good intros, improving transitions, etc. etc. etc.

Of late, however, I have been coming into conflict with another user,
whom I will refer to as X.

X is a prolific contributor to Wikipedia with a proclivity for gathering
large amounts of information about fairly obscure topics, such as
provincial towns and cities, transportation networks, and the like.  It
is perhaps an extreme example, but I even encountered a entry he had
written on a metro system currently under construction in a major
European capital, listing all of the proposed subway stations.  All well
and good; it is all valid information, except that this metro system
won't be operational until 2011 (!).  It made wonder about X's
priorities.

And herein lies the crunch. To begin with, X favors wikifying words, such as

  beach
  theater
  city hall
  performance
  pool
  reflection
  beach

in situations where there is no high-level thematic relation; they are
simply used as common English words. In my view, such items shouldn't be
Wikified. In support of my view, I found the following Wikipedia page:

  Make_only_links_relevant_to_the_context

(I have also noticed other users unwikify contextually insignificant
words so I know I am not alone.)

X wrote on a Talk page that he thinks they all belong, that people can
ignore them if they are not useful, that they alert people to
other articles in the encyclopedia.

OK, no big issue.

More critical for me, however, is that X adamantly opposes removing ANY
information from Wikipedia: everything that goes in cannot go out.
X doesn't oppose my copyedits -- fortunately, because he is no stylist
-- but if I remove so much as a single factoid from an article he has
edited, X replaces it within fifteen minutes or so.

In brief interchanges via Talk pages, it is becoming clear that X and I
have diametrically opposed philosophies on how to create encyclopedia
articles. X appears to believe that all information is of equal value
and all should be collected in the encyclopedia, what I would call the
"warehouse" approach.  I feel an encyclopedia is more like
building a pyramid, developing hierarchies, prioritizing
information, developing a critical eye for what should be included and
what not, all with the aim of producing well-organized, well-written,
balanced articles containing the right amount and right kind of
information.

Up until a short while ago, X rolled back deletions I made one by one,
which didn't please me, but I could live with it.  However, yesterday he
reverted an entire article in which I dewikified a couple of common
words, thereby junking other edits I had also made.  It was a short
article, not particularly important to me, so I let it be.  But there
are other more substantial articles dearer to my heart (that X has also
worked on) which I feel need work, but I don't feel that now I can
comfortably do so.

I respect X's formidable information gathering skills; raw data is of
course indispensable in the construction of an encyclopedia.  But he
doesn't appear to respect me as an editor interested in presenting
information in a useful way.  I would be interested in suggestions
anyone may have for resolving my predicament, as I would very much like
to continue to contribute freely to Wikipedia.

--
  Viajero


subject: [Wikitech-l] Re: Phase IV

body:
On Sat, Jul 26, 2003 at 01:33:14AM -0700, Hunter Peress wrote:
[cut]

Please, no language propaganda here. If you want to help -
write code. Patches to current codebase prefered.

If your only problem is that you don't like how Perl looks like,
write a module that will make it look like Python - it's perfectly
possible in Perl. Or write some magic syntax highlighter to your
editor.


subject: [Textbook-l] request Admin status

body:
On Sat, Jul 26, 2003 at 05:04:24AM -0700, Daniel Mayer wrote:
> Erik wrote:
> >You don't need to be admin to move pages,
> >you just need to be logged in. Do you still want
> >to be admin?
>
> Yep - you are right. The fact that the Admin interface has "Delete this page |
> Protect this page | Move this page" on the bottom threw me since "Move this
> page" is not on the bottom on the standard user skin (failing to see that I
> didn't even look at the sidebar).
>
> But yeah - why not? At the very least I'll get the "Move this page" link where
> I'm used to having it. ;-) I suggest Karl Wick also be an Admin (if he isn't
> already) since he is the most active person right now and hence the person
> most likely to notice vandalism before anybody else.

Done, 2 sysops now.


list: wikipedia-l

from_name: Delirium

subject: [Wikipedia-l] Do we really need a Sifter project?

body:
I like the idea of a Sifter project, and it would be a necessary
prerequisite for a future publication of Wikipedia in paper form, if
anybody ever wished to do such a thing.  It also might be an indication
to people that they can treat the articles like "real" encyclopedia
articles, and do things like cite them in papers, whereas in the current
state of Wikipedia everything always has to be taken with a grain of
salt (even a Sifter-approved article would have to be taken skeptically
of course, but not quite as skeptically).

-Mark


from_name: Timwi

subject: [Wikitech-l] Re: Cologne Blue mod

body:
Tomasz Wegrzanowski wrote:

> Sure I could use one of my machines for testing, but it has been always
> done on *.wikipedia.org, so why suddently change it ?

I haven't been here for long, so I don't know about earlier, but from
what I have read on this list since I'm here, other developers have been
using their own machine all the time (esp. for big things like the TOC
and category stuff), like I have (for the little apostrophe thing,
remember?).

Timwi


from_name: a.crossman at blueyonder.co.uk

subject: [WikiEN-l] DOS attack?

body:
Question: if Wikipedia was under a DOS attack of some sort, would we
know about it? I ask because there was an incident of repeated
vandalism today, and just after that was dealt with, Wikipedia became
very (very) slow.

So I just thought a DOS attack was a possibility. Is it? :-)

--
Allan Crossman
a.crossman at blueyonder.co.uk
http://dogma.pwp.blueyonder.co.uk


from_name: Daniel Mayer

subject: [Textbook-l] request Admin status

body:
Tomasz Wegrzanowski wrote:
>Done, 2 sysops now.

Cool - thanks.

--mav


from_name: Hunter Peress

subject: [Wikitech-l] RE: Phase IV

body:
Not as fast ?  Again, no one acknowledges psyco.

Which i said that for the difflib speed it up JUST as fast as C.

Want examples? Here is a COMPLETE package of MINE with the pure python difflib and the C-python
difflib.

You should compare the speed of: pure python, psyco-python, and C-python. You will have to
download kernel source (which is used as the test data).

Obtain psyco (i386 only) at psyco.sf.net , then simply drop it in
/usr/lib/python2.2/site-packages.

My file compare.py has commented out code that gets  psyco running (which is as simple as:
import psyco
psyco.bind(function_name)
and all functions called from this will be recursively optimized.

MY POINT: your comments that python is slower than php are based in reaction and not fact. Your
comments that php is designed for the web is true, however it is mereley a coment, not an
argument.

In my 1st email i show 3 content-management systems for python. THere are even wikis built on top
of these. (1 on twisted, 1 on zope, and 1 on plain python cgi which is sped up by mod_python,
something that causes python to have the "built for web" feature that php has, namely that only 1
process runs inside apache, instead of a new one for each request.)

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


subject: [Wikitech-l] RE: Phase IV link to my package.

body:
Here is the tarball which shows a combination c-python difflib (optimized where the profiler
showed the largest bottleneck).
Using the unit test style scripts i provide should compare it to pure python and psyco python  and
you will see that the C runs just as fast as the psyco.

http://24.175.39.66/~hperes/c_difflib.tar.gz

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


from_name: Walter Vermeir

subject: [Textbook-l] [INFO] Textbook-l now on gmane

body:
The mailing list Textbook-l is now also on gmane

http://mail.wikipedia.org/mailman/listinfo/textbook-l

Use the newsserver "news.gmane.org"

The name of the newsgroup is

"gmane.org.wikimedia.textbook"

gmane is a mailing list to usenet interfase

For posting to the newsgroup you must be a list member. The first time you
post to the newsgroup you will receive an email for verification of your
email address, which is normal. If you work by means of the newsgroup you
probably no longer wants to receive the messages by email. To disable email
delivery go to "Edit Options".
( see http://mail.wikipedia.org/mailman/listinfo/textbook-l )

All the other Wikipedia mailing lists are also available on gmane.
Search for wikipedia on the list of newsgroups of news.gmane.org

--
Contact: walter AT wikipedia.be
Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
http://www.wikipedia.be


subject: [Wikipedia-l] [INFO] Textbook-l now on gmane


from_name: Nick Reinking

subject: [Wikitech-l] Re: Phase IV

body:
On Sat, Jul 26, 2003 at 05:50:13PM -0400, Lightning wrote:
>
> >I do not know PHP good enough to compare it to Python, but I am sure that
> >Python would be an excellent choice since it is very easy to learn, has
> >some support for OOP and is very intuitive.
> >
> I'm sorry, but as a _personal_ preference I think  interpreted
> whitespace is a terrible idea. Sorry if you dont agree. As or a code
> switch, I have no doubts that python is a great language, it has many
> fans.. but I see no reason to switch.. sure its easy to learn, but the
> current developers already know php. Not too mention php is really easy
> to learn and understand. I mean really, you try and tell me php is hard
> or obfuscated or difficult to read or undocumented. You can't argue with
> that, the documentation available as well as the resources available for
> php are great, the built in functionality is great too. While it may not
> yet have as much available free code as PERL there is lots of availabe
> code to reuse, especially for the kind of thing we are currently doing.
> Besides.. really I want someone to post what exactly we would gain by
> switching languages, and why its worth the hundreds of manhours it would
> take to port the code.  Why can't we just spend that time improving the
> current code?
>
> Lightning

While I do think that Python is a cleaner language than PHP with much
better OO syntax and namespaces, I do not believe that it should be the
language of choice for Wikipedia for a couple of reasons.  First and
foremost, there is no way to get Python working as fast as PHP, and we
need every ounce of performance that we can eek out based on our current
infrastructure.  If we had a huge Sun box with 16GB of RAM and 8 CPUs, I
wouldn't worry so much, but we don't.  Furthermore, it would seem to be
a terrible waste to throw away all those manhours we have already put
into the PHP code.  I think we would be better off cleaning up the
admittedly messy PHP code and possibly adding in my C parser (if I
ever get around to getting the ugly list syntax working).

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN


from_name: Erik Moeller

subject: [WikiEN-l] 172 sysop status temporarily revoked

body:
Axel-
> I am thankful for your handling sysop requests on Wikipedia. This does
> not include your unsysoping people with whom you had a conflict,
> without prior discussion on this list.

It is hardly accurate to describe my actions as "unsysoping people with
whom I had a conflict." As a matter of fact, I made explicitly clear in my
mail that I agreed with 172's assessment of the changes to
[[Catholicism]]. What I did is try to enforce our existing Protected Page
policy. I will not do this in the future unless there is a real emergency
(a sysop protecting hundreds of pages without need etc.). Instead, I will
send a mail to Jimbo and he will then inform the list if he thinks a
decision is necessary.

Regards,

Erik


subject: [Textbook-l] No new wikis

body:
Tomasz-
> On Sat, Jul 26, 2003 at 05:40:00AM +0200, Erik Moeller wrote:
>> Toby-
>>>> Anyone is of course free to start their own project on their own servers,
>>>> but a Wikimedia brand project should have support from a substantial
>>>> number of, er, Wikimedians. We're not a wiki hosting provider.
>>
>>> Since when does Wikimedia take votes to make these decisions?
>>
>> We never did. I proposed that we should start.

> There is no consensus to switch from using consensus to using voting.

There doesn't need to be. Such policy decisions are made, and have been
made, by Jimbo.

Regards,

Erik


subject: [Wikitech-l] Re: Phase IV

body:
On Sun, Jul 27, 2003 at 12:07:39AM +0200, Tomasz Wegrzanowski wrote:
> On Sat, Jul 26, 2003 at 05:00:50PM -0500, Nick Reinking wrote:
> > I think we would be better off cleaning up the
> > admittedly messy PHP code and possibly adding in my C parser (if I
> > ever get around to getting the ugly list syntax working).
>
> If someone doesn't understand this yet:
> 	    NO C CODE SHOULD BE USED ON WIKIPEDIA EVER
>
> It's suicidally insecure.

That's rediculous - just because C can be insecure doesn't mean it has
to be.  We rely on PHP every day, which, surprise surprise, is written
in C.  What do you think PHP is?  It's just a C program that interprets
specially formatted HTML and runs a bunch of internal C functions.  As
such, it is just as suspect to buffer overflows and what-not as any
custom written C code that we might write.

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN


subject: [Wikitech-l] RE: Phase IV

body:
I agree with erik. This thread is over for all i am concerned.

If something python is going to happen, it will happpen and THEN i should bring it to the list.

Lets get back to doing instead of saying. The simple fact is that the code base is in php, and
although "phase" implies a paradigm shift, switching to another language would be too much of a
shift atm.

I am working on some interesting things for wiki. I talk about one in a few days.

ciao

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


subject: [Wikitech-l] Re: Phase IV

body:
On Sat, Jul 26, 2003 at 06:17:46PM -0400, Lightning wrote:
> hmm i kind of agree. i like the idea of a c parser, and i love C but i
> just can't see it being a good idea. too much risk for overflows, etc.
> I mean, i have no doubt it could be done securely.. but i just dont know
> theres too much room for errors...

I should say that my parser is written in flex, which in all likelyhood
is the exact same way PHP is written.  No real difference between how
PHP works and how a custom written C parser would work.

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN


subject: [Wikitech-l] Re: Phase IV

body:
> Many people thought they are wise enough not to do any such mistake,
> and they have been all proven wrong. Even such security paranoids
> as OpenBSD people.
>
> We are using C code all the time, but this code have been checked
> by thousands of people, and despite this, stack and heap overflows
> are being found in it all the time.
>
> Risk is too high, and benefit is too small.
>
> Anyway, lex and yacc are available for almost all languages,
> that's no excuse for using C.

As I was saying, the code is already written in flex, which produces C
anyways.  In fact, I have gone out of my way to not allocate any string
structures, instead relying on flex and its functions to jump around in
the various strings.  The only place where I actually do store strings
in is the list code which is why it is taking so long and is so damned
annoying.

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN


from_name: Lightning

subject: [Wikitech-l] RE: Phase IV

body:
Hunter Peress wrote:

>all responses so far are pure reactions, and show that no one acknowledged much of what i brought
>forth:
>
>That python has an optimizing JIT (that we used on f.scarywater.net which is a BitTorrent server
>that handles 12,000 users, and saw a 40% decrease in CPU load). That i have personally written
>things in C and that this JIT has met its performance. That it has a profiler.
>
>That it is a language with focus  http://www.python.org/dev/culture.html and professional
>acceptance specifically over all languages (see the oreilly link).
>
>Whitespace as a cause of errors? jeez... ever heard of unit testing ?
>
>Simply moronic.
>
>
Hey you know, different folks different strokes. Yeah sure python may be
real good. and hey you know ruby might be even better.. and endles list.
everyone has a reason to use the language they like. Simple point is
that php was designed to make web interfaces, it was designed to do
exactly what its doing right now, do it well, and do it easily. And you
know what... its doing fine i believe. I really don't thing that the
language the wiki is written in will affect the ammount of features
available, because prretty much anything we want can be done in any
language, some are easier in some, some are easier in others. For
example PERL seems well suited for the task of the module that parses
the wiki syntax. PHP and mysql might as well be joined at the hip. php's
mysql is supperb and no matter what people say about postgres or oracle
or what not, the FACT is that we are using mySQL and we probably will be
for a while seeing as there is as of yet no real reason to switch
databases another fact is that we have php software that is running
fine. Php has great support for everything we currently need and has a
lot of nice features built in like sessions, and the fact that it
integrates into mySQL and apache so well. Sure there is features we all
would want.. but its not a matter of language.  Those features have to
be written in any language. The hundres of man hours it would take to
port would be better spent fixing the current code base. Oh, and if you
don't like the current code base, go write your own.. theres nothing
stopping you.

and bout the whitespace thing.. learn to handle som picking.. its like
if timwi was to get offended over me calling perl code obfuscated.

Lightning


from_name: tarquin

subject: [Wikitech-l] Re: Phase IV

body:
Lightning wrote:

> I love those magic curly braces....

I love the way that in perl, you can put curlies *anywhere*, and declare
local vars to that curly block  :)

TextPad does good syntax highlighting for Perl


body:
There have been long discussions about having a separate "Sifter" project
which publishes selected revisions of existing Wikipedia articles that are
believed to be accurate and complete. Such a Sifter project would exist
alongside Wikipedia under a different name. Similarly, I have proposed a
system for certifying articles within Wikipedia.

Both may not be necessary.

The German and the English Wikipedia currently use a quite clever process
for selecting the so-called "Brilliant Prose" articles, the best of
Wikipedia, so to speak. Articles are first added to a "Brilliant Prose
Candidates" page, and if there are no objections within a week, they are
added to the Brilliant Prose directory. If there are objections, they have
to be resolved in some way.

This alone is already a kind of certification process, but it lacks one
component that the Sifter project provides, namely, the establishment of
trust by only linking to "safe" revisions of an article. This could be
integrated into the Brilliant Prose process relatively easily.

In the article footer (where the license stuff is), there could be a
"permalink" to the current revision of the article, which would simply be
a link with a timestamp like in the article history. When an article is
added to BP, this permalink would be used instead of a normal wiki-link.
Furthermore, the BP page itself would be protected, and only sysops would
actually add or remove articles from the BP candidates list to the BP
page. Similarly to the "Votes for Deletion" page, sysops would simply
carry out the requests of the community.

I would personally prefer if a process was in place that if a consensus
cannot be reached within a timeframe, the page is added to a list of
"Current negotiations", where again, for a period of 7 days, people would
be invited to suggest compromises and if that *also* fails, a vote is held
on the matter. This is to avoid problems like on the VfD page, where
sysops are given quite a lot of room for interpretation if a "consensus"
has been reached, and pages often linger without a decision for days or
even weeks.

The last component that might be necessary to make this work is an
associated WikiProject to organize the reviewing process. This is simply a
matter of organization.

The advantages of this approach vs. a separate Sifter project:
* no separate brand to the Wikipedia brand, no separate community
* feedback from all Wikipedians, not just those specializing in the
discipline in question -- besides being complete and accurate, articles
also must be reasonably well written and easy to understand
* establishes trust in Wikipedia
* simple, easy to use and completely open
* requires only one change to the software (permalinks), which is useful
anyway for external authors trying to provide a permanent reference to the
revision of the Wikipedia article they cite
* Does not encourage the establishment of any POV in the selected
revisions:
   In a Sifter project, people might just make some last minute changes
and then put the revision that contains these changes on the separate
site, knowing full well that the changes won't survive on the Wikipedia,
whereas in this model, changes would have to survive the Wikipedia
consensus process, so it works with existing NPOV guidelines

One possible disadvantage I see is that it might be harder to "launch"
this project -- when there's a new separate project there's always the
associated excitement, whereas a new WikiProject might not arouse the same
level of interest. On the other hand, if we get too much interest, the
candidate page might get too long, and we would have to split it up into
different categories. Both are not unsolvable problems.

What do you think? If we do this, I think we should basically put every
brilliant prose article that hasn't gone through this process in the new
queue, just in case some of them might not be as brilliant (anymore) as
the person who originally added them thought.

Regards,

Erik


subject: [Wikitech-l] Re: Phase IV

body:
>I do not know PHP good enough to compare it to Python, but I am sure that
>Python would be an excellent choice since it is very easy to learn, has some
>support for OOP and is very intuitive.
>
I'm sorry, but as a _personal_ preference I think  interpreted
whitespace is a terrible idea. Sorry if you dont agree. As or a code
switch, I have no doubts that python is a great language, it has many
fans.. but I see no reason to switch.. sure its easy to learn, but the
current developers already know php. Not too mention php is really easy
to learn and understand. I mean really, you try and tell me php is hard
or obfuscated or difficult to read or undocumented. You can't argue with
that, the documentation available as well as the resources available for
php are great, the built in functionality is great too. While it may not
yet have as much available free code as PERL there is lots of availabe
code to reuse, especially for the kind of thing we are currently doing.
Besides.. really I want someone to post what exactly we would gain by
switching languages, and why its worth the hundreds of manhours it would
take to port the code.  Why can't we just spend that time improving the
current code?

Lightning


subject: [Wikitech-l] Re: Phase IV

body:
Tomasz Wegrzanowski wrote:

>On Sat, Jul 26, 2003 at 05:00:50PM -0500, Nick Reinking wrote:
>
>
>>I think we would be better off cleaning up the
>>admittedly messy PHP code and possibly adding in my C parser (if I
>>ever get around to getting the ugly list syntax working).
>>
>>
>
>If someone doesn't understand this yet:
>	    NO C CODE SHOULD BE USED ON WIKIPEDIA EVER
>
>It's suicidally insecure.
>

hmm i kind of agree. i like the idea of a c parser, and i love C but i
just can't see it being a good idea. too much risk for overflows, etc.
I mean, i have no doubt it could be done securely.. but i just dont know
theres too much room for errors...

Lightning


subject: [Wikitech-l] Re: Phase IV

body:
Nick Reinking wrote:

>On Sat, Jul 26, 2003 at 06:17:46PM -0400, Lightning wrote:
>
>
>>hmm i kind of agree. i like the idea of a c parser, and i love C but i
>>just can't see it being a good idea. too much risk for overflows, etc.
>>I mean, i have no doubt it could be done securely.. but i just dont know
>>theres too much room for errors...
>>
>>
>
>I should say that my parser is written in flex, which in all likelyhood
>is the exact same way PHP is written.  No real difference between how
>PHP works and how a custom written C parser would work.
>

that sounds a whole lot more friendly.. i like the idea more now. You
know what would be REALLY cool. if you made your parser a php module..
so we could compile it into php, them it would be like... amazing fast..
yeaahhh im liking how that sounds.

Lightning


subject: [Textbook-l] No new wikis

body:
On Sat, Jul 26, 2003 at 05:13:00PM +0200, Erik Moeller wrote:
> > There is no consensus to switch from using consensus to using voting.
>
> There doesn't need to be. Such policy decisions are made, and have been
> made, by Jimbo.

Don't pretend you don't know how world works. Nobody has any "magical"
powers over the project. It's open projects and if things will be done
against will of contributors, people will just move away. Last time we
had this problem with advertising, it ended with Enciclopedia Libre fork.


body:
On Sat, Jul 26, 2003 at 05:45:00PM +0200, Erik Moeller wrote:
[cut]

I don't know how BP looks like now, but in the past lot of povful shit
managed to get into the list, so I wouldn't count on these articles being
any good.


from_name: Thomas R. Koll

body:
On Sat, Jul 26, 2003 at 05:45:00PM +0200, Erik Moeller wrote:
> This alone is already a kind of certification process, but it lacks one
> component that the Sifter project provides, namely, the establishment of
> trust by only linking to "safe" revisions of an article. This could be
> integrated into the Brilliant Prose process relatively easily.

As far as I know currently articles only evolve and don't get worse!
So linking to the current version shouldn't be a mistake. Spam and
keyboard tests are undone quickly by us Admins.
I'd suggest that changes in BPs should get an own recent changes so we
can control them easier.

> I would personally prefer if a process was in place that if a consensus
> cannot be reached within a timeframe, the page is added to a list of
> "Current negotiations", where again, for a period of 7 days, people would
> be invited to suggest compromises and if that *also* fails, a vote is held
> on the matter. This is to avoid problems like on the VfD page, where
> sysops are given quite a lot of room for interpretation if a "consensus"
> has been reached, and pages often linger without a decision for days or
> even weeks.

A few days ago I suggested at the German a voting system, like 5 admins or
20 user yes-votes (for German WP) and the article goes from the candidate
list to the brilliant prose page. It could be automated and also the links
to BP could be marked with a star so the reader knows that this link is
BP. A new table for the BP would be necessary I think.

> * requires only one change to the software (permalinks), which is useful
> anyway for external authors trying to provide a permanent reference to the
> revision of the Wikipedia article they cite

If we introduce them, can we have <a href="#top3"> too?

--
ACHTUNG: Ab 26.7.03 haben wir wegen einer kurzfristigen
Absage noch eine Ferienwohnung f?r zwei Wochen frei.
Tel: 08652/63382 http://www.tomk32.de/fewo-koll/


subject: [Wikitech-l] Long and Short pages. how to bring them back

body:
Hey. I was thinking, I hated seeing  short and long pages go. I have an
idea for returning them..  i dont feel like explaining in english, so i
hop you understand...

ALTER TABLE `cur` ADD `art_len` MEDIUMINT UNSIGNED;
ALTER TABLE `cur` ADD INDEX ( `art_len` ) ;

/////ARTICLE.PHP -- insertNewARticle()

replace :

$sql = "UPDATE cur SET cur_text='" . wfStrencode( $text ) .
              "',cur_comment='" .  wfStrencode( $summary ) .
              "',cur_minor_edit={$me2}, cur_user=" . $wgUser->getID() .
              ",cur_timestamp='{$now}',cur_user_text='" .
              wfStrencode( $wgUser->getName() ) .
              "',cur_is_redirect={$redir}, cur_is_new=0,
cur_touched='{$now}', inverse_timestamp='{$won}' " .
              "WHERE cur_id=" . $this->getID();

with this:

    $sql = "UPDATE cur SET cur_text='" . wfStrencode( $text ) .
              "',cur_comment='" .  wfStrencode( $summary ) .
              "',cur_minor_edit={$me2}, cur_user=" . $wgUser->getID() .
              ",cur_timestamp='{$now}',cur_user_text='" .
              wfStrencode( $wgUser->getName() ) .
+            ",art_len=".strlen($text).
              "',cur_is_redirect={$redir}, cur_is_new=0,
cur_touched='{$now}', inverse_timestamp='{$won}' " .
              "WHERE cur_id=" . $this->getID();

/////SPECIALLONGPAGES.PHP  ~line 21

from
$sql = "SELECT cur_title, LENGTH(cur_text) AS len FROM cur " .
      "WHERE cur_namespace=0 AND cur_is_redirect=0 ORDER BY " .
      "LENGTH(cur_text) DESC LIMIT {$offset}, {$limit}";

to:
$sql = "SELECT cur_title, art_len AS len FROM cur " .
      "WHERE cur_namespace=0 AND cur_is_redirect=0 ORDER BY " .
      "art_len DESC LIMIT {$offset}, {$limit}";

Whats everyone think?   Yes yes I know it involved adding another column
and an index.. but those pages really were usefull...  I mean, at least
I thought they were... and I know its kind of hackish.. but there's no
reason not too try it. If we implement it early in the other wikipedias
it saves the cost of doing a huge alter table.. and it lets them keep
those 2 special pages  even if they grow a lot like the english wiki

Lightning


subject: [Textbook-l] No new wikis

body:
Tomasz-
> On Sat, Jul 26, 2003 at 05:13:00PM +0200, Erik Moeller wrote:
>>> There is no consensus to switch from using consensus to using voting.
>>
>> There doesn't need to be. Such policy decisions are made, and have been
>> made, by Jimbo.

> Don't pretend you don't know how world works. Nobody has any "magical"
> powers over the project. It's open projects and if things will be done
> against will of contributors, people will just move away. Last time we
> had this problem with advertising, it ended with Enciclopedia Libre fork.

First, it is unlikely that a decision to use voting before starting a new
project would inspire a movement of contributors against it, given that
such contributors would be a small minority and scattered across all
Wikipedias (notably, the decision by Jimbo to authorize a vote on the
article count methodology did not have any such repercussions, nor will
the vote on the new logo).

Second, any fork at this point is unlikely to succeed. The Enciclopedia
Libre fork happened in the early stages of the Spanish Wikipedia (and
great good did it do them -- they're using outdated software, and the
Spanish Wikipedia just keeps on growing; they just reached 5000 articles).
The larger the project is, the more difficult will it be to keep two forks
in sync, and this alone discourages forking to a substantial degree. Of
course, Jimbo would probably not make a decision of which he knows that it
would alienate a significant number of users. But the type of decision we
are talking about does clearly not fall into this category.

Regards,

Erik


body:
Thomas-
> On Sat, Jul 26, 2003 at 05:45:00PM +0200, Erik Moeller wrote:
>> This alone is already a kind of certification process, but it lacks one
>> component that the Sifter project provides, namely, the establishment of
>> trust by only linking to "safe" revisions of an article. This could be
>> integrated into the Brilliant Prose process relatively easily.

> As far as I know currently articles only evolve and don't get worse!
> So linking to the current version shouldn't be a mistake. Spam and
> keyboard tests are undone quickly by us Admins.
> I'd suggest that changes in BPs should get an own recent changes so we
> can control them easier.

Well, the idea of the Sifter project was to create a stable space where
articles can *never*, by definition, be in an undesirable state. We can
only replicate this by linking to specific revisions. Furthermore, it
seems reasonable that substantial changes to an article would have to be
re-approved -- while they may well make an article better, I have seen
many articles get a lot worse by reorganizations, so-called NPOVing or
unnecessary fluff that was added with good intentions. Aside from that,
any Wikipedia article may at the time the reader views it contain
something like the goatse.cx photo, or other types of vandalism, and by
linking only to verified good revisions, we would create a kind of safe
area where we can send Jimbo's mother without concerns for her mental
health.

By the way, I have seen pages that were vandalized for months until
someone fixed them.

Regards,

Erik


subject: [Wikitech-l] Anti troll mechanism

body:
Crap, crap, http://meta.wikipedia.org/wiki/International_logo_contest was just vandalised.

If it is ok with some people, I think I should code a feature so that non-registered users are not
allowed to delete anymore than 50 characters in a row. (as you just have found out, i hacked
around with difflib.php in order to get some ideas for the difflib.py that i worked on, so i could
do this quickly).

I believe 50 characters might even be too much.

I think the same should go for adding?

Next, we have to consider that if joe-IPaddress gets a warning that " you have tried to delete 50
characters or more, this is not allowed unless you register" might start to game the system with a
wget script.

The simple fact is,however, that they could already do that before this security feature is
implemented.

HOWEVER, seeing this warning might incurr more aggressive behaviour on the whole.

What do you think?

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


subject: [Wikitech-l] RE: Phase IV

body:
Hunter Peress wrote:

>Not as fast ?  Again, no one acknowledges psyco.
>
>Which i said that for the difflib speed it up JUST as fast as C.
>
>Want examples? Here is a COMPLETE package of MINE with the pure python difflib and the C-python
>difflib.
>
>You should compare the speed of: pure python, psyco-python, and C-python. You will have to
>download kernel source (which is used as the test data).
>
>Obtain psyco (i386 only) at psyco.sf.net , then simply drop it in
>/usr/lib/python2.2/site-packages.
>
>My file compare.py has commented out code that gets  psyco running (which is as simple as:
>import psyco
>psyco.bind(function_name)
>and all functions called from this will be recursively optimized.
>
>
>MY POINT: your comments that python is slower than php are based in reaction and not fact. Your
>comments that php is designed for the web is true, however it is mereley a coment, not an
>argument.
>
>In my 1st email i show 3 content-management systems for python. THere are even wikis built on top
>of these. (1 on twisted, 1 on zope, and 1 on plain python cgi which is sped up by mod_python,
>something that causes python to have the "built for web" feature that php has, namely that only 1
>process runs inside apache, instead of a new one for each request.)
>
>
You know, I just don't remember saying anything about pythons speed.
Please remind me which e-mail i said that on, I can't recall, i don't
think I said anything about it's speed. I might have forgotter, so if
you ever find those words, please let me know.

 And as I said, python sounds like very nice language, i just don't see
the reason to switch  to it.   Yes I know you have mod_python.. and
there's mod_perl too... and you know.. I still see no reason to switch,
there is CMS's written in perl, ruby, python, c, c++, asp, jsp, and tons
of other languages.... like i said the language makes no difference
really. what makes a difference is how much code we already have written
and *working* on a live site.  Oh and im sure your difflib is
fantastic.. but i see no reason for me to download it.

Oh, and is the MIT license psyco is under GPL compatible??  hehe.. for a
minute i thought you were calling me psycho and forgot the H.

Lightning


body:
Hunter Peress wrote:

>Here is the tarball which shows a combination c-python difflib (optimized where the profiler
>showed the largest bottleneck).
>Using the unit test style scripts i provide should compare it to pure python and psyco python  and
>you will see that the C runs just as fast as the psyco.
>
>
>http://24.175.39.66/~hperes/c_difflib.tar.gz
>

ok. your difflib is really fast. whats the point??  nobody doubted the
speed of psyco or python or your difflib...

Lightning


subject: [Wikitech-l] Anti troll mechanism and non registered users

body:
hmm, so I was thinking about the performance hit from the extra difflib call. There are two
choices:

put ALL non-registered users under a separate process that is niced to be of lower priority
(higher nice) than the registered version.

OR simply use an if statement to only do the difflib/anti-troll call for non-registered.

If you agree with me that trolling is an issue and that my solution is effective (or some derivate
of it yet to be chiseled out), then it will be FACT that non-registered users will put more hit on
the server, thus its logical to put them at a lower priority (something that ALSO will be an
anti-troll mechanism).

ALSO, i believe that one 50 character add/delete (as discussed in previous message) should result
in automatic write-blocking until they make the effort to write an email (or use some web
interface) explaining their actions.

There are NO anonymity/privacy issues from making someone register.

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


subject: [Wikitech-l] LanguageZh.php  developers ISSUE

body:
HOLY shit, live, boilerplate code? this is unnaceptable. The language script should be a simply
dictionary of key/values where there is no room for error. If its ok with everyone I will refactor
the code to make this so.

Sheng Jiong (i am not writing this to you).

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


subject: [Wikitech-l] RE:Anti troll mechanism

body:
RE: the first response, I am disinclined to respond, however since I prefer to deal with this
"argument" (which it is not):

My solution does NOT disable non-registered users, it merely limits them to be able to do less
damage.

Sure, a registered user can do as much damage, but this system limits the power of one idiot, and
in this electronic age, all it takes is 1....person to crack dvd encrypting....person to release a
virus... Im not trying to be black and white here, I want to have a discussion, which my 2
previous emails lay the groundwork-for.

the simple fact IS that we are in continual presence of data decay.

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


subject: [Wikitech-l] RE:Anti troll mechanism

body:
There has never been any trouble with anons??

Thus, we should look at hard data, namely the ratio of banned IP's from registered users, and NOT.

To answer this question O(1) code must be written.

In irc just now, taw and I discussed the above. He even asks "maybe we should restrict editing of
even registered users".

Given the lack of solid information I was looking for, my brain cant work this fast at infereing
and simulating for this one task ;-). i need to let the ideas settle in while hopefully some good
commentary can be made.

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


from_name: Marco Krohn

body:
On Saturday 26 July 2003 18:32, Thomas R. Koll wrote:

> A few days ago I suggested at the German a voting system, like 5 admins or
> 20 user yes-votes (for German WP) and the article goes from the candidate
> list to the brilliant prose page. It could be automated and also the links
> to BP could be marked with a star so the reader knows that this link is
> BP. A new table for the BP would be necessary I think.

what makes me a bit afraid that this method does not necessarily involve
someone who is an expert in the field. Articles like
[[?berlichtgeschwindigkeit]] (see german wikipedia) got several positive
votes where I would claim that everyone who has some insight in the topic
would never agree that this is an excellent article.

I did not read your suggestion, where can I find it?

best regards,
  Marco


body:
We can use Erik's idea for adding neat features to the Brilliant prose page as
a start. Then that page can act as a queue for articles that Nupedia can
take-up and then put through a simplified Nupedia polishing process by area
experts. The Sifter software can be used to make this easy but it is not
really needed.

But a stable distribution vetted by area experts (at the very least by people
with baccalaureate degrees in the subject area) /is/ a very important thing
for us to have.

With such a system set-up we can start to work toward 1.0 status.

-- mav


body:
steve vertigo wrote:

>I think this is why Hunter was
>getting buggy in replying to Tarq....
>
>
>
I officially *Don't Know What The Heck I'm Talking About* when it comes
to which language to use.
I'd like perl, but purely for personal reasons (I can just about read it).

So consider me as not part of this discussion :)

>
>
>


body:
Mav typed: "But a stable distribution vetted by area
>experts (at the very  least by people with
>baccalaureate degrees in the subject area) /is/ a
>very important thing for us to have. "

I love this circular trend -- communism degrades into
totalitarianism and abuse of power --  Then comes
capitalist revolution and a little later, bourgeois
attitude and abuse of wealth, then until socialist
revolution takes over again.

Consider this trend here -- Nupedia was elitist and
produced nada.  The Wikipedia was a revolution that
became the flagship wiki on the web. Democratize
everything! Limit no user! Spam? Vandalism? Well
handle it!   Then came complaints and calls for
push-button corrections -- overstressed people quit. (
F($&) p(#*(# -- as George Carlin would say)

Then comes again the old idea of making a New Nupedia
again -- control everything! -- show us your
credentials!  Lets sell textbooks! What a load!-*

-S-

We can use Erik's idea for adding neat features to the
Brilliant prose page as
a start. Then that page can act as a queue for
articles that Nupedia can take-up and then put through
a simplified Nupedia polishing process by area
experts. The Sifter software can be used to make this
easy but it is not really needed.

But a stable distribution vetted by area experts (at
the very least by people with baccalaureate degrees in
the subject area) /is/ a very important thing for us
to have.

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


subject: [Wikitech-l] request Admin status

body:
>It would be nice to be able to move pages - so to any
>developer
>out there; Can
>I be an Admin for the textbook project?

>How active does a wiki have to be to make 'move this
>page' a
>non-Admin option?
>Just wondering - no real biggie.

>-- Daniel Mayer (user:maveric149 internal ID #7)

Seconded

-S-

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


subject: [Wikitech-l] Anti troll mechanism

body:
Hunter Peress wrote:

>Crap, crap, http://meta.wikipedia.org/wiki/International_logo_contest was just vandalised.
>
>If it is ok with some people, I think I should code a feature so that non-registered users are not
>allowed to delete anymore than 50 characters in a row. (as you just have found out, i hacked
>around with difflib.php in order to get some ideas for the difflib.py that i worked on, so i could
>do this quickly).
>
>I believe 50 characters might even be too much.
>
>
>I think the same should go for adding?
>
>
>Next, we have to consider that if joe-IPaddress gets a warning that " you have tried to delete 50
>characters or more, this is not allowed unless you register" might start to game the system with a
>wget script.
>
>The simple fact is,however, that they could already do that before this security feature is
>implemented.
>
>HOWEVER, seeing this warning might incurr more aggressive behaviour on the whole.
>
>
>What do you think?
>
>
>
i think 50 might be too little. 50 could easily be a malformed sntence
of a POV sentence... maybe something like 80, or somewhere around there.
Just because 50 chars might easily be a small rewording,  especially
someplace where html entities are present, since a single one of those
is 4 charcters...  For  en it might be ok, but I don't know if it would
work for the foreign wikis

Lightning


body:
Delirium wrote:

> I like the idea of a Sifter project, and it would be a necessary
> prerequisite for a future publication of Wikipedia in paper form, if
> anybody ever wished to do such a thing.

I think we would wish to do that!
but I don't think PaperWiki and Sifter need be related.
Some articles might need to be *dramatically* edited down for Paper --
we would have to work to a set number of pages per subject area.
(count me in on it!)

>   It also might be an indication to people that they can treat the
> articles like "real" encyclopedia articles, and do things like cite
> them in papers, whereas in the current state of Wikipedia everything
> always has to be taken with a grain of salt

There was talk of making URLs for the version of a given date, for that
purpose. Did that happen?


subject: [Wikitech-l] Re: Phase IV

body:
On Saturday 26 July 2003 18:37, Lightning wrote:

> I'm sorry but asm uch as I dislike perl, I would never advise replacing
> it with a language that has interpreted whitespace. thats just asking
> for a bunch of stupid little errors.

Have you ever tried to program anything in Python? I have learned python a
couple of month ago and since then _never_ made any error which was related
to wrongly indented code. Since any serious programmer indents his code
anyway it is hard to believe for me that this could be a source of errors. In
fact after using python for a while I found it pretty intuitive and would
like more languages to adopt it :-)

I do not know PHP good enough to compare it to Python, but I am sure that
Python would be an excellent choice since it is very easy to learn, has some
support for OOP and is very intuitive.

best regards,
  Marco

--
Marco Krohn
Theoretical Physics
University of Hannover


from_name: sgilbert at nbnet.nb.ca

subject: [Wikipedia-l] Re: Wikis and uniformity

body:
Jimmy Wales wrote:

> sgilbert at nbnet.nb.ca wrote:
> > I believe Nupedia (Wikipedia's parent encyclopedia project) used
> > XML markup. That project had a division of labour between writers
> > and editors: the former simply wrote the articles, while the latter did
> > all the fancy markup.
>
> And it worked well enough to generate 12 articles in 18 months, at an
> exorbitant cost to me.  :-(

Don't be sad, Jimbo. Without Nupedia, there would be no
Wikipedia, so you got over 140,000 articles and counting for your
cash. Of course, they aren't all good, but surely there's more than
12. :)

Stephen G.
-------
Wikipedia: The Free Encyclopedia
http://www.wikipedia.org


from_name: Ramesh

subject: [Wikitech-l] Request Thattes Brain as EST Phenomenon

body:
Date 26 Th July 2003
  Request read my website www.thatte.net
 Request my Attached file thattesbrain
  Thanks
 Ramesh Thatte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030726/cfb672da/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Relative-Thatte Ramesh P.vcf
Type: text/x-vcard
Size: 1002 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030726/cfb672da/attachment.vcf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030726/cfb672da/attachment-0001.html>


from_name: james duffy

subject: [WikiEN-l] Erik's rewriting of policy pages unilaterally

body:
>Look, James, I know that it's fun slandering me, but I would appreciate it
>if you could stop for a second and actually read what I wrote. Thanks.

Yes I did read what you wrote and no I am not slandering you. I have a great
deal of respect for you but I think unilaterally rewriting a policy page
without a debate is grossly wrong. I am not always on wiki, neither are most
people. How are we to know if you have made a major change to a page if by
the time we come on your change has slipped from the Recent Changes list,
unless we go into every policy page and link it to our watchlist. A debate
can only happen if people know about it.

There are plenty of things on the policy pages that I believe are misguided
but I would not dream of going on and unilaterally changing them. I have
noticed a few changes to policy pages (not by you BTW). I always presumed
that they must have been debated and agreed first and that I had simply
missed the debate. Now you have me wondering if every change ''was'' debated
or if they were the unilateral work of some user that no-one noticed in
time, they know becoming a 'rule' by default.

JT.

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Re: Phase IV

body:
On Sat, Jul 26, 2003 at 05:00:50PM -0500, Nick Reinking wrote:
> I think we would be better off cleaning up the
> admittedly messy PHP code and possibly adding in my C parser (if I
> ever get around to getting the ugly list syntax working).

If someone doesn't understand this yet:
	    NO C CODE SHOULD BE USED ON WIKIPEDIA EVER

It's suicidally insecure.


subject: [Wikitech-l] Re: Phase IV

body:
On Saturday 26 July 2003 23:50, Lightning wrote:

> I'm sorry, but as a _personal_ preference I think  interpreted
> whitespace is a terrible idea. Sorry if you dont agree.

Thinking that something is not good and trying it are two different pairs of
shoes. I thought that the Wikipedia idea can not work until I tried it...

> As or a code
> switch, I have no doubts that python is a great language, it has many
> fans.. but I see no reason to switch.. sure its easy to learn, but the
> current developers already know php. Not too mention php is really easy
> to learn and understand. I mean really, you try and tell me php is hard
> or obfuscated or difficult to read or undocumented. [...]

Neither did I say anything bad about php nor did I suggest to change the code
base to python. If you read my posting you'll see that I just said that I
don't agree with your critisism concerning python and that I said that python
is a cool programming language, that's all :-)

best regards,
  Marco

--
Marco Krohn
Theoretical Physics
University of Hannover


subject: [Wikitech-l] Re: Phase IV

body:
On Sat, Jul 26, 2003 at 05:13:28PM -0500, Nick Reinking wrote:
> On Sun, Jul 27, 2003 at 12:07:39AM +0200, Tomasz Wegrzanowski wrote:
> > On Sat, Jul 26, 2003 at 05:00:50PM -0500, Nick Reinking wrote:
> > > I think we would be better off cleaning up the
> > > admittedly messy PHP code and possibly adding in my C parser (if I
> > > ever get around to getting the ugly list syntax working).
> >
> > If someone doesn't understand this yet:
> > 	    NO C CODE SHOULD BE USED ON WIKIPEDIA EVER
> >
> > It's suicidally insecure.
>
> That's rediculous - just because C can be insecure doesn't mean it has
> to be.  We rely on PHP every day, which, surprise surprise, is written
> in C.  What do you think PHP is?  It's just a C program that interprets
> specially formatted HTML and runs a bunch of internal C functions.  As
> such, it is just as suspect to buffer overflows and what-not as any
> custom written C code that we might write.

Many people thought they are wise enough not to do any such mistake,
and they have been all proven wrong. Even such security paranoids
as OpenBSD people.

We are using C code all the time, but this code have been checked
by thousands of people, and despite this, stack and heap overflows
are being found in it all the time.

Risk is too high, and benefit is too small.

Anyway, lex and yacc are available for almost all languages,
that's no excuse for using C.


body:
james-

>> Look, James, I know that it's fun slandering me, but I would appreciate it
>> if you could stop for a second and actually read what I wrote. Thanks.

> Yes I did read what you wrote and no I am not slandering you. I have a great
> deal of respect for you but I think unilaterally rewriting a policy page
> without a debate is grossly wrong. I am not always on wiki, neither are most
> people. How are we to know if you have made a major change

I explicitly stated that authors should not make major changes to policy
pages without prior discussion. Heck, my change was a minor clarification
and in line with my previous discussion with 172, and I still announced it
on the mailing list! I described what has long been common practice. Now
if you want me to come to your house with a megaphone the next time I
intend to make a change to a policy page, well, I can do that, but you
have to cover the traveling costs.

Regards,

Erik


subject: [Wikitech-l] Re: Language wars

body:
Hunter-
> Not as fast ?  Again, no one acknowledges psyco.

If you want to rewrite the Wikipedia engine in Python, you are welcome to
do so. Tim is doing a rewrite in Perl. Maybe Tomasz will do a rewrite in
Ocaml. And hey, perhaps good old Jonathan Walther will come back here 3
years from now and tell us that his mod_wiki implementation in C is
finished. The more implementations we can choose from eventually the
better.

I am happy to see rewrite projects and might even participate in the ones
I find interesting. I am also happy to see contributions to our existing
codebase. Frankly, I have not seen much from you in either department yet.

Discussing the merits or disadvantages of various programming languages
here is completely pointless and off-topic. If you want to do that, please
take it off the list.

Regards,

Erik


body:
Ulrich Fuchs wrote:

>I agree that stable and accepted articles are important to have (for quoting
>and so on). I do not agree that defining those versions must be done by
>"people with baccalaureate degrees in the subject area". It would be far more
>important to get these experts *Writing* instead of editing.
>
>I am not in favour of a system where a lot of people drive thousands of
>articles to a certain (excellent) state, and a few experts get the merits by
>selecting the articels, making some smaller copyedits and then calling that
>the "real" encyclopaedia, implicitly stating that the Wikipedia is not
>serious at all.
>
>
I agree that such a system would be a bad idea, but I think it's
possible to work on a "stable distribution" of the Wikipedia (so to
speak) without that.  It could be done within the current Wikipedia
system, but we'd need either a lot of organization or some additional
software help.  Basically "this article in its current form is quite
good, and has no major errors" needs to be identified, and included in
the "stable" set.  Then updated versions can periodically be added to
the stable set.  The difference from the normal Wikipedia will be that
the goal is for every article in the stable set to be "good" at any
particular time, while with the normal Wikipedia any article at any time
could be right in the middle of a half-done revision or move, or could
just have been vandalized, and so on.  So if, say, you wanted to publish
a paper version of the Wikipedia, even if you had infinite amounts of
paper, you could never take a snapshot of the active version, because at
any given time a lot of stuff is in flux and not ready to be published.
So basically the Sifter-type idea would take stable snapshots of
articles now and then.

-Mark


body:
steve vertigo
>...
>Then comes again the old idea of making a
>New Nupedia again -- control everything! --
>show us your credentials!  Lets sell textbooks!
>What a load!-*

No - Wikipedia stays the same. The only difference is that another project
takes our articles, improves them and then puts the results back into
Wikipedia. And nobody has proposed selling textbooks.

If you don't want external projects doing this to the text you submit then you
are in the wrong project.

--mav


body:
Kpjas wrote:
>The Sifter idea was a compromise but a
>better proposal than using dead Nupedia.

Nupedia, right now, is dead. The /only/ thing that we would use is the name
under a new framework.

-- mav


from_name: Toby Bartels

subject: [Textbook-l] No new wikis

body:
Erik Moeller wrote:

>Toby Bartels wrote:

>>Erik Moeller wrote:

>>>Anyone is of course free to start their own project on their own servers,
>>>but a Wikimedia brand project should have support from a substantial
>>>number of, er, Wikimedians. We're not a wiki hosting provider.

>>Since when does Wikimedia take votes to make these decisions?

>We never did. I proposed that we should start.

And we'll see how much support your proposal gets. ^_^

>>A substantial number of Wikimedians /does/ want to do Wikibooks.

>Certainly.

Yet you imply above that we can't know this without having a vote.
I agree with you that a project must have the support of a substantial number.
How much is substantial? you ask.  Enough to get it happening, I reply.
This is not determined by votes, it's determined by action.
There's no reason why a project must have the support of a majority.
For example, I've never been particularly fond of Wiktionary,
but that's all right -- I just don't use it myself.

>>I don't need any vote to prove this.

>A vote would help to determine if there are many Wikimedians who are
>against the project. I would have voted against the Wikibook project in
>its present "Textbook" form, for example. There are many projects where
>there will be dissent among Wikimedians on whether they should be operated
>by Wikimedia or not. Take POV projects like Disinfopedia, for example --
>I'm sure there are many Wikimedians who like the idea and would love it to
>run under the Wikimedia banner. But many others would be against this,
>either because they see NPOV violated, or because they see *their* POV
>violated.

NPOV is a special case.
A project that violated NPOV would draw Jimbo's ire,
and the Wikimedia Board of Directors would stop it
(assuming that Jimbo retains /any/ significant influence there).
But I'll assume that you can come up with an example
that doesn't fall into this special case.

>In that case, it would not be enough to simply say "Look, it's quite
>obvious that many people want this, so quit yer whining already." A
>formalized voting process after the project plan has been finalized helps
>to address such concerns, and makes sure that a large number of
>Wikimedians is exposed to every new idea -- if not in the planning phase,
>then in the voting phase -- and gets a fair chance to voice their dissent.

In the case of the Wikibooks project, I don't know what a vote would do
to draw people's attention more than what has already happened.
You are commenting! and your concerns about excluding cookbooks
are even being addressed.  (I'll even support you on a change of URL.)
The process has been perfectly out in the open.

>The alternative would be to let Jimbo decide in each individual case.

Another alternative is to allow any project with enough interest
that a developer will write the necessary code and people work on it.
Then modify that by allowing Jimbo (or rather, the Wikimedia Board)
to stop projects that violate NPOV (and a few other rules,
like educational purpose, that we can decide on by consensus).

Potentially, there's an issue of the finiteness of Wikimedia's resources.
Perhaps we get so many projects that we bog down the servers!
OT1H, Wikibooks isn't creating more users now, hence no more load.
But OTOH, potentially Wikibooks, Wiktionary, and Wikipedia together
could manage to /draw/ more users, hence more load, than only two would.
So, we may have to start making decisions about resource management.
But there's no need to institute procedures now
for problems that may never arise -- [[Wiki:YagNi]].
(Mind you, that doesn't mean that /you/ can't start planning for it!)

-- Toby


subject: [Textbook-l] RE: different open content licenses

body:
Karl Wick wrote:

>We are creating new content. If we want to use wikipedia
>content we can link to it, as I linked to the periodic table.

The periodic table isn't covered by copyright anyway.
Most of our [[en:List of ...]] articles are similarly free;
there is no copyright on information, only creative work.
(IANAL, and it'd be interesting to ask one just how far that goes.)

-- Toby


body:
Ulrich Fuchs
>I do not beleive that this is a very good idea.
>You can do this, of course, the GNU FDL allows
>it. However, I feel like Wikipedia should be cannibalized
>that way, sorry.

How would it be cannibalized? We are talking about creating a stable version
of the articles. Most people, for example, don't install and use software in
a production environment that is from CVS. Most people wait for a stable
release of the software. Wikipedia is in a constant state of change - it is
like CVS. Nupedia would be a stable distribution of that content that has
been checked by experts.

>I agree that stable and accepted articles are
>important to have (for quoting and so on). I do
>not agree that defining those versions must be
>done by "people with baccalaureate degrees in
>the subject area". It would be far more important
>to get these experts *Writing* instead of editing.

They already are. I have a  baccalaureate degree in biology but that doesn't
mean I'm staking my reputation on anything I write in the biology section as
'maveric149.' But if I am checking facts in a biology article submitted to
Nupedia I /will/ be staking my reputation on the factual accuracy of the
article. As an added bonus Wikipedia gets an article whose facts have been
checked by somebody who should know what they are talking about. There is no
such stamp of approval on Wikipedia articles now.

>I am not in favour of a system where a lot of
>people drive thousands of articles to a certain
>(excellent) state, and a few experts get the merits
>by selecting the articels, making some smaller
>copyedits and then calling that the "real"
>encyclopaedia, implicitly stating that the Wikipedia
>is not serious at all.

Having a "checked by" attrib is hardly giving all the credit to the Nupedian.
The complete article history will also be linked from the static, checked
version on Nupedia. And Wikipedia is the content development area - that is a
serious and very important thing. Without it there would be no content.

So people will have a choice between the stable version which has been checked
by verified people with credentials or the more up to date version which may
have glaring errors or omissions or outright false information inputed a
second before they view the page.

I'm the type of person who likes to use stable distributions.

-- Daniel Mayer (aka mav)


subject: [Textbook-l] different open content licenses

body:
Mav wrote:

>Toby Bartels wrote:

>>OTOH, the physics and chemistry texts might
>>well want to borrow, not just information, but
>>entire chunks of text with only minor changes --
>>especially given the modular nature of textbooks
>>that's been proposed here, where different
>>textbooks might share the exact same module.

>And how exactly is this going to work if the physics textbook is GNU FDLd and
>the chemistry book is CCSA? You cannot mix and match like that because
>modules are part of a distinct work. Each work has to be under the same
>license.

That's the whole point of my paragraph,
which was an example of the sort of detail that we must think through.
Because they might borrow from each other, they must switch over together.
(Or at least once one switches, then the other can't switch to anything else.)
OTOH, a physics book deliberately written in a nonstandard style
might not want to borrow from them, so wouldn't need to switch.

>>I suspect that RMS will accept removing the
>>Invariant Sections. But I can't imagine him
>>changing the GNU FDL to allow redistribution
>>under a Creative Commons license;

>If he only removes the invariant sections then the GNU FDL is completely
>copyleft and everything major we want it to be. Therefore the differences
>between the CCSA and the FDL will be minimal and the advantages of allowing
>CCSA along side of the FDL will also be minimal.

No, removing the IS (and Cover Texts, etc) only means that
the CC SA licences are no longer objectively better than the GNU FDL.
All of the incompatibility issues remain,
which is what makes a disjunctive licence better.
Compatibility, after all, is what is driving this disagreement.
(And not necessarily the compatibility issues that you think!
See the end of this post.)

>>since CC doesn't share the FSF's ethical
>>philosophy (they even offer the non-free
>>ND and NC license options!),

>Strawman alert: The CCSA is the only CC license that could possibly be
>compatible with the GNU FDL in both directions.

Strawman???  Let me explain this in more detail.

RMS cares about philosophy, about ethics.
He seems to me to regard the "Open Source" guys as sell-outs.
He's happy to work with them on projects, but there's a philosophical rift.
CC has allied itself with the catchphrase "open", not with "free".
Lawrence Lessig does not share RMS's ethical philosophy.
The fact that his group offer nonfree licences --
especially the ND option, which forbids derivative works --
is clear evidence of their ethical failure.
Naturally, /if/ an intercompatibility is developed,
then it will be with an SA licence (more likely CC BY-SA IMO).
But my point here is RMS's trust of the other group.

>>how can he be sure that CC licenses will remain free?

>Simple: "Copyrighted works under the GNU FDL 2.0 or later version created by
>the Free Software Foundation can be copied, modified and distributed in full
>and placed under the Creative Commons Share Alike license version 2.0 or
>later version deemed to be sufficiently free and copyleft per FSF ruling. See
>http://www.gnu.org/licenses/fdl/compatibility/ for updates on the status of
>the Creative Commons Share Alike license."

This will work until CC makes their licence refer (as it ought)
to yet other licences that RMS and GNU might not have read --
I'm thinking in particular of future versions of the CC licence.
As soon as CC SA 2.1 says "or any future version of CC SA",
then GNU FDL can't allow CC SA 2.1, only CC SA 2.0.
Which people won't use anymore, and so nothing is gained.

Not that I mean to criticise your idea entirely; we can refine it.
And we should present it to RMS when we try to win him over.
Unfortunately, I'm more convinced than ever that we never will,
after reading discussions on the Debian legal list as late as April.
He was strongly against even getting rid of Invariant Sections,
which the FSF uses to place the GNU Manifesto in its documentation.
If a future distributor that was hostile to free software
could remove that manifesto from the documentation,
then future readers wouldn't have the opportunity
to be indoctrinated^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hread about
why free software is so important -- so his argument goes.
If Debian can't convince him, then I doubt that we can.
Not that we shouldn't try! -- but we shouldn't count on it.

Anyway, the bottom line is that making the licences compatible
depends on action by LL and RMS that may or may not occur.
I don't want to rely on that when submitting material that I write;
I want it to be available to everybody (or as many as possible),
not just to GNU FDL users.

>>Who has trouble understanding it?

>Given the number of copyvios we get daily and the great deal of confusion
>people have over copyright issues I would say the answer is self-evident.

These confusions aren't about the GNU FDL;
they're about whether contributed material is PD or not.
Our copyvios are from people that think something proprietary is PD,
not from people that think that something proprietary is GNU FDL.
(Or they're from people that ignore copyrights entirely!)
We've had very few people borrowing our own work incorrectly --
and we don't even explain the GNU FDL to these people either;
we just tell them to link to us and the licence and they do it.

>>I still expect that most users don't care at all.

>And they will furthermore copy text Willy nilly between the various Wikimedia
>projects. This should be encouraged. However having incompatible licenses
>/within/ Wikimedia will hinder this free exchange.

They /shouldn't/ copy text willy nilly between physics and math texts.
Or even between two physics texts with strongly different styles.
This has been discussed before in a different guise:
Textbooks are different from the encyclopaedia,
because they have their own stylistic integrities to maintain.
(That's also why text copied directly from WP won't usually be wanted
in the first place.)

Already, the half-hearted beginnings at <textbook.wikipedia.org>
(and the one full-hearted beginning, Karl Wick's OChem text)
are developing their own separate identities with no cross-linking.
This is the future of Wikibooks -- very different from Wikipedia.
Modules are important to allow variations on a theme,
so each theme (if you will) must keep the same licence.
But the math text and the cookbook have incompatible themes.

>BTW, we have created over 200,000 encyclopedia articles ourselves and only
>occasionally use public domain or GFDL text created elsewhere. There is no
>reason to believe that the textbook project will be any different.

I agree completely!!!

Your main argument has been that Wikibooks must be GNU FDL
because Wikipedia already is.  But Wikibooks, like Wikipedia did,
can start on its own, generally not borrowing from WP or other sources.
You already allowed that a disjunctive licence (like what Jimmy described)
might have been better for Wikipedia when it just started out.
Well, Wikibooks /is/ just starting out.

I suppose that you said this to argue that Wikibooks
also isn't likely to want much CC material either.  I agree!
I mentioned that it might only as a counterpart to your argument
that Wikibooks might want some GNU material.
If you agree that it probably won't want anything,
then I'm perfectly happy to stipulate that.

The main reason not to use the GNU FDL alone
is -- and has been since Karl first brought it up --
so that /other/ people will be able to use our work.
We can't anticipate now whether GNU or CC is the future,
so we should keep our work open to as much as possible.
Using the GNU FDL only is a limit on future users' freedoms.

The basic premise of free copyleft content
is to allow the work to be used by anybody
that will themselves keep the work free and copyleft.
These people might be:
1: People deriving works from our stuff alone;
2: People combining our work with GNU stuff;
3: People combining our work with CC stuff;
4: People combining our work with both GNU stuff and CC stuff.
(There are other possibilities as well, of course.)
Now, there's nothing that our licence can do for (4);
their only hope is that RMS and LL will work together.
And 1 is possible no matter which licence we choose.
You would help 2 as well but leave 3 out to dry.
I would help both.  My way is freer.

>Above all else; keep it simple.

If keeping it simple were above all else,
then we would just put everything in the public domain.
That's a lot simpler than these complicated licences.
Even making all contributions the property of Wikimedia
would be simpler than any copyleft licence.
Clearly, keeping it simple is /not/ above all else.

Freedom is more important than keeping it simple.
If we didn't believe that, then we'd go work for EB.
Freedom is the core reason for the disjunctive licence.

-- Toby


body:
Ulrich Fuchs wrote:
>We are not talking about a "checked by" for a
>stable version within Wikipedia, we are talking
>about seperate articles (e.g. in the domain
>www.nupedia.org) that were taken out of the
>Wikipedia, copyedited and then placed under
>a new label.

Just like anybody else who uses our content:
http://www.wikipedia.org/wiki/Wikipedia:Sites_that_use_Wikipedia_for_content

Except all changes are made on Wikipedia - Wikipedia benefits and gets full
credit.

>Do I understand it right, that you declare this
>attempt to be failed right now?

I you are talking about the way things are done on Wikipedia right now then I
would have to certainly disagree - Wikipedia has been an astounding success.

But it still is is in an unstable state - the content will even be more useful
if checked and certified. This can be done in different ways - it is healthy
to discuss those.

-- mav


body:
Ulrich Fuchs wrote:
>With an "official" cannibalization of Wikipedia arcticles for
>Nupedia articles there would be no content - people do not
>like it to write without being acknowledged.

What are you talking about? By law the Nupedia article would have to give full
credit to Wikipedia and have a link back. Our content is already being used
in many, many other places as well - this is not cannibalism. That is the
whole point of the GNU FDL - re-usability of the text.

>They get this acknowledment right now by supporting the
>free encyclopedia idea *directly*.

And the people who commit free software patches to CVS are not *directly*
supporting free software? I don't get your logic.

>I bet most of the contributors will have a very bad
>feeling about not doing the "final" thing any more,
>but being just the idiots who do all the work for some
>guys and girls at Nupedia who will be the "gods" which
>- at the end of the day - decide rather authorically what
>is good content and what is nonsens.

I'm not advocating that Wikipedia should not also have its own process for
making what it calls a stable version - I'm just saying that the result of
any such a process can be further certified by an additional process. If a
particular result of that process isn't liked by Wikipedians then it doesn't
have to be used in Wikipedia (simply revert the page).

The reason why the Nupedia brand makes sense is because any "stable" version
of an article would necessarily be static - nothing wiki about static. There
is furthermore nothing "wiki" about a printed version.

-- Daniel Mayer (aka mav)


body:
Erik wrote:
>Well, here's the thing. Our Main Page is protected.
>Our Main Page links to the Brilliant Prose page,
> which would also be protected. The Brilliant Prose
>page would only link to verified revisions of articles.
>A user can choose this path
>
>Main Page->Brilliant prose->Article

As I said - I think that is a great idea. But I also see within that idea a
way to kick-start Nupedia and feed it already high-quality content. Then
Nupedians (most of whom will also be Wikipedians) have relatively little to
do except certify content based on their own credentials.

GNU/Linux distros do this all the time - polishing of the free software code
so that it fit for the masses. This does not prevent the KDE people from
first having their own stabilization process. However the result of the two
processes is a superior product in the end.

>And they will never see an "unstable" article -- these
>pages would always be in a reasonable state. It is the
>same thing as a separate site, but happens entirely
>within Wikipedia. We might have to streamline the whole
process -- turn BP into a directory of pages, make this directory
> part of  the start page, and warn readers that pages linked
>from pages within that directory may not necessarily be in as
>good quality. This would not preclude us from also using a
>category system that contains *all* Wikipedia pages, not just
>filtered ones. On the other hand, we would retain wikiness and
>encourage people to also browse and participate in our unstable
>sections. I think that's a good thing.

Again - all great ideas.

-- Daniel Mayer (aka mav)


subject: [Wikitech-l] Anti troll mechanism

body:
On Sat, Jul 26, 2003 at 06:54:09PM -0700, Hunter Peress wrote:
> What do you think?

Stupid.

It says in big letters on main page of Polish Wikipedia that
registering is not needed. That's quite an important feature.


body:
On Sat, Jul 26, 2003 at 07:22:22PM -0700, Hunter Peress wrote:
> hmm, so I was thinking about the performance hit from the extra difflib call. There are two
> choices:
>
> put ALL non-registered users under a separate process that is niced to be of lower priority
> (higher nice) than the registered version.
>
> OR simply use an if statement to only do the difflib/anti-troll call for non-registered.
>
> If you agree with me that trolling is an issue
[cut]

We don't agree with you. Worst trolls were registered anyway.


subject: [Wikitech-l] RE:Anti troll mechanism

body:
On Sat, Jul 26, 2003 at 07:33:18PM -0700, Hunter Peress wrote:
> RE: the first response, I am disinclined to respond, however since I prefer to deal with this
> "argument" (which it is not):
>
>
> My solution does NOT disable non-registered users, it merely limits them to be able to do less
> damage.

You are limiting their ability to do positive things much more
than their ability to inflict damage.

There has never been any problem with anons.


body:
Erik wrote:
>I know, but what's the point?
>Why not just kill off Nupedia and
>advertise Wikipedia as a single project?

The point is that a main criticism I always here about Wikipedia is that it is
largely not written by people trained in the areas they are writting. But
that is the whole point of Nupedia. Therefore we take the best of Wikipedia
and put it through the expert approval process and the result is something
that can't be criticized for that reason. Also having a different name makes
it clear that those articles are different than regular Wikipedia ones (a
"stable" Wikipedia article is an oxymoron anyway).

>If Wikipedia is not simple enough, not easy
>enough to use for the kind of experts who
>can help in certification, then it seems we
>should make it simple enough -- perhaps by
>having a special skin for the purpose.
>See, my main concern is about having
>separate communities.

We already have the experts - let's use them in Nupedia, revive the Nupedia
brand as a stable, experted-approved distribution of Wikipedia and that will
attract even more experts. All editing will still be on Wikipedia so every
Nupedian is also a Wikipedian. I see this as setting-up great synergies
between the two projects.

>I feel that getting the experts hooked
>on Wikipedia might be way cooler.

See above.

-- Daniel Mayer (aka mav)


body:
Toby wrote:
>The periodic table isn't covered by copyright anyway.
>Most of our [[en:List of ...]] articles are similarly free;
>there is no copyright on information, only creative work.
>(IANAL, and it'd be interesting to ask one just how far that goes.)

The table itself, no. But the particular table in Wikipedia has different
colors for the series, a particular selection of which series to have, and
different colors for the different states of each element - all that is
creative work and is under copyright.

And a chemistry textbook without its own periodic table is very strange - just
copy the darn thing Karl. :)

--mav


body:
Toby wrote:
>That's the whole point of my paragraph,
>which was an example of the sort of detail
>that we must think through. Because they
>might borrow from each other, they must
>switch over together.

That would require the permission of every copyright holder of the text. For
older textbooks or ones that incorporate a good deal of Wikipedia text this
will be impossible.

>I don't want to rely on that when submitting material
>that I write; I want it to be available to everybody (or
>as many as possible), not just to GNU FDL users.

Then on your user page state that everything you write that is not a
derivative work is under the CCSA or the public domain for that matter.

Each book will have to be under the GNU FDL, CCSA or a dual license. So
downstream users will still be limited; a downstream user wanting to
incorporate part of a CCSA Wikibook into their GNU FDL book will be blocked.
If however we continue to promote the use of the GNU FDL then that will
become the default free content license for everybody to use. We have already
uncovered a great many GFDLd textbooks so far.

>Not that I mean to criticise your idea entirely;
>we can refine it. And we should present it to
>RMS when we try to win him over. Unfortunately,
>I'm more convinced than ever that we never will,

I'll concede the point that this will be an uphill battle - but it will be a
battle worth fighting.

>That's also why text copied directly from WP won't
>usually be wanted in the first place.

I very seriously doubt that. I very often open up one of my many textbooks to
use as sources for a Wikipedia article. For example I opened by freshman
biology textbook to write [[centipede]]. I skipped to the right chapter and
found a description of the group as part of one section - I simply rewrote
it. In the reverse process all I would have to do is copy the Wikipedia
article and place it in that point of the textbook. I can go on and on with
many other examples where I have taken info from textbooks in similar chunks.

172 is also famous for doing this already /within/ Wikipedia. He likes to copy
text from several related articles and he intregrates into one overview
article that flows from point to point - just like a textbook. Check out the
[[History of the United States]] article to see what I mean (this style is
annoying in Wikipedia but would be most welcome in Wikibooks).

So a great many textbooks can at least be partially constructed by organizing
Wikipedia text.

>The main reason not to use the GNU FDL alone
>is -- and has been since Karl first brought it up --
>so that /other/ people will be able to use our work.
>We can't anticipate now whether GNU or CC is the future,
>so we should keep our work open to as much as possible.
>Using the GNU FDL only is a limit on future users' freedoms.

Again - each book has to choose one license or another (or dual). Each of the
singular options limits downstream usage to a single license path and the
dual option severely limits what can be used by the book itself.

We have already created an Empire with GNU FDL text - let's continue building
that Empire. We are big enough already that we can justify what we do simply
because we do it. We are borg.

>If keeping it simple were above all else,
>then we would just put everything in the
>public domain.

But then the text could be incorporated into proprietary works and we would
not be able to benefit from any improvements they make.

-- Daniel Mayer (aka mav)


body:
>Erik wrote:
I can do that, but you
>have to cover the traveling costs.

What??? Meet a wikipedian in the flesh?? Well at least it would be in euros
(opps. Slap. Must do what the European Commission tells me. The plural is
euro, not euros! Slap. Bold boy!) and not in dollars or pounds! *wikilove*

JT

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail


subject: [Textbook-l] No new wikis

body:
Erik Moeller wrote:

>look, I can agree on this: Only hold a vote if there is an actual
>substantial number of dissenters, and if there isn't, just move on with
>the project.

Then we don't need a vote in this case then, do we?

>New project plans would have to be announced in the proper
>places so that every dissenter gets an opportunity to object.

We need an announcements list for this sort of thing.
Or a Wikimedia list that discusses only Foundation-wide policy,
not focussed on the encyclopaedia.

>Silently
>ignoring dissenters, starting projects without giving people a proper
>opportunity to voice their objections or letting them bog down the whole
>process even though they are just a small minority is all not desirable.

Yes, this is true.  I'm not sure why you mention it.
Certainly there was never any risk of this happening in this case.
The idea of putting the vote at the /end/ of the policy-making process
is what really throws me -- dissent should be voiced by then.

>Consensus can not always be reached, and in these cases, we use voting.

Maybe, but that's not even really relevant.
So what if there's no consensus that we need a textbook project?
Or so what if it doesn't even get a majority?
Objection should only be for broad principles, like NPOV,
which should be decided by the Wikimedia Foundation in general.
(Quite possibly, the Board may decide them despite your and my opinion!)

-- Toby


from_name: Krzysztof P. Jasiutowicz

body:
On 26-07-2003, Daniel Mayer wrote thusly :
> We can use Erik's idea for adding neat features to the Brilliant prose page as
> a start. Then that page can act as a queue for articles that Nupedia can
> take-up and then put through a simplified Nupedia polishing process by area
> experts. The Sifter software can be used to make this easy but it is not
> really needed.
>
> But a stable distribution vetted by area experts (at the very least by people
> with baccalaureate degrees in the subject area) /is/ a very important thing
> for us to have.
>
> With such a system set-up we can start to work toward 1.0 status.

I don't like this idea.

Quality assurance should be done by Wikipedians within Wikipedia.
It is doable and I am sure that the community can handle this issue
brilliantly.
The Sifter idea was a compromise but a better proposal than using dead
Nupedia.

Regards,
Kpjas.


subject: [WikiEN-l] Re: Wikipedia: Warehouse or Pyramid?

body:
Timwi wrote:
>Everything should be included ;-)

Only when information on a subject can be independently confirmed by third
parties. Then the writer has to make sure the information is organized
correctly; is there enough independently verifiable information on the topic
to have a whole article on the subject? If not then the info should be
incorporated into a related article that does.

We cannot include everything.

-- Daniel Mayer (aka mav)


from_name: Ulrich Fuchs

body:
Am Sonntag, 27. Juli 2003 06:51 schrieb Daniel Mayer:
> We can use Erik's idea for adding neat features to the Brilliant prose page
> as a start. Then that page can act as a queue for articles that Nupedia can
> take-up and then put through a simplified Nupedia polishing process by area
> experts. The Sifter software can be used to make this easy but it is not
> really needed.
>
> But a stable distribution vetted by area experts (at the very least by
> people with baccalaureate degrees in the subject area) /is/ a very
> important thing for us to have.
>

I do not beleive that this is a very good idea. You can do this, of course,
the GNU FDL allows it. However, I feel like Wikipedia should be cannibalized
that way, sorry.

I agree that stable and accepted articles are important to have (for quoting
and so on). I do not agree that defining those versions must be done by
"people with baccalaureate degrees in the subject area". It would be far more
important to get these experts *Writing* instead of editing.

I am not in favour of a system where a lot of people drive thousands of
articles to a certain (excellent) state, and a few experts get the merits by
selecting the articels, making some smaller copyedits and then calling that
the "real" encyclopaedia, implicitly stating that the Wikipedia is not
serious at all.

Uli


from_name: Sheng Jiong

subject: [Wikitech-l] LanguageZh.php completed

body:
It seems that my previous email has been ignored. :(

The new LanguageZh.php has been completed, and it is now fully
localised. Please kindly install it on the server. It can be found at
http://meta.wikipedia.org/wiki/LanguageZh.php

Another question I want to ask is if it is possible to have two locales
for Chinese Wikipedia, so that users can choose their own character
settings(traditional or simplified). Currently the interface is
translated to simplified Chinese. I think it would be very ugly to
combine the two together, and it is not easy to translate also.

Regards,

[[User:Formulax]]


from_name: Fred Bauder

subject: [Wikitech-l] RE:Anti troll mechanism

body:
on 7/27/03 8:29 AM, Lightning at lightning at chaos-productions.com wrote:

> Hunter Peress wrote:
>
>> In irc just now, taw and I discussed the above. He even asks "maybe we should
>> restrict editing of
>> even registered users".
>>
>>
>
> wooooahhhhh there woody. you know i didnt even liket he idea of the n
> char max edit for anons. Primarily because its just not so "free".  I
> think editors should have the right to edit as anons and i dont see a
> problem with that, thats the way wikis are and thats why we have
> previous versions saved. Pages will be vadalized, and we will fix them
> thats what the wiki is all about. I don't see editing restrictions
> fitting well into the community. I don't like them myself. It just
> completely violates the spirit of the wiki.
>
>
> Lightning

Yet it might prevent the wholesale reverts some folks participate in. If
they had to actually go into the article and edit they might be less ham
handed. I remember one case where both new material and a link correction
had been put in and article and the reverter never caught on that by
reverting he was also reverting a link correction over and over.

Fred Bauder

http://www.internet-encyclopedia.org


subject: [Wikitech-l] RE:Anti troll mechanism

body:
Hunter Peress wrote:

>In irc just now, taw and I discussed the above. He even asks "maybe we should restrict editing of
>even registered users".
>
>

wooooahhhhh there woody. you know i didnt even liket he idea of the n
char max edit for anons. Primarily because its just not so "free".  I
think editors should have the right to edit as anons and i dont see a
problem with that, thats the way wikis are and thats why we have
previous versions saved. Pages will be vadalized, and we will fix them
thats what the wiki is all about. I don't see editing restrictions
fitting well into the community. I don't like them myself. It just
completely violates the spirit of the wiki.

Lightning