Last modified: 2011-01-25 01:36:44 UTC
We see lots of bug requests here that require someone with shell access to add
new namespaces, enable Wiki.png, etc. Why not eventually let
bureaucrats/stewards do some of the stuff that doesn't require technical
knowledge, from in-wiki? (Obviously these options would all be moved out of
LocalSettings.php and into the database somewhere. Maybe they could even be
killed as globals and switched over to constants instead . . .)
As long as the options are easily reversible, there's no security issue. It's
probably best to tack everything uncomplicated and easily reversible into this
bug proposal, in fact, because GUIs are more friendly than file-editing, except
that on WMF sites there are some things that 'crats shouldn't be allowed to
touch (e.g., $wgGroupPermissions['*']['edit']).
Some of the following would be suitable options for eventual inclusion:
* $wgEnableUploads (some WMF wikis want everyone to upload to Commons instead,
* $wgGroupPermissions (for adding new groups *only*, at least on WMF sites, a la
rollback or whatnot; only really useful to us once we get a more flexible
group-assignment mechanism so stewards won't have to be bothered constantly,
although other sites with more active userrights-enabled groups might appreciate
* Maybe $wgRestrictionLevels, if it works as one would expect? Particularly
useful if some wiki wants to introduce a "semi-sysop" group of some kind.
Probably only allow people to touch custom entries, not the current three, or
else things could break.
* $wgNamespacesWithSubpages (if it can't screw up existing names with slashes in
* $wgImportSources (but maybe have a list of valid sources set from text file
for use in WMF projects; trying to import from Meatball: would probably be Bad)
* $wgExtraNamespaces (obviously not in present form, which is way too easy to
break stuff with; progress was made at some point with [[m:Help:Namespace
manager]], but that seems to have died)
* $wgForceUIMsgAsContentMsg (unless this can break stuff)
Presumably a new permission like 'config' would be added to handle this, with
bureaucrats getting it by default.
There are a multitude of reasons we don't allow bureaucrats to set site
configuration. This is the cause for having a team of system administrators to
do the work; they understand exactly what each case does, and know what
supplemental work (maintenance scripts, etc.) needs to be performed for each.
The old argument that "the developers [sic]* don't work hard enough" is
bollocks, but if you do feel that, then be a bit more persistent.
A number of the configuration options above are NOT suitable to be edited by any
old Joe Smith who the community trusts, and many are NOT innocuous and
unbreakable. Trust does not equal expertise, and I would predict the larger
wikis breaking down within moments. Fuck 3RR, just think of the config. wars.
Next up, performance. Storing this stuff in the database means we have to go
digging it up when we want it. Right now, use of the SiteConfiguration class and
the caching for it means that on sites like Wikipedia, MediaWiki takes less time
to initialise and it's optimised.
I am absolutely against handing over access of this nature to end users who are
elected through voting farces.
* Developer != System administrator. The former codes, the latter administers.
I never suggested the options *as currently implemented* should be editable. I
suggested that the *concepts behind the options* should be editable. I
apologize if that wasn't clear enough. Any change of something that required a
maintenance script . . . would run the maintenance script. If there's a problem
with running a maintenance script every time an option needs to be changed, then
that's not "safe" and is unrelated to this bug (see: summary word two). There's
no drawback in allowing bureaucrats to change what checkboxes are on by default
in Special:Search (see, e.g., bug 6306).
I'm not making firm suggestions about implementation, I'm just saying that some
*choices* that can currently be implemented only by developers could be allowed
for implementation by bureaucrats, and that this would have benefits in terms of
responsiveness to our smaller wikis, just as the original creation of the rank
relieved developers of the need to promote sysops. Do you have a problem with
the namespace manager?
(P.S.: enwiki and a few of the other large wikis elect bureaucrats, but most
wikis with a bureaucrat have only one, steward-appointed. Even the largest have
only a few active bureaucrats — roughly eight or so on enwiki — and I've never
heard of either a bureaucrat- or steward-war.)
This is [[mw:Extension:Configure]].
(In reply to comment #3)
> This is [[mw:Extension:Configure]].
Closing this as fixed; please open separate bugs to request more features in Configure or for Configure to be enabled on WMF wikis.