On 11/22/05, Jej <jejc(a)free.fr> wrote:
It seems that many people need this feature. Since I
published this
patch
(
http://conseil-recherche-innovation.net/index.php/1974/04/11/41-restrict-pa…),
we have 25% of visits on this single article. Generaly people need
restriction feature to manage small wikis, private intranets. I guess
they choose mediawiki for the syntax, templates, and
reliabilty/community support, and not for the ability to manage projects
as big as wikipedia nor encyclopedies.
From a wikipedia point of view, I think nobody wants more restriction
features (protect is enough). We cannot polute the core of MW with
features not useful for WP, it's difficult to maintain patches for ages,
and it's not necessary to carry WP specific features in a forked
project. So my choice would be a fifth... E. To write some
specifications from needs, abstract the problem, and start a new project
:) Any ideas ?!...
I think it would be nice to have everything contributed into the core
wikipedia project itself, with a simple switch to disable things, so
that the wikimedia projects aren't, for once, themselves forced to
have a community feature.. as opposed to them forcing features on the
community. ;)
Or rather, the traditional "protect" feature would eventually just
mean "protect against writes from those not in the administrators
group"..
There *could* be core security and code tidyness benefits from
rewriting portions of the way mediawiki handles things.
If a new project was branched off.. it would have to keep up with all
the code changes from the mother project, which won't work for very
long. Take a look at fluxbox, for example.. blackbox shifted and
they're now far behind -- unable to import the styles and such from
blackbox, which they still claim to be able to do. That's why I'd be
strongly against the notion.
.. unless MediaWiki was reimplemented in Ruby/postgres.. *hides* ;)