> http://slashdot.org/articles/01/10/10/1454231.shtml
I checked out the site after reading this, and they are NOT
releasing the courseware to the public domain, or even some
open-content-like license; they explicitly retain full
copyrights on all the material, so it's useless to us.
Hi all,
before you waste lots of energy on discussion, be aware that the upcoming
wikipedia software, which is currently in beta phase, supports variables in
the text. For example, the date on the homepage is automatically adjusted
when you view it, with things like "{{{CURRENTYEAR}}}" being replaced with
2001 (this year).
That system could be expanded with things like
- {{{CATEGORY:Biology}}} in an article that could be seen as belonging to
biology
- {{{GERMAN:Haus}}} in the "house" article
These "variables" could be replaced for display with, say, a little German
flag linked to the German version of the "house" article, named "Haus".
These things don't have to be displayed inside the article, either; they can
go to the header, for example, so you'd have some little flags next to the
page title, or a category listing at the bottom.
That can be used for the category listing on recent changes (say, all
non-categorized articles, and biology only). Furthermore, all international
wikipedias could be checked once a day (or once a week), crosslinking
languages. If the English article links to the German one, the German one
will automatically link back to the English version. Also, if the German
article links to the Swedish, but the English does not, both English and
Swedish will be automatically updated.
This can be done without much trouble. We should wait for the software to be
tested and implemented with the "current" features only, though. Once the
new software is running wikipedia stable, all the other features can be
added.
Magnus
I temporarily disabled the cron during our traffic crisis. I will
re-instate it now. Also, I'll run the job by hand now, which will
take a couple of hours to update the engine.
lsanger(a)nupedia.com wrote:
> How frequently is the Wikipedia search engine updated now? Someone else
> expressed some concern about this recently, I think...they seemed to think
> it was updated less often than once per day.
>
> ---------- Forwarded message ----------
> Date: Fri, 21 Sep 2001 22:54:50 -0500
> From: Axel Boldt <Axel.Boldt(a)metrostate.edu>
> Reply-To: wikipedia-l(a)nupedia.com
> To: wikipedia-l(a)nupedia.com
> Subject: [Wikipedia-l] Search database not updated?
>
> >From discussion at http://www.wikipedia.com/wiki/Wikipedia_commentary/Search_Engine
> it appears that the search database has not been updated in a while. Could someone
> with access to the server please check if there's a working cron script in place to index
> the site daily?
>
> Axel
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
--
*************************************************
* http://www.wikipedia.com/ *
* You can edit this page right now! *
*************************************************
Yes, I agree! It will be fine to use the German wiki. It is large
enough to have lots of links to test, but small enough to be quick and
easy.
Magnus Manske wrote:
> Larry, that's a misunderstanding: We only want to copy the German data to my
> test wiki!
>
> Don't panic,
> Magnus
>
> > -----Original Message-----
> > From: lsanger(a)nupedia.com [mailto:lsanger@nupedia.com]
> > Sent: Tuesday, October 09, 2001 10:13 PM
> > To: Michael Dill
> > Cc: Magnus Manske; jwales(a)bomis.com; lsanger(a)nupedia.com
> > Subject: RE: PHP wikipedia
> >
> >
> > What we need is a test wiki. I don't much like the idea of using the
> > German wiki as a test wiki--they've done a huge amount of work already,
> > and we don't want to mess it up. Maybe we can make a copy of it and put
> > it at http://test.wikipedia.com/ .
> >
> > Larry
> >
> > On Tue, 9 Oct 2001, Michael Dill wrote:
> >
> > > Magnus,
> > >
> > > Go ahead and try the German version for the first
> > > tests. We can probably get Clifford Adams or someone
> > > to help sort out the current perl/CGI data formats. I
> > > beleve that Jimbo might have some information there...
> > >
> > > I don't know enough to help with the data conversion,
> > > but if we cant get any support from Clifford or
> > > someone at BOMIS, I will see if I can find a
> > > programmer or two to look at the tarball and help you
> > > with the structure.
> > >
> > > Jimbo,
> > >
> > > Would you help point us in the right direction here.
> > >
> > > Thanks to you all for great work!
> > >
> > > Mike Dill
> > > Phone 408-545-3675
> > >
> > > --- Magnus Manske <Magnus.Manske(a)epost.de> wrote:
> > > > --- Mike Dill <michael_dill(a)yahoo.com> wrote:
> > > > > Yes, call the current PHP script at
> > > > > wikipedia.sourceforge.net a Beta.
> > > >
> > > > OK!
> > > >
> > > > > I think we need to clear out everything in the
> > > > test
> > > > > database and see how to install a copy of the
> > > > current
> > > > > data. This will allow us to test/debug the script
> > > > for
> > > > > the data conversion. It will probably take a dozen
> > > > > trys at porting it before we get the conversion
> > > > script
> > > > > into a reasonable shape. Then we can ask all the
> > > > > wikipedians to look at all the pages to check for
> > > > the
> > > > > remaining script inconsistancies.
> > > >
> > > > We not necessarily need to clean the DB. And, should
> > > > we try another
> > > > wikipedia (e.g., the German one) first? It's much
> > > > smaller, so conversion
> > > > won't take that long for the first tries. If that
> > > > works, we can purge the DB
> > > > and install the "real thing". What do you think?
> > > >
> > > > > If we can get those bugs out, then asking Jimbo to
> > > > > make the transition would be a reasonable
> > > > proposition.
> > > > > Until we can port the current data with some
> > > > accuracy,
> > > > > I feel that we should not push it on the world.
> > > >
> > > > Agreed.
> > > >
> > > > > Lets try a data convertion from the tarball and
> > > > see
> > > > > what comes out. When it seems reasonable to us
> > > > then
> > > > > Larry and Jimbo can decide when it should be
> > > > > implemented.
> > > >
> > > > I looked at the German tarball, which seems to be
> > > > quite old, and I suppose
> > > > the "real" data is in the "page" sub-sub-...-subdir.
> > > > Do you know if that's
> > > > it? Are just the old versions stored as diffs, or
> > > > the current version as
> > > > well? I'm not that good at perl/CGI, so...
> > > >
> > > > Magnus
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Make a great connection at Yahoo! Personals.
> > > http://personals.yahoo.com
> > >
> >
>
--
*************************************************
* http://www.wikipedia.com/ *
* You can edit this page right now! *
*************************************************
This might be of some interest to you. This is a discussion, posted on
Nupedia-l, of some problems Nupedia is facing, together with a proposed
solution. One part of the solution is to add a link to Wikipedia article
pages saying (something like) "Submit this article to Nupedia." This
would take you to a page where further information would be solicited.
Successful submission of an article to Nupedia would be noted on the
Recent Changes page, as would final approval of any Wikipedia-originated
Nupedia article.
This *isn't* approved yet. It's just FYI. If you want to discuss it, it
would be better that you do so on Nupedia-l rather than Wikipedia-l. You
can subscribe to Nupedia-l here:
http://www.nupedia.com/mailman/listinfo/nupedia-l
--Larry
---------- Forwarded message ----------
Date: Mon, 8 Oct 2001 16:42:38 -0700 (PDT)
From: lsanger(a)nupedia.com
Reply-To: nupedia-l(a)nupedia.com
To: nupedia-l(a)nupedia.com
Subject: [Nupedia-l] Discussion and a proposal
Please, read through this whole thing before responding to any part of it.
I know it's long, but it sums up my thinking on the issues pretty well.
I. First problem: bottlenecks
I've been looking over all the many comments about the future of Nupedia
with great interest. One strand of the discussion, started by Andreas
Flack, is that Nupedia's system can be improved in various ways. One of
these ways was to create reminder e-mails. As Magnus said, we already
have many such e-mails (it took Toan and I some weeks to design them
properly, last January and February, I suppose it was). It's worth noting
that most people simply delete these reminder e-mails as soon as they
receive them.
Some of the other proposed changes are fairly cosmetic changes that would
very likely speed things up somewhat, but overall, not very much, I
suspect. I designed the process with the help of people from advisory-l
and nupedia-l, and Toan and I designed the system to implement the
process. I've also addressed problems at every step of the way. As I
said (in great detail, which I am not going to repeat) last spring, there
are bottlenecks at *every* step--dozens of potential bottlenecks, really.
Getting rid of a few of them will speed things up, yes, but not
significantly over the long haul. This is why I'm opposed to confining
our changes to the system to relatively cosmetic changes.
Another point discussed by Andreas and others and replied to by G. B. Lane
is that we should do what we can in order to find replacements for
delinquent reviewers and writers. As G. B. well said, this is a heck of a
lot harder than it sounds. Finding a qualified reviewer for a single
article might be easy for the most distinguished leaders of a field, but
it can be quite difficult for people who are not so high on the
academic/research totem pole, particularly when one must sell the
*project* at the same time. On this point, I think we should all defer to
the experience of G. B.; if you're not an editor, you don't understand the
problem as well as he does.
In sum, even our most dedicated, motivated members have complained of
endless bottlenecks in the process. I don't think that removing just one
or two of the bottlenecks is going to speed things up very much. The
problem is not cosmetic, to be solved by small tweaks to the system.
II. Second problem: lack of adequate credibility
Many people, both potential and former participants, have been turned off
by the fact that participation in the Nupedia project requires that people
do for free what they would do elsewhere for pay. Brad Eden's comments
are typical in this regard and totally understandable. The fact that
Nupedia is an open content project--that our articles are freely
distributable to anyone by anyone, and not just by the website
Nupedia.com--does not seem to matter to them. And why should we expect it
to matter to everyone? Just because *we're* convinced, that doesn't mean
they will be.
In response, we can sing the praises of open content, that it involves
contributing free information to the world and that this cause is worthy.
But, of course, there are many people who won't be convinced, and we
shouldn't wring our hands if they're not convinced; we should instead
regard their skepticism as a constraint on how we design our projects.
It's difficult enough to organize academics to do difficult academic work,
for which they'd ordinarily be paid, for free. It's even more difficult
to get them to do that sort of work if they feel, as Brad feels, that
their time is being wasted because the system forces them to work with
people that they feel are underqualified. I'm *sure* that's one of the
weaknesses of the current system that runs Nupedia--let alone Wikipedia.
(This is not to say, however, that I agree with Brad's dim assessment of
the state of Nupedia's music category at present.)
I don't think we should simply dismiss these concerns. We can pontificate
all we like about the virtues of open content, but that's not going to
change the *facts* about the people we would like to have involved.
I know that Jimbo and others are very concerned about making Nupedia more
open, like Wikipedia, and I *completely* sympathize; but I think we should
resign ourselves to the fact that the people whom we want to write for
Nupedia don't want to be part of a wide-open project. Instead, we should
make it as easy as possible for them to get to work in their *own*
element. I don't think we can *expect* many academics to work closely
with nonexperts--and that's what we ask academics to do if we ask them to
join a fully bazaar-like model, like Wikipedia. It seems to me it would
be best to have as efficient (but still high-quality) article-creation
model as possible for them to use, and if they become impressed Wikipedia
along the way, grand--we can welcome to Wikipedia with open arms. If we
make it easier for Wikipedians to submit good Wikipedia articles to
Nupedia, we will thereby expose Nupedian academics to the virtues of
Wikipedia.
III. The range of options open to us
Therefore, the way I see it, if we want to redesign Nupedia's editorial
process, we can choose revisions from a continuum with (at least) two
extremes. At one extreme, Bomis would try to make Nupedia an
ueber-elitist project, not unlike the Stanford Encyclopedia of Philosophy,
accepting submissions from and making reviewers of only the leading
researchers in any field. Another option in this direction, but less
extreme, would be for us to revert to a traditional peer review system,
completely redesigning (but radically simplifying) the system. At the
other end of the continuum--and this is actually *not* seriously proposed
by anyone--Nupedia would become another version of Wikipedia. Since
Wikipedia already exists, this is silly; but in this direction, Nupedia
could become *no more than* an approval process for Wikipedia. The latter
would cause a mass exodus of people like Brad--most of our most qualified,
distinguished participants on Nupedia.
I know some of you on Nupedia-l just don't care about having the
participation of academics and bona fide experts, but I think this is a
huge mistake. If our open content encyclopedia projects are going to
achieve their full potential, we *must* have the participation of these
people. It would be a mistake not to let our *most qualified* potential
participants stay in the project--on their own terms.
So, I think Brad has an excellent point. It's one that Michael Witbrock
emphasized to me very forcefully and persuasively when I visited him in
Boston: to succeed, the project has to have even *more* credibility among
its most qualified potential participants.
I think Andreas' suggestion, that we feel free to replace reviewers and
authors as necessary, is fine, but it's implausible that it would help
much to adopt this policy explicitly, for the reason G. B. Lane gave. As
I'd put it, for any given topic, on Nupedia, there is bound to be only a
very few people who are *both* interested in writing on that topic *and*
willing to revise someone else's work. Similarly with reviewers--it's
hard enough finding just *one* qualified reviewer for an article. In
other words, Nupedia's problem isn't that the project is closed to our
finding replacement authors and reviewers when necessary--it's that we
couldn't find enough *qualified* people even if it *were* generally open.
I think you'd find most Nupedia editors would agree with this.
IV. The proposal
It's with these sorts of thoughts in mind that I have come around to the
following proposal. This is something Jimbo suggested many months ago and
that Claus Wilke has articulated recently. In fact, it was probably
suggested by some wise person when we were designing a review system in
the first place.
I. Replace the current Nupedia system with a simple, traditional review
process, to be designed by the members of advisory-l. This would at a
minimum involve (1) writers either being assigned an article or simply
submitting articles to the editor, (2) the editor deciding whether to
assign the article to a reviewer or reviewers or reject it outright, (3) a
reviewer or reviewers either saying yea, nay, or conditional pass (maybe)
on articles (in one simple step), and (4) the article being passed by the
editor. After that, I would strongly recommend having a public feedback
system that would be something like the open review step we now have in
place. In other words, I think we should basically eliminate steps four
through six, open review and copyediting, and leave quality in the hands
of editors and expert reviewers--then *supplemented* by public feedback.
Copyediting would be the responsibility of authors, who would have to
solicit help, if needed, on pain of having articles simply rejected.
Copyediting comments would be solicited in the public feedback process.
(By the way, I would like to say at this juncture that Ruth Ifcher has
been probably the hardest-working member of Nupedia, and one of the most
widely appreciated, and this latter proposal should by no means be
construed as (absurdly) implying that her contributions as Nupedia's chief
copyeditor have been without value.)
If an editor were to approve very much substandard work, I would be
willing to field complaints and, if necessary, take whatever action was
appropriate.
II. Create a link on Wikipedia article pages labelled: "Submit this
article to Nupedia." This would link to a page that would solicit further
information from the submitter and then place the Wikipedia article in the
queue. Submission information would be reported on the Wikipedia [[Recent
Changes]] page, as would final approvals of articles in the Nupedia
system.
III. Delete the Chalkboard (move its contents to Wikipedia, with the
permission of authors--Magnus, mainly :-) ).
IV. Put off a decision whether to make a separate article approval process
for Wikipedia, on the hope that Nupedia might turn into a reasonably
efficient approval process for Wikipedia articles.
(This latter, after all, is how many of us have envisioned Wikipedia and
Nupedia working together.)
So, that's it.
I'd like to solicit comments here and then, sometime soon, unless fatal
flaws are discovered, take this proposal to advisory-l.
Larry
[Nupedia-l] -- a Nupedia.com mailing list
Help build the largest and finest encyclopedia in the world!
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/nupedia-l
Owning the Future:
Content Discontent
http://www.techreview.com/magazine/oct01/shulman.asp
I'm not sure if anything follows for the prospects of open content
projects, but it's very interesting, I think.
Larry
I was interviewed about Nupedia and Wikipedia (about equally) this morning
by New Scientist:
http://www.newscientist.com/
They describe themselves as "The World's No.1 Science & Technology News
Service," and I imagine most of you have heard of them.
The article is going to be about the open source movement's influence on
other kinds of projects. Actually, it wasn't perfectly clear to me what
the subject was, but the reporter seemed to imply that open content
projects would be highlighted.
--Larry
It looks to me like Wikipedia's recent traffic problems have been fixed,
and it's back to its formerly fast self (and links to new articles appear
as regular links!).
It's nice to note that, despite being a Saturday, and despite being
plagued by traffic-related problems, yesterday we *still* had as many
visitors and pageviews as the average pre-Sept. 11 weekday. :-)
Larry
Nope, it's still unusable. I've been trying to update my Wolf page for
twenty minutes now and it just won't lock.
Larry, Jimbo this might scare off newbies who stumble onto the site while
this is going one. Maybe disable editing while you are working on it?
--