Jimmy Wales wrote:
Magnus Manske wrote:
The arguments Erik gave for an
"in-wikipedia" solution were:
* no separate brand to the Wikipedia brand, no separate community
- I don't see that happening.
But, do you agree that it is desirable, to whatever extent we can
achieve it?
I'm not sure I understand that sentence. I don't believe there will be
aseparate "sifter" and "wikipedia" groups. I'd think they'll
overlap in
huge parts. Those who don't care about the stable version thingy at all
won't participate either way. Maybe a separate project would even
attract some academics who'd shy away from the "pure" wikipedia ;-)
Before other people like Erik explained this to me
again, I was still
thinking of having an appointed class like sysops, with appointment
being open and easy, to have quality control. But on further
reflection, it seems like quality control can be had in other ways
that don't force us to have a separate class of users.
Of course, if we start in on a process and the end result starts to
look problematic, we'll have to bite the bullet and make a change.
I used to be in favor of the "appointed class" model, but now I think we
should try "logged-in only" open for everyone. It worked before :-)
Now to my
"pro-sifter" list:
* fully capsuled, like a language wikipedia, with its own images etc.
Avoids problems of an "internal" solution, like:
- Approve some version, which gets moved to "old" eventually
- That "approved" article uses "xyz.jpg"
- Someone replaced "xyz.jpg" with a goatse.cz image
That's obviously a benefit, but doesn't point to a need for a separate
project, per se, but a need for making sure that the 'version' being
approved is the *entire* article, including text and images. This
does complicate things a little bit.
Let's see: We'd need an additional image management routine, a new table
in the database to keep track of what-image-was-when-where, probably
interface to deltete wrongly approved images (and another one to
undelete them, of course;-)
Then we'll need another implementation of Recent Changes, or some kind
of filter; a search mode for just-the-stable-versions; URLs to the
stable version; making sure that stable versions have not been deleted;
and some new user options to spice the soup up a little ;-)
I probably forgot some of the necessary changes, but you get the picture...
OTOH: Sifter project needs a few more lines of code for importing
images, then it's basically ready to go.
* going to
sifter.wikipedia.org (or whatever) means you're sure to get
only approved stuff, while going to
www.wikipedia.org is for those who
write, and/or need complete and up-to-the-minute coverage
Well, the exact url where people may browse 1.0 could be anything.
In my private thinking about it, I've been thinking of it as
www.wikipedia.org/1.0/wiki/
But the exact url where someone could view what has been approved so
far is not really important.
I wasn't talking about the URL, I meant there's an actual place to go to
for "reliable" information. Wikipedia-with-an-addon will be quite
confusing for some people, I'd guess; "You can edit this page" is scary
enough already :-)
* user access
is much easier to manage on a separate project
Maybe, maybe not. Depends on implementation.
Try to answer "Who's been working on the 1.0 version, and how much?" in
both schemes, and you'll see what I mean.
* sifter Recent
Changes shows you only what was imported, while
wikipedia Recent Changes shows you what was written. Imagine the
clutter, otherwise.
I think having a separate RC (or Recent Approvals) is vitally
important, but again I'm not sure it's really relevant for a
question of 'separate project' or 'added features to existing
project'.
Maybe not relevant, but a pain to hack (see above), and it has potential
for confusing the users.
* sifter yould
reside on another server (we'll have another one soon,
right?), with its own database etc., thus reducing/spreading load on
wikipedia itself
Maybe! But this could complicate some things.
No it wouldn't, as long as both servers (the sifter and the 'pedia one)
are in your server farm. I'd only have to change an IP in the sifter
LocalSettings.php .
* software is
basically written, just needs a few more tweaks
Well, that's a huge plus of course, because rough consensus and
running code makes the world go around.
Ah, the good ol' times :-)
After reading all this and writing all this, I'm
not sure that
"internal" versus "separate project" is really a useful concept. I
guess I'm for an 'internal' project, but with most of the features
that you've identified.
Well, basically the choice is to
* implement many things twice within the same source (or include so many
IF statements that it will blur your eyes;-) or
* use the code we have
Magnus