Page MenuHomePhabricator

Set up dev.wikimedia.org portal
Closed, DeclinedPublic

Description

There's a few (not too many!) things that need a home, and I think this is a good time to start work on what will become the main entry point for developers to learn about Wikimedia (wiki) projects and Wikimedia (software) products.

developer.wikimedia.org

The initial portal wouldn't be unlike some of these:

Here's are some very specific use cases that have come up during the Zurich Hackathon that I think would be best served with this:

  • Where do I find out about the existence of:
    • gdash.wikimedia.org
    • graphite.wikimedia.org
    • noc.wikimedia.org
    • doc.wikimedia.org
    • git.wikimedia.org
    • wikitech.wikimedia.org
    • irc.wikimedia.org ( * stream.wikimedia.org/rc )

      Current solution: None

      Current workaround for regulars: https://wikitech.wikimedia.org/wiki/Category:Services

I'm sure the people from the "Data API & Hub" table from Zurich Hackathon 2014 have more specific stories and use cases.

This hub would act as delegate for the following cases (pointing to things on another domain or the same, some of which should probably move to it eventually):

  • Products Such as:
    • MediaWiki -> Homepage -> Source code (git repo) -> Documentation (separate portal, on mediawiki.org for now, ultimately linking back to developer.wikimedia.org/mediawiki/{js,php,api} for documentation of individual classes and apis. We already have JS and PHP docs autogenerated for MediaWiki. Docs the API are still hardcoded on mediawiki.org and api.php/help exclusively, we should get API and Hooks documentation onto doc.wikimedia.org as well. See https://www.mediawiki.org/wiki/Requests_for_comment/Documentation_overhaul
    • VisualEditor -> Source code -> Demo(s) -> Documentation
  • Data and APIs (APIs that are not related to MediaWiki or individual user-facing products, but Wikimedia services in general, MediaWiki's API is one small part of that)

    Such as:
    • page view counts
    • xml dumps
    • OAuth?
    • irc.wikimedia.org ( * stream.wikimedia.org/rc )
    • "See also: Wikidata"
  • Communications
    • (e.g. link to tech blog, as currently linked from noc.wikimedia.org)
    • mailing lists

Version: wmf-deployment
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=29936

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:12 AM
bzimport set Reference to bz65074.
bzimport added a subscriber: Unknown Object (MLST).

I think all of doc.wikimedia.org can migrate to appropriate paths on this domain.

Like:

  • dev.wikimedia.org/mediawiki/doc/js
  • dev.wikimedia.org/mediawiki/doc/php
  • dev.wikimedia.org/mediawiki/doc/api
  • dev.wikimedia.org/visualeditor/doc
  • dev.wikimedia.org/visualeditor/demo
  • dev.wikimedia.org/oojs-ui/doc
  • dev.wikimedia.org/oojs-ui/demo
  • dev.wikimedia.org/oojs/doc

I'm in full support of this.

As someone working on this https://www.mediawiki.org/wiki/API_Documentation_&_Developer_Hub, I would like this very much.

Initial implementation proposal:

  • static html wrapped in a lightweight php router for header/footer and nice url handling (e.g. no need to repeat too much for each subdirectory, it can be handled automatically using data and available directories (js,php,api,demo) and versions (master,REL1_23,etc.)), using twitter bootstrap (like doc.wikimedia.org)
  • all in git (wikimedia/dev-docroot.git?)
  • deployed via git-deploy

The server for it only needs to be behind misc-lb-eqiad and be a git-deploy target. The main changes would come in from people via gerrit/git and deployed periodically.

Changes to the auto-generated docs would be build by gallium, and somehow pushed to the web server (they wouldn't be in dev-docroot.git).

Topic related with a session scheduled for tomorrow at 10:30 in the Wikimedia Hackathon:

How does the data and developer hub fit into the current documentation
https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Schedule#Saturday_May_10

(In reply to Krinkle from comment #0)

  • Data and APIs

    Such as:
    • page view counts
    • xml dumps
    • OAuth?

Discovered today that there is such a thing as https://frdata.wikimedia.org
as well. To be documented at https://wikitech.wikimedia.org/wiki/frdata.wikimedia.org.

Why not just have dev.wikimedia.org redirect to a page on mediawiki.org. That way people can update it as appropriate easily.

  • Where do I find out about the existence of:

[..]

  • graphite.wikimedia.org

Not much point telling people about the existence of a service they are not allowed access to.

Let's merge this discussion with the work done at https://www.mediawiki.org/wiki/dev.wikimedia.org. Sorry for the duplicity of spaces, which will go away when we merge Bugzilla with Phabricator.

We have settled on http://dev.wikimedia.org -- see

Name for the 'developer hub'
http://fab.wmflabs.org/T488

and

URL of the Developer Hub
http://fab.wmflabs.org/T490

(In reply to Bawolff (Brian Wolff) from comment #6)

Why not just have dev.wikimedia.org redirect to a page on mediawiki.org.
That way people can update it as appropriate easily.

Yes, this is the current plan that you can help fine tuning:

Technology selection for the Developer Hub
http://fab.wmflabs.org/T491

How to redirect from dev.wikimedia.org
http://fab.wmflabs.org/T558

sumanah wrote:

Removing myself from cc on this as I prepare to leave Wikimedia Foundation.

Change 181398 had a related patch set uploaded (by Qgil):
add dev.wikimedia.org

https://gerrit.wikimedia.org/r/181398

Patch-For-Review

Qgil mentioned this in Unknown Object (Diffusion Commit).Jan 14 2015, 4:52 PM

needs Apache config, then obviously some files to upload..

Qgil lowered the priority of this task from Medium to Low.Feb 4 2015, 8:50 AM

We have decided to prioritize the creation of some actual content under the existing API: namespace in mediawiki.org.

We have decided to prioritize the creation of some actual content under the existing API: namespace in mediawiki.org.

Yes, content, then a portal page on mw.org featuring that content based on wireframe ideas. Once it's at "better than draft" status, dev.wikimedia.org can have a redirect to this, and doc.wikimedia.org can link to it.

Change 195338 had a related patch set uploaded (by Chmarkine):
Enable HSTS on dev.wm.org max-age=7 days

https://gerrit.wikimedia.org/r/195338

Change 195338 merged by BBlack:
Enable HSTS on dev.wm.org max-age=7 days

https://gerrit.wikimedia.org/r/195338

Change 197272 had a related patch set uploaded (by Chmarkine):
dev.wm.org - Increase HSTS max-age to 1 year

https://gerrit.wikimedia.org/r/197272

Change 197272 merged by BBlack:
dev.wm.org - Increase HSTS max-age to 1 year

https://gerrit.wikimedia.org/r/197272

#Engineering-Community with the help of @Spage are committing to this goal for the next quarter: T101441: Goal: Integrate the new Web APIs hub with mediawiki.org.

I think it is time to conciliate that goal with this task, and to find the best relationship with both that we can achieve by the end of September.

I have detached this proposal from T101441: Goal: Integrate the new Web APIs hub with mediawiki.org and Web-APIs-Hub because the latter has defined its scope within web APIs only (which happens to be the scope of the Google, Facebook, Twitter examples given above).

Being Wikimedia also the umbrella of hundreds of open source projects, we have a more complex picture. What should be the one and only home to find about all of them? In short, my opinion is to make http://mediawiki.org that home, linking wherever it is needed.

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

please also see T246945 which might conflict with this effort and introduce yet another place for documentation rather than having a single place for developers to go to

Aklapper claimed this task.

This task has been lingering for five years.
The domain mentioned in the summary has existed for years (resolved).
However, the content/workflow/thoughts in the task description do not (not resolved).

I'm boldly decline this (very Epic broad) task in favor of the Wikimedia-Developer-Portal project which allows a better breakdown of subtasks.
See https://www.mediawiki.org/wiki/Developer_Advocacy/Developer_Portal for more info (still going to take me 2-3 more weeks to sort out the very basics though - patience please!)