Page MenuHomePhabricator

Create Portal namespace on wikitech to give a place for audience specific landing pages
Closed, ResolvedPublic

Description

The Portal namespace is used on some Wikimedia wiki projects to provide entry points to the wiki's contents oriented around specific audiences. Adding a Portal namespace to wikitech and using it for a similar purpose would provide a means to organize content for the various audiences there (e.g. WMF production, Tool Labs, Labs, Deployers, WMF Office IT, ...).

Event Timeline

bd808 raised the priority of this task from to Needs Triage.
bd808 updated the task description. (Show Details)
bd808 added subscribers: Aklapper, StudiesWorld, bd808.

Potential initial content: https://wikitech.wikimedia.org/wiki/User:BryanDavis/NewPortals

This is a strawman design I've put together for a new Main_Page for wikitech and initial Portal:X pages for the three largest audiences that we have today.

I'd like to emphasise tool labs being part of labs in the design

@bd808: Are you also considering creating a Tools namespace specifically for Tool Labs content? This would solve the problem of not being able to effectively search Tool Labs documentation (since you always get Labs and WikiTech documentation instead).

@Krenair: I think emphasizing that Tool Labs is part of Labs would make things more confusing without adding any benefit. Typically, Tool Labs users don't care about Labs and shouldn't have to.

Found the task for the Tool namespace, so nevermind :) T123429

@bd808: Are you also considering creating a Tools namespace specifically for Tool Labs content? This would solve the problem of not being able to effectively search Tool Labs documentation (since you always get Labs and WikiTech documentation instead).

That's sort of like T123429: Create a Tool namespace on wikitech for documentation of Tool Labs projects, but maybe not exactly the same thing.

@Krenair: I think emphasizing that Tool Labs is part of Labs would make things more confusing without adding any benefit. Typically, Tool Labs users don't care about Labs and shouldn't have to.

Maybe not, but they should know the difference and roughly what sorts of things are controlled at which level.

@bd808: Are you also considering creating a Tools namespace specifically for Tool Labs content? This would solve the problem of not being able to effectively search Tool Labs documentation (since you always get Labs and WikiTech documentation instead).

T123429: Create a Tool namespace on wikitech for documentation of Tool Labs projects is a proposal more about giving tool projects themselves a place to document things rather than documenting the Tool Labs infrastructure.

There is some overlap between Tool Labs and the parent Labs project as well that may make complete separation of support and infrastructure documentation undesirable. For example, most documentation about the production database mirrors and the other dumps data available in Labs is relevant to both Tool Labs and Labs projects. Today we have the "Help" namespace for both Labs and Tool Labs documentation. I think with a bit of effort we can make that work using portals and categories to help with organization. If it turns out to be too hard we can always try splitting them into different namespaces later.

@Krenair: I think emphasizing that Tool Labs is part of Labs would make things more confusing without adding any benefit. Typically, Tool Labs users don't care about Labs and shouldn't have to.

Maybe not, but they should know the difference and roughly what sorts of things are controlled at which level.

I think the key thing will be to clearly describe the pros and cons of Labs and Tool Labs somewhere on wiki (do we have that already?) in some sort of feature grid that makes it clear why a project would want to use one or the other. One ridiculously over simplified way to describe it would be that Labs is like a VPS provider (or infrastructure as a service) and Tool Labs is more closely related to a shared hosting solution (or platform as a service). The VPS option gives greater control but that control comes with a higher configuration and maintenance cost to be born by the project.

What would such a namespace accomplish? You can always name a page Portal:Something (or, if you prefer plain English, Something portal). It seems like there would be about half a dozen portals altogether, so the navigational benefits of a separate namespace do not apply.

What would such a namespace accomplish? You can always name a page Portal:Something (or, if you prefer plain English, Something portal). It seems like there would be about half a dozen portals altogether, so the navigational benefits of a separate namespace do not apply.

Reasonable suggestion. I doubt that we will end up with hundreds of portals for wikitech so simply using a naming convention and maybe a category would probably suffice for organization. If it turns out that we have a vastly growing number of portal pages we could always make the namespace and move the pages later.

Using enwiki's Portal namespace as a model for the target audience specific documentation was @kaldari's suggestion when we discussed the current situation. Once that seed was in my head I didn't really consider whether or not the usage on wikitech would really necessitate a separate namespace. My historical experience setting up MediaWiki installs has been pretty namespace oriented to support editing privilege separation. Using $wgNamespaceProtection on an intranet wiki is a pretty nice way to enforce departmental boundaries and provide limited search scopes, but on a public wiki like wikitech that's probably not too valuable.

bd808 claimed this task.

For now I've decided to go with the simplest thing that will work which is following @Tgr's suggestion of just using a naming convention and category. See https://wikitech.wikimedia.org/wiki/Category:Portals

What would such a namespace accomplish? You can always name a page Portal:Something (or, if you prefer plain English, Something portal). It seems like there would be about half a dozen portals altogether, so the navigational benefits of a separate namespace do not apply.

That would depend on whether you are having a freeform namespace or looking to apply some method and rigour.

The Wikisources use their namespaces well to sort and coordinate their subject matter. They also apply templates that allow for a standardise look, feel and data in a ready fashion. Be that data be auto or manually generated is less relevant that the quality of the data. Giving guidance and standardised templates to handle the introductory aspects gives uniformity and the basis for better data, and the evolution of that data over time. The author namespace in English Wikisource has proven very successful for use, for addition of data, for tailoring searches; linking to wikidata, etc.

So I support a specific namespace addition be it portal:, or tools: though it will need more than the namespace, it needs its development of structure and attention to pertinent detail.

Also looking at the discussion above, I also believe that it has forgotten that our tools sitting in a namespace of their own also opens up an opportunity to be linked into Wikidata as the these tools become what is notable at Wikitech, with the best tools being the portent of components opening the Pandora's box to Wikimedia sites. Having a namespace also provides an ability to look at tools historically, both in their own development sense, and the antecedents and successors, active vs. closed. All good data to be added manually or to be pulled from Wikidata.

So I think that if we have an outward focusing consideration of Wikitech, rather than a myopia. There is a lot of scope for good data that gives wikitech and its projects their own notability.