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?
* 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
- Changes will still happen on wikipedia. Also, I propose that noone is
restricted to certain topics; anyone can approve any article ;-) as long
as s/he can be trusted to use common sense in what s/he is able to judge
I agree with that. We learned from Nupedia that excessive a priori
formalization is a killer. Better to start from a very open point of
view, and then upon review, if our end product is starting to be bad
in some way, make adjustments based on what we've learned.
* simple, easy to use and completely open
- same as sifter, except that I would not let anons approve articles...
I would tend to agree with this. The main things to remember here is
that 'anon' is a misnomer (though one that we are stuck with because
we all say it) because not-logged-in is *less* anonymous than
logged-in. :-)
Having people logged-in allows for the development of reputation,
which is a great incentive for doing a good job.
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.
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.
* 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.
* user access is much easier to manage on a separate
project
Maybe, maybe not. Depends on implementation.
* 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'.
* 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.
* 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.
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.
--Jimbo