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