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, for instance) * $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 it more)' * 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 them) * $wgNamespacesToBeSearchedDefault * $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) * $wgImportTargetNamespace * $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) * $wgContentNamespaces 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.
