Property:Description
From atwg
0
Document internal PHP service interrface along with responses, specs, examples and prose explaining use cases and workflows +
Document REST API along with responses, specs, examples and prose explaining use cases and workflows +
Document "mid-level" items that explain how our systems work. This provides an overview of systems and architecture with diagrams and workflows along with links to low level documentation +
Develop, publish and implement Code Standards that align with our new priorities around APIs, encapsulation and global state +
Develop and implement coding standards that inform and enforce 1. better encapsulation with the creation of public PHP APIs and REST APIs to expose functionality 2. the use of the Service Container. 3. librarization for components that are likely to be extracted to services for scaling needs of the WMF +
We need a coherent, understandable set of documented APIs for our own projects and 3rd party API consumers (an example: https://developer.github.com ) +
We need a generic storage for long term storage of content other than article renders (feed content, edits-in-process, collaborative sessions, translations, annotations, conflict resolution, media, archival renders of pages, etc) +
We have duplicated functionality in core and in services (ex: title handling code, parser tests syncing, some parts of lang. variant support) +
Configuration complexity: Installation and deployment of mediawiki + services requires a lot of different configuration files to be managed (sometimes with duplication, ex: sitematrix code in parsoid and in core) +
Healthy extension ecosystem has the unfortunate side-effect that few third-parties are actually running "mediawiki as WMF uses it", and lots of valuable functionality is hidden in overlooked extensions +
Lack of clarity around what functionality and features are specific to the wikimedia usage and what is generic for all mediawiki users +
Code modularity (good) gets confused with "optional features" or even "unmaintained community features", since the same mechanisms are used (ie, pushback against unbundling the parser "for greater modularity" since "it's not an optional feature") +
We need to agree on what constitutes the MediaWiki core platform and if there are additional optional bundles of important functionality +
The third-party community needs to be involved in the development of installation/deployment strategies targeting their environments to be sure that solutions fit the problem +
We need a better contract/set of expectations w/ third-party community, so we have a coherent lifecycle from "started by third-party" -> "adopted by WMF" -> "deprecated by WMF" -> "maintained by third-party" -> end-of-life (cf Semantic MediaWiki, PDF export, etc) +
It should be possible to support page composition at the network edge without requiring that ordinary page design changes require source code edits across a service/language boundary +
Third party community keeps asking for composer for extensions deployment; we should agree on a mechanism that meets their needs but does not bring composer's issues re: extension management +
