Page MenuHomePhabricator

Future of the current Developer Hub at
Closed, ResolvedPublic


The creation of the new Developer Hub will have an impact on

The new project still has many moving pieces (i.e. will the new hub be hosted in or not?) and the first goal is to build a prototype that will not challenge the current role of mw:Developer_hub.



Related Objects

Event Timeline

flimport raised the priority of this task from to Medium.Sep 12 2014, 1:43 AM
flimport added a project: Web-APIs-Hub.
flimport set Reference to fl492.

qgil wrote on 2014-08-25 12:58:13 (UTC)

We are going for "Build" and "", a term and a URL that doesn't clash directly with We still need to avoid duplication and a better plan to integrate both spaces, but at least the rename of this project will make the plan simpler.

Krinkle wrote on 2014-08-25 13:23:45 (UTC)

Please don't call it "build".

Build in context of web development, engineering and technology is primarily associated with artefacts resulting from compiling (or "building") a piece of software. Sometimes equal to the distribution or offered download of a product.

I guess the logic here is to indicate that you'd use this portal to "build" something with Wikimedia technologies (e.g. develop software by hand, not automated compilation/building of an existing application).

However using "build" in that way is imho a mistake. Both because our target audience will not have this association, and because it doesn't seem to be used that way by an other major parties either. It sounds like a awkward compromise that serves nobody ("I'm going to build something with Wikimedia stuff, so I go to" Yeah, no..).

I thought we already agreed on the name "Developer Hub", located at dev, develop or

Elsewhere names proposed were:

  • Not appropriate, since that doesn't cover the content (it discusses more than just APIs), and the hub will most likely not host a single actual API.
  • Good, but not good enough; scope is wider (will likely contain demos as well). Content currently at should move to this new hub, using automated publishing of new builds after commits to projects with generated documentation and demos.

See also write-up at

qgil wrote on 2014-08-25 14:08:21 (UTC)

"Developer Hub" was what I had been proposing until recently. Moyz, Dario, Jared, and others seem to be reluctant to use "Developer" without the "Data" part.

Would create.w.o. or make.w.o. work better? These have been also considered.

qgil wrote on 2014-08-25 14:10:58 (UTC)

PS: I have also proposed

Krinkle wrote on 2014-08-25 16:42:48 (UTC)

I know it's for more than documenting developed software. I helped build and I support this hub and can't wait to migrate to it so that demos and manuals can be integrated better into the API documentation.

The portal is also about making datasets available, showcasing how the data can be used, etc. But I think "Developer" covers that scope just fine. Existing sites from other organisations have gone that route too and seem to be doing fine. I'm curious as to the rationale to deviate from "developer" and indeed why "build" would be so much better. Was this discussion with named individuals public somewhere? (or at least explained somewhere?).

I'll continue with inferred arguments for why one might think "developer" doesn't cover it. "Developer" doesn't mean the intended users are only Wikimedia developers, or people interested in software "develop"ed by Wikimedia. It reaches all (esp. third-party) "developers" and people interested in what developers do; whom are interested in using data (or software) from Wikimedia, or seeing how other developers have used it.

Individual projects that reach regulars users directly as product will have their own domain anyway (e.g. wikistream wouldn't be hosted on this hub, it would be promoted however; and those users won't be served any better by build, create, make or io, than developer as they're not wanting to develop something).

If we have a major need for an interface dedicated to stuff that we don't want to be seen in public under the name "developer", perhaps we need a separate hub for those pages? I actually think this is fine in the scope of one hub, but if there's really a fear for mis-serving non-developers, I think changing the name won't fix that, you may need a separate hub. Something confusing or generic like build, make or create wouldn't serve anyone I think. While develop(er) is also quite generic, it's an established term that people understand.

"Build" especially is confusing because it's actually been used in the past (and CI is thinking of bringing it back) for hosting integration builds or software distributions (though is doing a good job of that now, better than the old and

qgil wrote on 2014-08-25 19:10:47 (UTC)

Well, ok. I've been scanning all this naming discussion backwards in order to find the best place of common agreement, only to conclude that... after all we will go for as URL, since this was the original proposal and it works for the rest of us. This solves T490: Wiki Release Team Quarterly Review on 2014-10-15 for good.

The exact name is less important right now. "" can be the name if we want. Or Wikimedia Developer Hub. Or even Wikimedia Data & Developer Hub. We can continue the discussion, but I would do it based on actual mockups of the homepage and regular pages.

Qgil lowered the priority of this task from Medium to Low.Oct 22 2014, 6:20 PM

What's in a name, right? Clear, concise, relevant and up to date documentation will make or break this hub regardless of its name. In particular, I'd like to see the examples of interesting uses of the Wikimedia Data through the API highlighted. This would allow for easier marketing of the hub as the examples could be pushed to various technically inclined news sites to both get the project's developer exposure as well as drive traffic to the hub.

Alright, here goes a proposal for T101441: Goal: Integrate the new Web APIs hub with It focuses on the BASICS, acknowledging that there are 1001 little details, but putting them aside because once the main organizing principles are sorted out, the rest will follow.

In terms of concepts

In terms of names supporting such concepts

  • "" will redirect to "Dev" namespace in (T369)
  • "Code contributors hub"

In terms of content

  • everything API related goes to Dev
  • everything related to free software collaboration goes to Code contributors hub
  • we can link from one space to the other where appropriate

This leaves some questions open. In case of doubt, we just leave the docs where they are today. This is how we can avoid bikeshedding between now and the end of next quarter. There will be time to improve the organization and fix the smaller problems.

In T313#1356150, @Qgil wrote:
  • "Code contributors hub"

How about "Technical contributors hub"? I suppose this would cater to non-code contributions as well (bug reports, documentation, translation, etc.)

That is a fat and complex page already. Do we really want to increase the scope to non-coders, in order to bring more links?

I don't see where else those contributors would go, but I don't have a strong opinion on this. Just wanted to make sure this wasn't merely an overlook. is the first landing page for "Contribute" (top level in the homepage). The current "Developer Hub" covers a subset of that.

In T313#1359657, @Qgil wrote: is the first landing page for "Contribute" (top level in the homepage). The current "Developer Hub" covers a subset of that.


I see tofu. :)

(raw shows "+1", thank you, and interesting bug)

Yeah, interesting indeed. I wrote that on Windows and it does show the Unicode character, but now on Linux I don't see it. But it isn't a local font problem, because on I can see the character. So I can only guess that the bug lies in Phabricator's CSS font definitions.

Sorry, turns out uses a custom font to achieve that. In I see tofu as well. I guess it is a local font problem after all...

T369: Implement a namespace in to host the developer hub is stuck between going for Dev: or Api: namespace. Each option has different implications, and the future of the current Developer Hub would be affected in different ways. Hence, making as Blocked by.

We have resolved to move away from the "Developer hub" and the "Dev" concept in general, and focus on APIs instead. This means that this project now is not causing any disruptions to Resolving.