Requests for comment/Shadow namespaces

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

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


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

I think all of this would be great. Wikidata is reaching a point where it has enough translations for specific property names contained in infoboxes that many templates could be made global (translated automatically). This would simplify a lot of scenarios for content growth and synchronization within templates, like when you want to add a new property to an existing template. As far as locations for storing them, I would be comfortable with putting global templates and modules in Commons (I generally support expanding the types of media that can be stored there, like 3D meshes, etc) and putting global gadgets on MediaWiki. Wakebrdkid (talk) 00:34, 10 July 2013 (UTC)

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? Also doesn't really exist yet.

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