Output:1.2: Difference between revisions
From atwg
No edit summary |
m (Ccicalese moved page Output:003 to Output 1.2 without leaving a redirect) |
||
(One intermediate revision by the same user not shown) | |||
Line 2: | Line 2: | ||
|Description=modularized MediaWiki | |Description=modularized MediaWiki | ||
|Parent Outcome=Outcome:1 | |Parent Outcome=Outcome:1 | ||
| | |Primary Team=MediaWiki Platform | ||
|Collaborating Teams=WMDE, Parsing, TechCom, Reading Infrastructure, Readers Web | |||
|Archived=No | |Archived=No | ||
}} | }} |
Latest revision as of 08:46, 20 February 2018
Output | modularized MediaWiki |
---|---|
Parent Outcome | Infrastructure for Wikimedia projects can be more easily scaled due to increased modularization, re-use, maintainability, and testability of the technology stack |
Primary Team | MediaWiki Platform |
Collaborating Teams | WMDE, Parsing, TechCom, Reading Infrastructure, Readers Web |
Task | Description | Depends On Tasks | Type | Associated Outputs | Primary Team | Collaborating Teams | Start Year | Duration | Risks | Contingencies | Benefits | Assumptions | Implications | Notes |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Refactor MediaWiki Core into well encapsulated components, removing global state and circular dependencies between classes | Incrementallly refactor MediaWiki code into logical classes/components/libraries to isolate functions such as storage, parser, events and app logic. Prioritizing refactoring of code into components to allow: Easier testing (leading to faster development), more easily support both LAMP stack and WMF use cases that require scale and selective SOA, increased re-usability, enabling an API-first approach be de-coupeling the presentation layer. Removing global state also enabled full cross-wiki capability (e.g. loading and rendering content from multiple wikis in a single request). | Write Architecture Spec | Development | Output 1.2 | MediaWiki Platform | WMDE, Parsing, TechCom, Reading Infrastructure, Readers Web | 0 | Primary candidates are those where LAMP stack needs are vastly different than WMF scaling needs such as: Storage and Event Propagation |