Requests for comment/Shadow namespaces

A lot of this depends on the implementation details of global scripts. However, in either implementation, it would be possible (and advantageous) to have a central repository of things somewhere.

Existing

 * Global spam blacklist (Extension:SpamBlacklist) - MediaWiki wide, on Meta
 * Global title blacklist (Extension:TitleBlacklist) - Wikimedia wide, on Meta
 * Commons image repository (InstantCommons) - MediaWiki wide, on Commons
 * Wikidata data repository (Wikibase) - Wikimedia wide, on Wikidata
 * Global CSS/JS (Extension:GlobalCssJs) - Wikimedia wide, on Meta
 * Global user pages (Extension:GlobalUserPage) - Wikimedia wide, on Meta (planned: T72576)

Scope
For the purposes of this RFC, we're looking at least:


 * Global gadgets (bug 20153)
 * Global Scribunto modules ((bug T41610)
 * Global templates (bug 4547)

In this context, "global" means MediaWiki-wide, so any and all MediaWiki installations should be able to use these (possibly requiring installation of extensions/setting up configuration). In addition, wiki farms would be able to designate one of their wikis to be used as the central repository if they choose not to use the default one.

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.

Suggested at:
 * mediawiki.org
 * 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 or scripts.mediawiki.org?

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

Cons:
 * Need to build up a new community
 * Yet another wiki to maintain, watch, etc.

Compatability
MediaWiki installations using global scripts will not keep pace with WMF deployments, so we need a method to continue to support older versions (or maybe just versions that are still supported with code/security updates?).

Usage tracking
For media on Commons, we have GlobalUsage tracking, however that's only Wikimedia-wide, and captures no usage information about non-WMF installations using InstantCommons. This means that Commons administrators have no idea whether a file is actually used or not when doing destructive operations like renaming (without leaving a redirect behind) or deleting.

When a new version of a file is updated on commons, it will automatically update on InstantCommons sites since images are hotlinked. However if a template is updated, it should cause HTMLCacheUpdate jobs to be queued so all pages are updated.

See also: Mentorship programs/Possible projects (T48525)

Current progress / Implementation status

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


 * $wgEnableScaryTranscluding exists in core, but isn't usable and could probably be removed in favor of a real solution.

Licensing

 * Free software license for (global) gadgets on wikitech
 * en:Wikipedia:Village pump (policy)/Archive 98