Task Table

From atwg
Revision as of 08:41, 10 February 2018 by Ccicalese (talk | contribs)
 TypeAssociated OutputsPrimary TeamCollaborating TeamsStart YearDurationDepends On TasksRisksContingenciesBenefitsAssumptionsImplicationsNotes
Make REST Routing possible in MediaWikiDevelopmentMediaWiki Platform06Routing 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 supportResearchAudiences Product and Design0
Design MediaWiki REST APIMediaWiki Platform06Should 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 APIDevelopmentMediaWiki Platform
Research Desktop Workflows to port to Mobile and/or Responsive (ARCHIVED)ResearchReaders Web06CSA: Added "re-evaluate technology tradeoffs"; perhaps split into a separate first-year research goal?
Port Desktop Workflows to Mobile and/or Responsive (ARCHIVED)DevelopmentReaders Web018
Research architecture requirements and needs, identify and resolve trade-offsResearchMediaWiki Platform03
Write Architecture SpecDocumentationMediaWiki Platform0
Refactor MediaWiki Core into well encapsulated components, removing global state and circular dependencies between classesDevelopmentMediaWiki Platform0Primary candidates are those where LAMP stack needs are vastly different than WMF scaling needs such as: Storage and Event Propagation
Prototype page assemblyPrototypingPerformance0
Simplify the RESTBase stackDevelopmentServices03
Create a multi-purpose key/value storage componentServices13
Isolate session data by creating a specialised session serviceServices03
Refactor Parsoid to support portingDevelopmentParsing03This 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 ParsoidDevelopmentParsing03
Standardize on a single parserDevelopmentParsing012
Research 3rd party installations, uses, and contributions (ARCHIVED)ResearchMediaWiki Platform03Virtualization/Containerization/Cloud/Shared/Bare metal?
Define the default MediaWiki installation (ARCHIVED)ResearchMediaWiki Platform03These 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)DevelopmentRelEng6I 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)DevelopmentOps0
Develop page assembly capabilityDevelopmentPerformance
Create a purpose built developer portal for documentationDevelopmentDocumentation0
Document MediaWiki PHP service interface on portalDocumentationDocumentation
Document MediaWiki REST API on portalDocumentationDocumentation
Document system architecture, lifecycles, etc. on developer portalDocumentationDocumentation0
Develop, publish and implement Code Standards that align with our new priorities around APIs, encapsulation and global stateDocumentationDocumentation00