On Tue, Aug 29, 2006 at 09:12:47PM -0700, George Herbert wrote:
You have a pot of screws and a hammer. Purchase a screwdriver.
I have a real document management system. Several, in fact.
[..Snip..]
Some of these environments will benefit from Wikis; many of them will require additional access control. It's unreasonable to expect that MediaWiki would never find itself installed in such a situation.
You're missing his point, though, George:
MediaWiki happily doesn't claim to provide those features, so if you spec it into those environments, *you've* screwed up. You're welcome to patch it to do anything you like, or pay someone else to, though.
If MediaWiki doesn't fill your needs, and you can't patch it to do so, you're welcome to use something else; Tim and brion won't be offended.
I think George's point was that there are many intranet environments (not just his) where easier access-control would be a useful addition to the software.
One need only look at bugzilla, and the access-control request bugs, to verify this as being correct.
That said, this behaviour (e.g. restricting read access) is not desired on an open collaborative site like the Wikipedia.
Basically there's a tension between the real-world ways in which people want to use MediaWiki the software "product", and the primary raison d'etre of MediaWiki as an open-to-everyone collaborative platform.
The more interesting question is: If people can find a way of adding this type of functionality to the default install (but disabling it by default) so that it doesn't impact you, should it be added?
On the plus side, it'd most likely lead to more deployments of the software, and hence more people familiar with the syntax, and more people familiar with wikis in general, and what people get used to at work they tend to use at home too (with potential positive impact). On the negative side, maybe it's seen as complicating the software, and endorsing a feature that's opposed to the fundamental aim of open knowledge.
All the best, Nick.