Requests for comment/Global user preferences

This is a request for comments regarding implementing global user preferences. This request for comments encapsulates user preferences from MediaWiki core and user preferences from MediaWiki extensions (including the Gadgets and BetaFeatures extensions).

Global here refers to preferences that would apply across a wiki-farm (e.g., Wikimedia-wide).

Background
Currently user preferences are stored locally in an individual wiki's user_properties table.

Arbitrary section heading

 * Global gadgets (bug 20153)
 * Global gadgets are mostly implemented in core and in the "RL2" branch of the Gadgets extension. It needs some cleanup and updating before being deploy-ready.
 * Free software license for (global) gadgets on wikitech
 * en:Wikipedia:Village pump (policy)/Archive 98
 * 14950 – Global preferences
 * usage tracking — for gadgets, T35355 and T21288

Existing locations
Potential existing wikis: commons.wikimedia.org
 * Outside project scope? Already treated as a central (media) repository with precedence support (where [[File:Foo.ext]] will use the Commons version, unless a local version exists).

wikidata.org
 * Outside project scope?

meta.wikimedia.org
 * A number of cross-wiki items already largely lives here (global blocking, global title blacklist, global spam blacklist, global user rights, etc.) - but these are administration rather than content sharing.


 * Global user CSS/JS also lives on meta, however that is only Wikimedia-wide, not for all MediaWiki users.

mediawiki.org Suggested at:
 * Thread:Talk:ResourceLoader/V2 testing/Questions about permission model and developer workflow
 * ResourceLoader/Version 2 Design Specification

Pros:
 * Already existing community with mainly developer-type people
 * Some "global" gadgets are already hosted on mediawiki.org

Cons:
 * Already has populated Template/Module namespaces, might need to move things around to accommodate global ones
 * mediawiki.org is treated like a testwiki and is phase0, it might need to be more stable if it is depended upon by all MediaWiki wikis

MediaWiki.org is its own community and its own wiki. It will likely have local needs that could conflict/get in the way of global needs. It probably makes sense to treat mediawikiwiki as a documentation wiki for the MediaWiki software.


 * What is the nature of these conflicts? If we don't use Git, IMO mediawiki.org is the next obvious choice; there's a community here already that does a lot of wiki gardening/gnoming, it's got visibility through lots of inbound links, it's where we coordinate a lot of the larger development efforts, and it serves both WMF and third party users. The main disadvantage that I could see is that code activity could become a little bit overwhelming in Special:RecentChanges and such, but if that became a real problem it could probably be solved with filters, in the same way that translations are filtered by default on Meta.--Eloquence (talk) 08:49, 4 December 2012 (UTC)
 * I had to look up who wrote the line about conflicts in the page history. It was me. I can't honestly remember exactly what I meant when I wrote that. I think the idea was that mediawiki.org would have its own modules/templates that serve mediawiki.org (for example, Template:Extension) and there would be naming conflicts/collisions between these pre-existing templates/modules and newer global templates/modules. Basically you're starting with polluted namespaces (Template and Module) on mediawiki.org, as opposed to a separate new site (e.g., scripts.wikimedia.org), which would have empty Template and Module namespaces.
 * Generally, we need to put a lot more thought into global everything (global user pages, JavaScript gadgets, Scribunto modules, wiki templates, CSS/JS user subpages, user watchlists, etc.) before it turns into a real mess. --MZMcBride (talk) 04:26, 2 March 2013 (UTC)

New locations
Maybe scripts.wikimedia.org, scripts.mediawiki.org? (see also Global-Wiki and Requests for comment/Global bits and pieces)

Pros:
 * New wiki, no existing content to worry about

Cons:
 * Need to build up a new community
 * Yet another wiki to maintain, watch (maybe not: see T5525, meta:Grants:IEG/Global Watchlist), etc.