Page MenuHomePhabricator

Name for the 'developer hub'
Closed, ResolvedPublic

Description

We need to agree on the name for the 'developer hub'.

  • Wikimedia Developer Hub (default option)
  • MediaWiki Developer Hub
  • Wikimedia Data & Developer Hub
  • MediaWiki Data & Developer Hub
  • Wikimedia API
  • more?

Details

Reference
fl488
TitleReferenceAuthorSource BranchDest Branch
Return error when attempting to resolve ZWrapper with a nonexistent key.repos/abstract-wiki/wikifunctions/function-orchestrator!130apineapine-zwrapper-undefined-keymain
Add first gitlab-CI pipeline - Test onlyrepos/ci-tools/wmf-jvm-parent-pom!2joalbase_cimain
Add first gitlab-CI pipeline - Test onlyrepos/ci-tools/wmf-maven-tool-configs!2joalbase_cimain
Update from discovery to wmfrepos/ci-tools/wmf-jvm-parent-pom!1joalupdate_from_discovery_to_wmfmain
Update from discovery to wmfrepos/ci-tools/wmf-maven-tool-configs!1joalupdate_from_discovery_to_wmfmain
querypage: Change the target path to be the exact name of the query pagerepos/data-engineering/airflow-dags!566ladsgroupquerypage_improve_pathmain
Add support for nested go.mod filesrepos/security/gitlab-ci-security-templates!25sbassettT309997-add-nested-gomod-supportmain
Integrate go-mod-outdated ci template for Golang Dependency Managementrepos/security/gitlab-ci-security-templates!24mmartoranago-mod-outdatedmain
Introduce querypage_most_linked_templates_monthly DAGrepos/data-engineering/airflow-dags!534milimetricairflow-dags-start_querypagemain
Change badrevid retry logic: retry on recent eventsrepos/data-engineering/mediawiki-event-enrichment!74ottoT347884-retry-badrevid-on-recentmain
Introduce querypage_most_linked_templates_monthly DAGrepos/data-engineering/airflow-dags!494ladsgroupstart_querypagemain
error: version bump to 2.1.0repos/data-engineering/eventutilities-python!73gmodenaadd-error-typemain
Retry on request timeoutrepos/data-engineering/eventutilities-python!70gmodenaT309699-retry-on-timeoutmain
page_content_change: retry requests on missing contentrepos/data-engineering/mediawiki-event-enrichment!62gmodenapage_change-add-badrevisionmain
Update function-schemata sub-module to HEAD (9abc7c2)repos/abstract-wiki/wikifunctions/wikilambda-cli!8jforrestersync-function-schematamain
Update function-schemata sub-module to HEAD (9abc7c2)repos/abstract-wiki/wikifunctions/function-evaluator!17jforrestersync-function-schematamain
Update function-schemata sub-module to HEAD (9abc7c2)repos/abstract-wiki/wikifunctions/function-orchestrator!22jforrestersync-function-schematamain
Remove Z13 references, we've abandoned itrepos/abstract-wiki/wikifunctions/function-schemata!11jforresterT309409main
require golang-any to be 1.16 or later in debian/controlrepos/releng/jwt-authorizer!3dzahnwork/dzahn/build-golangmain
debian: Omit sources from .debrepos/releng/jwt-authorizer!2dduvalldebian/packagingmain
Show related patches Customize query in GitLab

Event Timeline

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

qgil wrote on 2014-07-24 15:15:05 (UTC)

Moiz started calling this project Wikimedia Developer Hub and after all the discussions and attempts I think it is a good name. Do you agree?

msyed wrote on 2014-07-24 17:26:47 (UTC)

In T488#7, @Qgil wrote:

Moiz started calling this project Wikimedia Developer Hub and after all the discussions and attempts I think it is a good name. Do you agree?

I think the word "Data" should be in the name too. I know Dario wants that too. Besides developers we also want researchers, data journalists, dataviz artists/scientists and such to use what we are building.

How does everyone feel about the name "Wikimedia Data & Developer Hub"?

qgil wrote on 2014-07-25 10:46:34 (UTC)

My reasons against "Wikimedia Data & Developer Hub"

  • Unfamiliar term. Pick a search engine and you will find that the only reference to a "Data & Developer Hub" is this project. In the entire Internet.
  • Extremely long. Bad for titles, logos, references... People have been finding shortcuts to refer to it and would continue to do so, which defeats the purpose of a project title.
  • As far as I understand, a "Data Hub" is not what we are offering here. This term refers to a site full of data with a prominent search box, or to a specific software to manage data.
  • "Developer" doesn't exclude researchers. As soon as you are using an API, you are a developer.
  • You are proposing dev.wikimedia.org as a domain, which already shows the need to simplify the name.

Looking at https://www.mediawiki.org/wiki/Data_%26_Developer_Hub#External_examples we can see that there are a few terms used to reference to projects: developer(s), docs, API, engineering, services.

  • We can forget about services because is plain boring and can mean anything. Agreed?
  • Engineering + Wikimedia == a WMF department. Discarded.
  • Being Wikimedia an open source project welcoming contributors. "developer" and "docs" have a scope that goes beyond to the scope of this project, since both term can apply to 3rd party developers and project contributors.

Therefore, what about

Wikimedia API

Short, crystal clear, and equidistant from pure developers and pure researches. The sections Inspire, Explore, and Build refer to the API. This would "free" mediawiki.org's Developer Hub from direct pressure, and such pressure would be inflicted directly on https://www.mediawiki.org/wiki/Api, which is really the area that this project wants to revamp.

qgil wrote on 2014-07-31 21:32:33 (UTC)

Any comments about my proposal for "Wikimania API"? Let's try to close this task. Pushing a project is easier when it has a name. :)

DarTar wrote on 2014-08-15 17:45:57 (UTC)

Sorry for not chiming in earlier. I gave some feedback to Quim and Moiz at Wikimania.

I told Quim that I actually don't dislike the Wikimedia API idea, although that shifts the focus away from some of the most important datasets that people use (such as the XML dumps and the pageview dumps) which currently are not served by an API (and may never be)

Aside from this, there will also be some confusion we need to be aware of with the MediaWiki API. Right now if you ask people about the English Wikipedia API they will (legitimatelly) point you to /api.php – so I remain conflicted about this option although it's definitely one that doesn't suck.

From a totally different angle, partly inspired by Last.fm (1, partly inspired by Raph Koster's excellent Wikimania talk about the educational role of fun, I thought play.wikimedia.org would make a really nice domain name. No confusion with Wikidata about the use of the word "data", no restriction imposed by the choice of "API" and a clear indication that this is about encouraging people to reuse, remix and creatively build stuff on top of our APIs and data. Google uses "playground" for the OAuth section of their developer hub.

What do you guys think?

qgil wrote on 2014-08-18 20:47:14 (UTC)

After letting the idea sink during the weekend...

Although I don't dislike the concept of "Play" and I welcome the attitude behind it, it is also true that both Last.fm and Google don't use it prominently, and they use it with a different meaning.

  • Last.fm refers to "API" http://www.last.fm/api; http://playground.last.fm/ is more akin to our Beta Features.
  • Google talks about "Code", "Developers" and then "Products" and "APIs". "Playground" is used in a few products, referring to an API sandbox.

I still think "Wikimedia API" is the clearest label to attract the kind of developers, researchers and other curious minds we want to target. The fact that some of that curiousity will be satisfied with data sets instead of APIs sounds secondary to me. What is important is that the label is clear and will attract the right people.

jaredzimmerman wrote on 2014-08-19 18:52:04 (UTC)

Hi all (and hi Phabricator) putting my marketing hat on I want to provide some feedback on some of the proposals

Wikimedia Developer Hub

  • my main issue with this is if you read it, it sounds like a "hub for mediawiki developers" which to me makes it feel exclusive (in a bad way) and that if you are not a mediawiki developer this place is not for you, this is explicitly what we do not want

Wikimedia Data & Developer Hub

  • This doesn't suffer from the above problem because of the way it breaks up the words, but still sounds a bit too technical and it is long, Quim you're point about it being the only google result I think is a positive, not a negative, however, it only works if someone remembers all 4 works and types them in, otherwise we get lost in the results. Its descriptive, bland, and boring, but you know what you're getting.

verb.wikimedia.org

  • I love this, it brings the spirit of what we're trying to do, it is inclusive, and it is actionable, sure its a bit more vague than the others but it leaves things open for interpretation and creation, the things we're trying to foster with this project. I think Play is good, but we could also think about Build, Make, Create, Invent or any other single short verb. we can always call it Play:Wikimedia Data & Developer Hub on the actual landing page to manage confusion but the name should inspire people to want to come, explore, and make things, I think only one of the proposed names accomplishes that right now.

msyed wrote on 2014-08-19 18:57:22 (UTC)

This is good, I think we're all building some consensus around the "verb.wikimedia.org" idea.

qgil wrote on 2014-08-20 09:31:04 (UTC)

No comments about "Wikimedia API" and api.wikimedia.org?

"verb.wikimedia.org" is only actionable when you propose an actual verb. :) Build, Make, Create, Invent may work when they are used next to technology brands/products/services, but I fear we might miss the shot when using them next to Wikimedia, which simplifying a lot is seen as "an encyclopedia".

Build, Make, Create, Invent + "an encyclopedia" is not the message we want to send. API + "an encyclopedia" makes the right call to the right target.

Maybe the API option sounds kind of boring to you, but it is good to remember that most of the sites you have been showcasing as good examples are named as "API" or "Developers". I'd rather bet on clarity and discoverability, especially considering the Wikimedia-Wikipedia-MediaWiki confusion, and the gazilion pages, projects, and programs we have, many of them featuring own creative names like GLAM, Teahouse, Meta, Wikitech, etc.

msyed wrote on 2014-08-20 18:56:02 (UTC)

My concern with api.wikimedia.org is that it sounds technical and actively works against one of the project goals which is to make an inclusive and inviting place for people to build and experiment with Wikimedia APIs & data.

I think we have two options:

  1. Have an open-ended name like play.wikimedia.org, which gives us the opportunity to keep this project a bit loosely defined and we can keep the project inclusive and experimental at its core. It also feels a lot more inviting than any of the more technical sounding names.
  1. Have a name that is a lot more explicit like Wikimedia Data & Developer Hub, have the domain be dev.wikimedia.org. This was my initial proposal, this name covers both the Data and Developer parts of the project.

I'm happy with either of these two options.

qgil wrote on 2014-08-21 10:24:05 (UTC)

Mmm well, ok, I don't see why someone willing to play with and API or ready to process huge datasets should be scared by the term "API", but we really need to settle this and other discussions in order to do some actual progress.

Let me double-check that "play.wikimedia.org" and "Play" are good from an Engineering & Comms point of view. An updated mockup for the home showing how this would look like is welcome.

qgil wrote on 2014-08-25 11:55:24 (UTC)

"play.wikimedia.org" was seen as unnecessarily too close to Google Play, a brand that is receiving a heavy investment. I agree, we don't need to get there having other verbs around.

@Mysed and I are happy with "build.wikimedia.org" aka "Build". Agreed & resolving.

Just for future readers:

In T309#3706, @Qgil wrote on 2014-08-25 11:55:24 (UTC)

"play.wikimedia.org" was seen as unnecessarily too close to Google Play, a brand that is receiving a heavy investment. I agree, we don't need to get there having other verbs around.

@Mysed and I are happy with "build.wikimedia.org" aka "Build". Agreed & resolving.

Back in August this was discussed further, and the actual conclusion was

In T313#3759, @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

dev.wikimedia.org as URL, since this was the original proposal and it works for the rest of us. This solves T311: URL of the Developer Hub for good.

The exact name is less important right now. "dev.wikimedia.org" 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.

So "dev.wikimedia.org" is the best candidate for a name we have got, until a better alternative wins.

Copying discussion from T92941:

Proposal: Technically inclined community members seeking to contribute to improve the editing experience for themselves or their communities
(Or am I mistaking the intended purpose dev.wikimedia.org?)

Yes, but you're not alone :-)
(...)
(I want to scrap the term "dev.wikimedia.org" because it encourages people to project whatever they want onto it.)

(It has been the same for whatever other combination we have tried before, so unless you find a magical string, I would just keep insisting on "dev.wikimedia.org".

Here's hoping that we can eventually find a better term. I'm aware of the past unfruitful discussions (though not of their entire contents), but still feel uneasy that the term "dev" is being used to mean something different than what I believe is its immediate association. Out of the top of my head, has something like devdata.wikimedia.org or data-apis.wikimedia.org been considered? If not, would they make sense? I'm not suggesting we change things at this point, just trying to see if we are aligned at the same page in our understanding of this project's aim.