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).

Request for comment (RFC)
Global user preferences
Component General
Creation date
Author(s) MZMcBride, Legoktm
Document status implemented
See Phabricator.

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

Background edit

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

Arbitrary section heading edit

Location edit

Existing locations edit

  • Special:Preferences on each wiki for user_properties. Compare: on mailman, the options panel for each list is able to change an option for all the lists on the same server, by checking the "change globally" checkbox.

Wikis for stuff which requirs pages edit

  • 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).
  • 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#Shared gadgets
    • 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)[reply]
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)[reply]

New locations edit

Maybe scripts.wikimedia.org, scripts.mediawiki.org? (see also meta:Global-Wiki and meta:Requests for comment/Global bits and pieces#Locations)

Pros:

  • New wiki, no existing content to worry about

Cons: