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.

commons.wikimedia.org
Outside project scope? Already treated as a central (media) repository with precedence support (where 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.

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

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)

scripts.wikimedia.org
Hmmmm. Create a new wiki? Do we want a wiki where it's all (or mostly) developer-types running around? There are a lot of features of using a separate dedicated wiki of some kind for global scripts.

scripts.mediawiki.org
Are we serving Wikimedia wikis or any MediaWiki user? This could always be a redirect as well, of course.

Licensing

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