Task Table
From atwg
| Type | Associated Outputs | Primary Team | Collaborating Teams | Start Year | Duration | Depends On Tasks | Risks | Contingencies | Benefits | Assumptions | Implications | Notes | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Make REST Routing possible in MediaWiki | Development | Output 2.1 | MediaWiki Platform | Services,Reading Infrastructure | 0 | 6 | Write Architecture Spec | Routing for external services should be handled outside of MediaWiki (Varnish). The MW routing should be done using a service runner that can be run separately from MW for WMF use, but could be run in the same process for small installs. Where a service lives, node, MW, or elsewhere should be transparent to clients. We should then figure out any necessary routing, mapping, proxying, etc without the clients needing to worry about this. This means we have an agreed upon REST url pattern that spans all services and routers. For MW APIs, thsse should be routed from Varnish to MW via some sort of configuration. | |||||
| Identify features that the REST API needs to support | Research | Output 2.1 | Audiences Product and Design | Readers Web,Reading Infrastructure,Services,MediaWiki Platform | 0 | ||||||||
| Design MediaWiki REST API | Output 2.1 | MediaWiki Platform | Services,Reading Infrastructure | 0 | 6 | Identify features that the REST API needs to support,Refactor MediaWiki Core into well encapsulated components, removing global state and circular dependencies between classes | Should be designed by a group consisting of members from the MW Platform team, Services, Readers and Contributors. This ensures that those who know the MW platform best, those who have experience designing REST services, and those who implement the clients all agree on the design | ||||||
| Develop MediaWiki REST API | Development | Output 2.1 | MediaWiki Platform | Services,Reading Infrastructure | Make REST Routing possible in MediaWiki,Design MediaWiki REST API | ||||||||
| Research Desktop Workflows to port to Mobile and/or Responsive (ARCHIVED) | Research | Output 2.3 (ARCHIVED) | Readers Web | Audiences Design,Reading Infrastructure | 0 | 6 | Write Architecture Spec | CSA: Added "re-evaluate technology tradeoffs"; perhaps split into a separate first-year research goal? | |||||
| Port Desktop Workflows to Mobile and/or Responsive (ARCHIVED) | Development | Output 2.3 (ARCHIVED) | Readers Web | Audiences Design | 0 | 18 | Research Desktop Workflows to port to Mobile and/or Responsive (ARCHIVED) | ||||||
| Research architecture requirements and needs, identify and resolve trade-offs | Research | Output 1.1 | MediaWiki Platform | Services,TechCom,WMDE,Reading Infrastructure,Performance,Parsing | 0 | 3 | |||||||
| Write Architecture Spec | Documentation | Output 1.1 | MediaWiki Platform | TechCom,WMDE | 0 | Research architecture requirements and needs, identify and resolve trade-offs | |||||||
| Refactor MediaWiki Core into well encapsulated components, removing global state and circular dependencies between classes | Development | Output 1.2 | MediaWiki Platform | WMDE,Parsing,TechCom,Reading Infrastructure,Readers Web | 0 | Write Architecture Spec | Primary candidates are those where LAMP stack needs are vastly different than WMF scaling needs such as: Storage and Event Propagation | ||||||
| Prototype page assembly | Prototyping | Output 2.2 | Performance | 0 | Write Architecture Spec | ||||||||
| Simplify the RESTBase stack | Development | Output 1.3 | Services | 0 | 3 | ||||||||
| Create a multi-purpose key/value storage component | Output 1.3 | Services | 1 | 3 | Simplify the RESTBase stack | ||||||||
| Isolate session data by creating a specialised session service | Output 1.3 | Services | MediaWiki Platform | 0 | 3 | Create a multi-purpose key/value storage component | |||||||
| Refactor Parsoid to support porting | Development | Output 1.4 | Parsing | 0 | 3 | This step is useful for improved maintenance, readability of the Parsoid codebase independent of the port. It also reduces the time spent doing the actual port. | The code cleanup and refactoring doesn't need to depend on the architecture document. | ||||||
| Prototype and test PHP implementation of Parsoid | Development | Output 1.4 | Parsing | MediaWiki Platform | 0 | 3 | Refactor Parsoid to support porting | ||||||
| Standardize on a single parser | Development | Output 1.4 | Parsing | MediaWiki Platform | 0 | 12 | Create a multi-purpose key/value storage component,Prototype and test PHP implementation of Parsoid,Write Architecture Spec | ||||||
| Research 3rd party installations, uses, and contributions (ARCHIVED) | Research | Output 5.3 (ARCHIVED) | MediaWiki Platform | Reading Infrastructure (Gergo) | 0 | 3 | Virtualization/Containerization/Cloud/Shared/Bare metal? | ||||||
| Define the default MediaWiki installation (ARCHIVED) | Research | Output 5.1 (ARCHIVED) | MediaWiki Platform | 0 | 3 | These goals need to better stress "increase commonality between WMF and 3rd party installs", rather than treating 3rd party installs as a separate configuration target | |||||||
| Improve installation of default MediaWiki for WMF development, testing and production environments as well as 3rd parties (ARCHIVED) | Development | Output 5.1 (ARCHIVED) | RelEng | Bryan Davis,MediaWiki Platform | 6 | Research 3rd party installations, uses, and contributions (ARCHIVED),Define the default MediaWiki installation (ARCHIVED) | I don't think we have full consensus on single-process LAMP vs node js helpers etc. | ||||||
| Improve installation and deployments of the "WMF Technology stack" for WMF development testing and production environments (ARCHIVED) | Development | Output 5.2 (ARCHIVED) | Ops | Services,RelEng | 0 | ||||||||
| Develop page assembly capability | Development | Output 2.2 | Performance | Traffic | |||||||||
| Create a purpose built developer portal for documentation | Development | Output 3.1 | Documentation | Audiences Design,Services,Reading Infrastructure,MediaWiki Platform,Technical Collaboration,Wikimedia Cloud Services | 0 | ||||||||
| Document MediaWiki PHP service interface on portal | Documentation | Output 3.4 | Documentation | WMDE,MediaWiki Platform | Refactor MediaWiki Core into well encapsulated components, removing global state and circular dependencies between classes,Create a purpose built developer portal for documentation | ||||||||
| Document MediaWiki REST API on portal | Documentation | Output 3.4 | Documentation | Services,MediaWiki Platform | Develop MediaWiki REST API,Create a purpose built developer portal for documentation | ||||||||
| Document system architecture, lifecycles, etc. on developer portal | Documentation | Output 3.2 | Documentation | WMDE,MediaWiki Platform | 0 | Create a purpose built developer portal for documentation,Write Architecture Spec | |||||||
| Develop, publish and implement Code Standards that align with our new priorities around APIs, encapsulation and global state | Documentation | Output 3.3 | Documentation | MediaWiki Platform,TechCom | 0 | 0 | Create a purpose built developer portal for documentation |
