Adding #Wikimdia-Site-requests to get this ball rolling.

Do we really want to allow yet another extension that'll only be used on one (tech-centric) site? Is the maintainer active?

cc'd author @tstarling

Hmm, that's SkinPerPage.. :S

For what is worth: https://wikiapiary.com/wiki/Extension:SkinPerNamespace

In T98897#1356504, @Krenair wrote:

Do we really want to allow yet another extension that'll only be used on one (tech-centric) site?

The alternatives would be

• Use https://wikiapiary.com/wiki/Extension:Skin_per_page, which is in the same situation, only with a bit more usage and a WMF employee that happens to know about it. Some extra hassle to keep all #dev.wikimedia.org pages looking alike, but if there is no other choice...
• Use Vector skin for #dev.wikimedia.org, with the sidebar and header links we want to get rid of, with the old look&feel we want to depart from.
• Keep #dev.wikimedia.org in Labs with Blueprint skin and let it grow and be famous there, until mediawiki.org runs Blueprint by default, or another skin that fits the purpose of the site. Not anytime soon.
• Check whether other Wikimedia projects are also interested in this feature and pool interest here. Too much energy and not anytime soon, although I do see the point of having this possibility i.e. to distinguish Main from backstage namespaces. Anyway, a discussion that I don't feel like starting.

Is the maintainer active?

CCing @IAlex

You can evaluate this better than me, but it looks like a very simple and stable extension: rESPN extension-SkinPerNamespace

This may not be the right place to say it, but I just want to throw it out there.

Making half of mw.org use a different skin so that the styling is inconsistent seems like a bad idea to me. Consistency of UI is important.

@Bawolff , there is an ongoing discussion at https://www.mediawiki.org/wiki/Project:Current_issues#Adding_a_dev_namespace_for_.22Data_and_developer_hub.22_articles_58129. The topic of consistency is already being discussed there.

We decided not to create a new Dev: namespace on mw.org, instead the pages written for the "Web APIs hub" will mostly be in the API namespace along with hundreds of existing pages. So SkinPerNamespace is not what we want. Instead we'll probably use the SkinPerPage extension. Similar concerns and dependencies apply, so I'll rename this task.

The decision was to "NOT create a new Dev: namespace and to improve the existing Api: namespace instead". I have been assuming that this meant that all the content in the Api: namespace would be organized and integrated as "Web APIs hub", and therefore all the pages in that namespace would get the same skin.

I see no reason or benefit in offering different look&feel for existing Web APIs pages and new Web APIs pages created with the hub in mind. Web APIs documentation is Web APIs documentation regardless of date of creation and author.

I'm setting High priority to this task because this discussion needs to be resolved first.

In T98897#1487237, @Spage wrote:

the pages written for the "Web APIs hub" will mostly be in the API namespace along with hundreds of existing pages. So SkinPerNamespace is not what we want. Instead we'll probably use the SkinPerPage extension.

From bad to worse.

I agree with QGil and Ricordisamoa - skin per page is completely contrary to where consensus seems to be going. You might just about get sufficient support for a separate skin for the namespace as a whole (though there is quite a lot of opposition, too), but I doubt skin-per-page is going to be approved by the community, based on comments made so far (assuming, of course, that the MW community is going to be listened to).

@Spage and I discussed this topic yesterday. The plan is to T105133: Organize current and new content in the API: namespace at mediawiki.org. Therefore, all pages within the API: namespace will conform the Web APIs hub. Therefore, the proposal for a different skin comprises all wiki pages in the namespace. We are going back to the original proposal for enabling SkinPerNamespace instead of SkinPerPage.

Thanks for the feedback. I think y'all are objecting to existing users seeing Blueprint for some pages in the API namespace and not others. I hope to finesse the defaults on mw.org so that existing users don't see Blueprint at all.

Blueprint's main innovation in skin "organization" (as opposed to visuals) is the integration of the current page's TOC with a sidebar. That's effective for a small set of pages such as the pages currently featured in the Web APIs hub and the OOUI Living style guide. Fitting all 178 English pages in the API namespace is harder, e.g. here's API:Main_Page in the skin.

In T98897#1487535, @HappyDog wrote:

(assuming, of course, that the MW community is going to be listened to).

Of course I will listen. The goal of all this is to encourage third-party developers to use Wikimedia APIs and data. To that end, we're writing pages with a shift of focus (less "How you can contribute", more "Here's what WMF has to offer you"), and we want to engage new developers with a modern appearance. I think those are reasonable goals.

Please forget for a moment about the characteristics of the Blueprint skin. The discussion that matters is: are there any reasons to make a radical distinction between "existing API: namespace pages" and new "Web APIs hub" pages?

I don't think so, since all of them contain information useful for developers willing to use Wikimedia APIs. Some of them will be more generic or introductory, and we will promote them in the main page and navigation. Some of them will be more specific or advanced, and users will reach them through searches or more clicks. Nothing new in terms of web architecture?

This discussion is not related to new vs existing users. The Web APIs hub aka API: namespace must be consistent for all, both in structure and look & feel.

About the characteristics of Blueprint, yes, we will need to look in detail. However, no sidebar is expected to contain all pages of a website, and we can have secondary nav bars via template in content, subpages, pages at the end of the tree that don't appear in any nav bar... Again, the usual navigational tools we have in MediaWiki and websites in general.

I hope these arguments are convincing enough to make you desist of the idea of using SkinPerPage and go for SkinPerNamespace instead. We are having our weekly meeting today. Let's discuss this until we both agree on a solution. It's mid August and we need to move forward.

In T98897#1523539, @Qgil wrote:

are there any reasons to make a radical distinction between "existing API: namespace pages" and new "Web APIs hub" pages?

No.

Are there any reasons to make a radical distinction between "API namespace pages" and other pages on mediawiki.org?

Neither.

This discussion is not related to new vs existing users. The Web APIs hub aka API: namespace must be consistent for all, both in structure and look & feel.

Why not to keep the whole site consistent then?

In T98897#1528994, @Ricordisamoa wrote:

Are there any reasons to make a radical distinction between "API namespace pages" and other pages on mediawiki.org?

Neither.

We have discussed this already.

The main target audience for this hub are developers not developing, or even running, the MediaWiki software. We want to diminish the risk of confusing them by mixing the content relevant to the with the rest of mediawiki.org. We plan to address this risk by morphing the API: namespace into the Web APIs hub, controlling and contextualizing links to other part of mediawiki.org or other Wikimedia sites. We also want to try offering a different look&feel in this namespace.

https://www.mediawiki.org/wiki/Web_APIs_hub

We have also proposed to park this discussion until T93613: Deploy Blueprint on mediawiki.org as optional and experimental skin is resolved. When that happens, let's try the Web APIs hub with Blueprint in our personal configurations, and then let's discuss.

We want to diminish the risk of confusing them by mixing the content relevant to the with the rest of mediawiki.org.

And instead, increase the risk of confusing everyone else.

I still think a separate static site driven by MW.org content is the way to go, if that is your end goal, instead of turning MW.org schizophrenic.

Tuesday 2015-09-01T18:00 UTC (11am San Francisco time) we will be having an IRC office hour about

• T101441: Goal: Integrate the new Web APIs hub with mediawiki.org
• T105133: Organize current and new content in the API: namespace at mediawiki.org
• T98897: Deploy SkinPerNamespace extension on mediawiki.org

If you're interested in developing with, documenting, or promoting MediaWiki/Wikimedia APIs, you should attend. I hope by having a realtime conversation we can come to a shared understanding faster.

(Thank you Andre for all this cleanup.)