Wikimedia Technology/Annual Plans/FY2019/CDP2: Platform Evolution
See also CDP2ː Platform Evolution
Program outline
[edit]Teams contributing to the program
[edit]Audiences Design, Documentation, MediaWiki Platform, Parsing, Performance, Readers Web, Services, WMDE
Annual Plan priorities
[edit]Knowledge as a Service/Foundational Strength: Evolve our systems and structures
Program Goal
[edit]Empower the Wikimedia Foundation to accomplish its goals of Knowledge Equity and Knowledge as a Service by evolving and investing in our technology stack to improve its flexibility, maintainability, and sustainability
Outcome 1
[edit]- Engineers have a clear understanding of our technology stack and the plan to better scale, maintain and test it
Outcome 2
[edit]- Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs
Outcome 3
[edit]- Engineers better understand our current architecture and coding standards and where to find them
CDP Budget Segment 1
[edit]- Team: Audiences Design
Outcome 2
[edit]- Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs
Output 2.8
- Improved OOUI Library
Outcome 3
- Engineers better understand our current architecture and coding standards and where to find them
Output 3.4
- Wikimedia Style Guide Version 2
CDP Budget Segment 2
[edit]- Team: Documentation
Outcome 3
[edit]- Engineers better understand our current architecture and coding standards and where to find them
Output 3.1
- Wikimedia developer documentation portal
Output 3.2
- Architecture pages on developer portal
Output 3.3
- Coding standards pages on developer portal
CDP Budget Segment 3
[edit]- Team: MediaWiki Platform
Outcome 1
[edit]- Engineers have a clear understanding of our technology stack and the plan to better scale, maintain and test it
Output 1.2
- MediaWiki REST API Design
Outcome 2
[edit]- Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs
Output 2.1
- MediaWiki REST API Infrastructure
CDP Budget Segment 4
[edit]- Team: Parsing
Outcome 1
[edit]- Engineers have a clear understanding of our technology stack and the plan to better scale, maintain and test it
Output 1.3
- Parser Unification Plan
Outcome 2
[edit]- Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs
Output 2.5
- Initiation of Parser Unification
CDP Budget Segment 5
[edit]- Team: Performance
Outcome 2
[edit]- Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs
Output 2.4
- Personalized and non-personalized content can be assembled into a page outside of the MediaWiki application
CDP Budget Segment 6
[edit]- Team: Readers Web
Outcome 2
[edit]- Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs
Output 2.7
- Refactor presentation layer away from business logic code in MediaWiki
CDP Budget Segment 7
[edit]- Team: Services
Outcome 2
[edit]- Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs
Output 2.2
- Modularized RESTBase
Output 2.3
- Session Management system
CDP Budget Segment 8
[edit]- Team: WMDE (Daniel)
Outcome 1
[edit]- Engineers have a clear understanding of our technology stack and the plan to better scale, maintain and test it
Output 1.1
- Architecture Spec for the WMF technology stack
Outcome 2
- Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs
Output 2.6
- TBD Refactoring Output (Scope pending architecture - potentially: Use Service Container throughout MediaWiki core)
Targets
[edit]Outcome 1
[edit]- Engineers have a clear understanding of our technology stack and the plan to better scale, maintain and test it
- Target
WMF Staff and volunteers can view and understand the current architecture, proposed architecture, implementation plan as well as the parser unification plan
- Measurement method
Ensure the architecture and plan documents exists, are publicly accessible, and are announced on public communication channels
Outcome 1
[edit]- Engineers have a clear understanding of our technology stack and the plan to better scale, maintain and test it
- Target
Engineers can confidently port specific individual components of Parsoid and verify its correctness and performance without requiring a full port to be ready
- Measurement method
Ensure that token transformers and DOM passes have unit tests and a unit testing framework with suitable mocks
Outcome 2
[edit]- Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs
- Target
Engineers can implement a REST API in MediaWiki using our routing infrastructure
- Measurement method
Engineers develop or convert at least one service to REST in MediaWiki
Outcome 3
[edit]- Engineers better understand our current architecture and coding standards and where to find them
- Target
Engineers can view the WMF production architecture, the exposed APIs and the coding standards in a centralized documentation portal
- Measurement method
Ensure this portal exists [cf. https://doc.wikimedia.org/], is accessible by engineers inside and outside the organization, and is announced on public communication channels
Resources
[edit]Staffing | FY2017–18 | FY2018–19 |
---|---|---|
MediaWiki Platform |
|
|
Services |
|
|
Performance |
|
|
Parsing |
|
|
Reading Infrastructure |
|
|
Readers Web |
|
|
Technical Collaboration |
|
|
CapEx | ||
| ||
Travel and Other | ||
|