FY18-19 Plan: Platform Evolution CDP

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Program Manager:	Corey Floyd
Product Manager:	Cindy Cicalese
Executive Sponsor:	Victoria Coleman

Goals and Outcomes

Annual Plan Goals:	Knowledge as a Service/Foundational Strength: Evolve our systems and structures
Program Goal:	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
Outcomes:	Outcome 1: Engineers have a clear understanding of our technology stack and the plan to better scale, maintain and test it Outcome 2: Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs Outcome 3: Engineers better understand our current architecture and coding standards and where to find them

Targets

Outcome	Target Description	Measurement Method
Outcome 1: Engineers have a clear understanding of our technology stack and the plan to better scale, maintain and test it	Engineers can confidently port specific individual components of Parsoid and verity its correctness and performance without requiring a full port to be ready	Ensure that token transformers and DOM passes have unit tests and a unit testing framework with suitable mocks
Outcome 1: Engineers have a clear understanding of our technology stack and the plan to better scale, maintain and test it	WMF Staff and volunteers can view and understand the current architecture, proposed architecture, implementation plan as well as the parser unification plan	Ensure the architecture and plan documents exists, are publicly accessible, and are announced on public communication channels
Outcome 2: Engineers are able to access more functionality of the stack using well encapsulated components and well defined APIs	Engineers can implement a REST API in MediaWiki using our routing infrastructure	Engineers develop or convert at least one service to REST in MediaWiki
Outcome 3: Engineers better understand our current architecture and coding standards and where to find them	Engineers can view the WMF production architecture, the exposed APIs and the coding standards in a centralized documentation portal	Ensure this portal exists, is accessible by engineers inside and outside the organization, and is announced on public communication channels

Budget Segments

Team:	Audiences Design
Outcomes:	Outcome 2: 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

Team:	Documentation
Outcomes:	Outcome 3: 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

Team:	MediaWiki Platform
Outcomes:	Outcome 1: 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: 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

Team:	Parsing
Outcomes:	Outcome 1: 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: 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

Team:	Performance
Outcomes:	Outcome 2: 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

Team:	Readers Web
Outcomes:	Outcome 2: 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

Team:	Services
Outcomes:	Outcome 2: 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

Team:	WMDE (Daniel)
Outcomes:	Outcome 1: 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)

Full Plan

Outcome	Output	Primary Team	Collaborating Teams
Outcome 1: 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	WMDE (Daniel)	TechCom MediaWiki Platform Services Performance Parsing Reading Infrastructure
	Output 1.2: MediaWiki REST API Design	MediaWiki Platform	Services Readers Web Reading Infrastructure Audiences Design Audiences Product
	Output 1.3: Parser Unification Plan	Parsing	MediaWiki Platform
Outcome 2: 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	MediaWiki Platform	Services Readers Web Reading Infrastructure Audiences Design Audiences Product
	Output 2.2: Modularized RESTBase	Services	MediaWiki Platform
	Output 2.3: Session Management system	Services
	Output 2.4: Personalized and non-personalized content can be assembled into a page outside of the MediaWiki application	Performance	Traffic
	Output 2.5: Initiation of Parser Unification	Parsing	MediaWiki Platform
	Output 2.6: TBD Refactoring Output (Scope pending architecture - potentially: Use Service Container throughout MediaWiki Core)	WMDE (Daniel)	TechCom WMDE MediaWiki Platform
	Output 2.7: Refactor presentation layer away from business logic code in MediaWiki	Readers Web	MediaWiki Platform Audiences Design Reading Infrastructure WMDE
	Output 2.8: Improved OOUI Library	Audiences Design	Readers Web
Outcome 3: Engineers better understand our current architecture and coding standards and where to find them	Output 3.1: Wikimedia developer documentation portal	Documentation	Technical Collaboration Audiences Design Services Reading Infrastructure MediaWiki Platform Wikimedia Cloud Services
	Output 3.2: Architecture pages on developer portal	Documentation	TechCom WMDE MediaWiki Platform
	Output 3.3: Coding standards pages on developer portal	Documentation	TechCom MediaWiki Platform WMDE
	Output 3.4: Wikimedia Style Guide Version 2	Audiences Design

Resources

Staffing	FY2017–18	FY2018–19
MediaWiki Platform	.33 ✕ Engineer	.33 ✕ Engineer Engineer (new hire) Engineer (new hire) Engineer (new hire) Product Manager (new hire) Technical writer (new hire) Technical writer (contract) Designer (contract) 0.5 ✕ Product Manager (reallocation (Cindy))
Services	Engineer 0.5 ✕ Engineer	Engineer Engineer (new hire) 0.5 ✕ Engineer
Performance	0.25 ✕ Engineer	0.25 ✕ Engineer (no change)
Parsing	Engineer Engineer 0.5 ✕ Engineer	Engineer (no change) Engineer (no change) 0.5 ✕ Engineer (no change)
Reading Infrastructure	Engineer Engineer	Engineer (no change) Engineer (no change)
Readers Web	Engineer 0.75 ✕ Engineer	Engineer (no change) 0.75 ✕ Engineer (no change)
Technical Collaboration	0.25 ✕ person	0.25 ✕ person (no change)
CapEx
		None
Travel and Other
		None