Talk:Requests for comment/Configuration database 2

DefaultSettings.json?

 * Context: In an IRC conversation, ^d suggested turning DefaultSettings.php, which becomes a huge metadata file, into a JSON file

^demon, I thought about this a bit and don't think it'll work. The defaults need to be backend-independent, which means it can't be JSON. Legoktm (talk) 03:22, 9 November 2013 (UTC)
 * We do a lot of stuff like after extract globals:

and there even are some hooks and such written into WMF common settings, like SkinCopyrightFooter to set the CC-0 license for Wikidata data namespaces. Important that there is a way to do this stuff in a new system. Aude (talk) 10:12, 20 November 2013 (UTC)
 * Okay looks like maybe that hook is not actually used but there are numerous such hooks for specific things. Aude (talk) 10:17, 20 November 2013 (UTC)
 * $wgDBname can't be changed on-wiki since it's needed to figure out which setting to use in the extraction of globals. The loading order will be LocalSettings.php first, and then LocalSettings.json. I've [//www.mediawiki.org/w/index.php?title=Requests_for_comment%2FConfiguration_database_2&diff=823490&oldid=823091 clarified] this. Legoktm (talk) 18:41, 20 November 2013 (UTC)

All configuration settings? I hope not.
There are a lot of configuration settings that really don't need to be messed with by anyone except sysadmins. For example, there's no possibility that on-wiki configuring of $wgScriptPath is going to make any sense. A lot of other settings have security or performance implications that are not necessarily obvious. Personally, I think I'd rather see a whitelist of configuration settings that can be managed via this mechanism rather than an assumption that things will be managed this way by default. And that whitelist would, of course, not be able to whitelist itself. Anomie (talk) 15:15, 20 November 2013 (UTC)
 * IMO everything that can technically be configurable on-wiki should be. The user rights are flexible enough so that if a preference shouldn't be messed with by an administrator, then just restrict the rights so it can't be touched by anyone not in the 'sysadmin' group. I think it will be important to come up with sane defaults for a simple MediaWiki installation. Legoktm (talk) 18:22, 20 November 2013 (UTC)
 * Before we can proceed, do we need a list of what config settings would be available, by default, to be edited by which user groups, or is it enough if we can agree on some basic principles that will guide this default-setting process? For starters, how about saying that the ones listed at Manual:List of MediaWiki configuration settings containing sensitive data will not even be viewable by anyone but the site owner? The site owner should be in a group that doesn't yet exist, above even bureaucrats. Maybe it's time to bring back the old "developer" group. The developers would be at the top of the hierarchy. Leucosticte (talk) 18:31, 20 November 2013 (UTC)
 * Well all of them would be available to the configuration API backend/storage. What would then be configurable (on a per site basis, I'd imagine) is which ones can be configured via the web, and by whom. ^demon[omg plz] 22:26, 20 November 2013 (UTC)
 * And yet the proposal includes an "edit everything" right, which it sounds like should never be given to anyone ever except for maybe the people who could edit LocalSettings.php anyway. Another fun one, you can't give web editability for $wgGroupPermissions, because anyone who could edit that could edit it to give their group "edit everything" and then edit everything. Anomie (talk) 14:02, 21 November 2013 (UTC)

Viewing settings
I hope it will still be possible for non-'configure'-group users to view config settings, as they are presently able to on wikis (all three of them!) that have Extension:ViewFiles installed. Leucosticte (talk) 18:54, 20 November 2013 (UTC)
 * That is currently the plan. Unless the configuration option has 'private' or 'hidden' set, anyone can view it. Legoktm (talk) 19:37, 20 November 2013 (UTC)
 * This is actually an improvement with reference to transparency, then, because most wikis haven't made LocalSettings.php viewable by users, but this will make most of the settings viewable by default. Good; hopefully this will lead to more active participation by users in making suggestions for config setting changes and will allow wiki system administrators to learn from and copy other wikis' settings. Leucosticte (talk) 20:17, 20 November 2013 (UTC)

Permissions nightmare waiting to happen
I think "flexible permissions system" and the nature of the configure user right are way too vaguely defined. How would the permission be assigned? If it's bundled with adminship, local admins are not elected with any technical knowledge required at all, and generally tend to be disconnected from the MediaWiki technical community (either by ignorance, choice, or language barriers). To me that spells fights and dumb changes to configuration waiting to happen. If it's bundled with a similar right such as bureaucrat or steward, it suffers from the same problems. If it's not bundled with a currently existing user right, there are two options: either elections locally or globally, which create even more bureaucratic overhead nobody wants, or the configure right is appointed by fiat somehow, which I don't think anyone would like either. Basically I think it's a no-win situation when it comes to deciding how to give out a new configuration right, which suggests to me the idea is fundamentally flawed. Steven Walling (WMF) &bull; talk   21:54, 21 November 2013 (UTC)
 * I'm not sure I follow your logic here.
 * For Wikimedia wikis: what's wrong with using stewards? Stewards were always envisioned as the roots of Wikimedia. Stewards will implement requests from local communities just as shell users do now. The fact that logo changes and the like currently require a shell user is bad for many reasons, not the least of which are that it's expensive and doesn't scale.
 * For MediaWiki wikis: it's long been a request to have a sane mechanism by which to change settings similar to that of any modern computer program. (What desktop application doesn't have a preferences area? Why wouldn't MediaWiki?) Requiring users to edit messy PHP files is obviously a poor design.
 * This particular proposal does have some user rights issues, to be sure. The proposal seems so flexible that we could end up with hundreds of new user rights, which we obviously want to avoid. Is this your concern? --MZMcBride (talk) 05:27, 22 November 2013 (UTC)
 * I likewise don't follow your logic. MediaWiki has a Preferences area. Like most applications for the Web and for desktop, this allows to you to change preferences at the user level. Comparing to the preference system in a desktop app doesn't make a whole lot of sense in general, since what we're talking about is adding the ability for sysops or Stewards to change the settings for all other users. That's not preferences, it's site configuration. The only applications I know of that do major site configuration work through a GUI are CMS systems like WordPress. These are not a good corollaries. These systems operate this way because they are designed to be downloaded, hosted, configured, and run by users who cannot do configuration outside of a GUI. On these CMS's, the user who needs to do site config through a GUI also typically is the sole decision maker. There aren't really any good examples of other systems as large as ours, where end users with superuser privileges can do site configuration for thousands of other users who work in a shared collaborative environment. This is probably because it's a recipe for madness. Steven Walling (WMF) &bull; talk   22:06, 24 November 2013 (UTC)

Accountability and avoiding accidental breakages
I notice not all of the arguments from the old RFC were copied into this one. It would still be accurate to say, wouldn't it, that this change will improve accountability (by logging who changes what) and help avoid accidental breakages, e.g. if someone forgets to put a semicolon before they save LocalSettings.php? Also, won't it be more secure, since it doesn't require giving out shell access to a bunch of people who don't necessarily need the capability of breaking anything and everything in potentially hard-to-fix ways? Leucosticte (talk) 23:09, 24 November 2013 (UTC)