Three APIs will be featured at the Developer Hub prototype through its Inspire, Explore, and Build sections. These APIs must be selected considering factors like
| Reference | Source Branch | Dest Branch | Author | Title | |
|---|---|---|---|---|---|
| repos/sre/miscweb/research-landing-page!15 | replace-jelto-readme | master | jelto | replace reviewer jelto with wmf-sre-collab group | |
| repos/sre/miscweb/bugzilla!1 | add-ci | main | jelto | add .gitlab-ci.yml | |
| repos/releng/gitlab-trusted-runner!42 | add-bugzilla | main | jelto | add /repos/sre/miscweb/bugzilla to Trusted Runners | |
| repos/sre/miscweb/annualreport!5 | use-timestamp-tags | master | jelto | use timestamp in image tag | |
| repos/sre/miscweb/bienvenida!2 | use-timestamp-tags | master | jelto | use timestamp in image tag | |
| repos/sre/miscweb/transparencyreport!2 | use-timestamp-tags | master | jelto | use timestamp in image tag | |
| repos/abstract-wiki/wikifunctions/function-orchestrator!24 | apine-mock-utils | main | apine | Increase test coverage for utils.js. Also fix a couple of bugs: | |
| repos/releng/gitlab-trusted-runner!22 | add-miscweb-annualreport | main | jelto | allow annualreport on trusted runners | |
| repos/sre/miscweb/annualreport!2 | ci-image-build | master | jelto | Add Ci image build and publish | |
| repos/sre/miscweb/annualreport!1 | blubber-build | master | jelto | add blubber image build for annual report sites |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Spage | T307 Announcing the Developer Hub prototype release | |||
| Resolved | • Spage | T299 Release the Developer Hub prototype | |||
| Resolved | • Spage | T306 Featuring the first three APIs in the Developer Hub | |||
| Declined | None | T302 API sandboxes for the Developer Hub | |||
| Resolved | None | T300 Select the three APIs featured at the Developer Hub prototype | |||
| Declined | None | T88755 Improve MediaWiki API example behavior | |||
| Resolved | Anomie | T89229 API Help should generate [try in ApiSandbox] link to Special:ApiSandbox#action=params from getExamples() | |||
| Declined | None | T89318 Replace on-wiki API documentation with Special:ApiHelp transclusion | |||
| Open | None | T89768 Language support in Special:ApiHelp and its transclusion. | |||
| Open | None | T90528 Generated API Help doesn't indicate the MediaWiki versions that support a module and parameters. | |||
| Resolved | • Spage | T89680 Template:ApiEx on mw.org should have a link to "[view in ApiSandbox]". |
qgil wrote on 2014-07-22 16:00:34 (UTC)
I'm wondering whether GSoC - OPW - GCi - FOA and v outreach programs we do in the future could be in the picture as part of the "new contributors". Are there specific APIs that are more used / needed / interesting for these developers?
eloquence wrote on 2014-07-27 18:59:00 (UTC)
I want to second RCStream as a candidate. Visualizing/tracking/analyzing changes in our projects is one of the key third party uses, and having a clear, well-understood API for this purpose is really important. We'll get lots of interest and real world feedback if we do this one right.
brainwane wrote on 2014-08-04 20:33:18 (UTC)
I talked with Brad, developers and managers from several teams, and thought about it. I have decided to focus on
Longer version:
Since Erik, Ori, and a few other people have especially requested that I cover the Content and the RCStream APIs, it looked pretty clear that those should be #1 and #2. The question for me was: which part of the MediaWiki API should I improve as the third area to cover in the next couple months?
(Many of the APIs at https://www.mediawiki.org/wiki/Data_%26_Developer_Hub#Existing_APIs are parts of the MediaWiki API at api.php (albeit sometimes only with particular extensions turned on). Echo, Flow, Upload, Commons, GeoData, Mobile, Wikidata, and Account Creation are accessible that way, I believe. The APIs in that list that are not part of the api.php route are Parsoid, Content, and RCStream.)
Lydia had mentioned to me earlier her interest in substantially improving the Wikidata API docs, and there's already a community of tool/bot writers who would benefit from better documentation. Also, as we work on multimedia, it's important that we move towards putting the metadata around media files into some kind of structured data format, and it seems possible that it would go into Wikidata someday. I anticipate that there will be a lot of work in migrating from wikitext to structured data for multimedia stuff, and that this migration will have to include bot writers and other members of the larger Wikimedia community. Good documentation will enable bot writers, user script writers, and others to try out new combinations and solutions.