Thread:Project:Current issues/Adding a dev namespace for "Data and developer hub" articles/reply (11)

Hi HappyDog, thanks for engaging with us about this.
 * a separate site is set up, using a variant of the new skin, which pulls it data from the API namespace of MediaWiki and presents it in a static format that is very friendly to third-party consumers That sounds like http://devhub.wikimedia.org! It's read-only and limited functionality, and I Special:Import mw.org content to it. The idea of configuring a separate site in production so that a single set of content can live a second lifestyle at a different host is intriguing and might have wider applicability for special sites like Wikimania, annual reports, etc., but I have no idea what the engineering challenges are. Maybe it's been done, before my time. :)


 * I don't think it's a problem for new developers to encounter different skins. They'll already switch skins when they follow a link to doc.wikimedia.org or out of the API (or dev) namespace.


 * We could develop logic to not show existing mediawiki.org users the Blueprint skin. Obviously "if user's skin is not default, then no Blueprint", maybe "if user is logged in, then no Blueprint" (this sounds like SkinPerNamespace's ), maybe a hidden preference or session variable to identify new visitors, or a definitive "Never screw with my skin choice!!" preference. But it's complex logic that will never catch all circumstances (e.g. long-time user  browsing MediaWiki anonymously). I don't think it's the end of the world if a long-time MediaWiki user is exposed to a new skin on a few dozen pages targeted to a different audience.


 * Perhaps SkinPerNamespace is the wrong idea. I would like to see the OOUI living style guide http://living-style-guide.wmflabs.org moved to mediawiki.org (T93610) for similar reasons, but then we would want two different Blueprint sidebars, so two different namespaces, ... it doesn't scale. I will investigate extension:SkinPerPage and explore an explicit   in pages.