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.