Platform Evolution/Goals

Since the Platform Evolution program began, the Program Team has been working on understanding the needs of platform stakeholders in order to define a roadmap for the future of the platform. The goals and outcomes below are the result of the work of speaking with many different stakeholders both inside and outside of the Wikimedia Foundation. We are currently in the process of validating and refining the goals and outcomes. In parallel to this work we are organizing projects identified at TechConf and by stakeholders that will help us achieve these outcomes. If you have any feedback or questions, please leave a note on the talk page. We hope to have these finalized during the first part of the midterm planning process at the WMF which ends in April 2019.

= Goals =


 * Define our products, users and use cases. Before making any technical decisions, we need to agree on who we are building our products for and what use cases these products should support. We must make important decisions in both of these areas in order to define our products.
 * Work better together, and establish clear roles and communication channels. Along with clarity of products, clarity of responsibilities and processes allow us to work effectively and direct resources responsibly. Complex communities and a complex technological ecosystem require coordination and cooperation to help us move forward together.
 * Enable our engineers, staff, and volunteers to achieve our goals easier and faster. Our technology and processes should make everyone’s work more efficient. This means clear documentation and investing in infrastructure that makes deployment of new features and big fixes easier for engineers. This also includes improvements for error reporting and logging in order fix problems quicker.
 * Architect our code, services and infrastructure for change and sustainability. Our platform has supported almost two decades’ worth of collaboration. Using best practices for software architecture and engineering we can extend it for new, as yet unknown challenges.
 * Increase our technical capabilities to achieve our strategy. The Wikimedia Foundation and the larger movement require our support to reach next-level goals. Adding new features will help reach them.

These goals can be written succinctly as: Clear plans and goals, improved processes, easier to develop, easier to grow, new capabilities.

= Outcomes supporting each goal = The outcomes below further refine the intention of each goal. Each outcome is written in a way which allows us to think of how we will measure our success in achieving our goals. By agreeing on measurable outcomes, we create a concrete shared understanding of our goals which enables us to prioritize our most important work.

Define our products, users and use cases

 * Increase clarity and organizational alignment around the users and use cases on which we focus our products. Our platform serves many different audiences, directly and indirectly. In order to make technology decisions about our platform, we need to understand the needs of the products it supports and have organizational alignment on the priorities of those products. This includes products for our contributors, end users as well as third party MediaWiki users.
 * Increase clarity and organizational alignment around which features are core to our platform. Our platform and community overlap in ways which make it hard to understand where the responsibilities of the WMF end and those of the community begin when it comes to delivering features and value to end users. Clarifying where we support end users directly and where we support them indirectly through empowering our communities will help us define what features are core to the platform.
 * Increase clarity and organizational alignment around the our technical priorities. Having an agreed upon priorities for our technology allows us to develop long term technical plans with organizational support. It also allows us to work more efficiently by focusing more resources on fewer, but more impactful priorities.
 * Increase clarity around our product and technical roadmaps. Our stakeholders need time to plan and prepare for changes to our platform. We need to develop, publish and update a roadmap for the platform that allows for those who depend on the platform to make longer term plans.

Work better together, and establish clear roles and communication channels

 * Increase clarity of the product development process. We want staff, teams, and stakeholders to understand how technology solutions are planned, researched, designed, developed and deployed. Teams and staff should have a shared understanding of responsibilities and how product and technology decisions are made. Communication channels should be minimized and obvious in order to reduce noise and distractions for staff and community members alike.
 * Increase inclusivity and transparency of the product development process. We also want to improve the process to make sure we clearly defined ways to include communities and non-management in the process. We should have clear feedback loops that encourage constructive participation when it is most useful. Everyone should understand when and how to participate.
 * Decrease time to deliver features and improvements throughout our product development process. We want to teams to work together together smarter and faster. By making improvements to the process while removing overhead, duplication and ambiguity, we can deliver value to our users efficiently.
 * Decrease the time it takes for us to identify, resource and solve emergent needs and issues. We want to plan for and recognize the emergent nature of our work and communities by having processes that allow for flexibility. We should be able to respond to needs that emerge outside of our planning cycles. Addressing an unplanned need should not cause chaos, but instead have clear predictable effects on our roadmaps.

Enable our engineers, staff, and volunteers to achieve our goals easier and faster

 * Increase understanding of platform and its capabilities. We intend to provide documentation that makes it easier to build on our platform. We will to incorporate comprehensibility of our platform in our architecture decisions, and streamline redundant features to make decisions easier for our users.
 * Decrease time for new engineers to make quality contributions. With clear contributor documentation, standard developer environments, and reduced integration periods, We intend to close the gap between developer engagement and first productive contribution.
 * Increase predictability and safety of deploying code changes. We plan to provide standard environments for developers and testers to make sure everyone is working from a common base. We want to use continuous integration (CI) to protect deployments of the Wikimedia platform and to 3rd-party MediaWiki installations from regressions and other detectable problems. We will increase our test coverage for integration and unit tests to make code changes more dependable without introducing regressions.
 * Decrease time to find and fix bugs. We will use automated testing and continuous integration to detect bugs and regressions before they are released. We want to improve logging and error reporting to make errors in production more visible and identifiable.
 * Decrease time to integrate and deploy new features. We will work to minimise the time needed to review new code. We want to use automated unit testing and automated code style checking to speed up code reviews on new features.
 * Decrease the complexity of installing and updating our platform for third parties. We want to improve the installation process to make it easier to setup MediaWiki and other Wikimedia service components. We also want to simplify updates so that everyone can benefit from new features, bug fixes and security improvements.

Architect our code, services and infrastructure for change and sustainability

 * Reduce the complexity of the platform. We want to improve the architecture of our platform to make it easier to maintain and understand. We will continue our work to define and separate out encapsulated components with well-defined interfaces. Decoupling subsystems will allow us to refactor and reimplement each component without destabilizing the entire platform. It will also make it easier to add new features.
 * Increase the scalability of the platform for future applications and new types of content, as well as a growing user base and amount of content. As the needs of our projects, contributors, and staff grows, we want to ensure that our platform to accommodate that growth. This not only means accommodating the growth of our users and content, but also supporting new use cases and the development of new features easily.
 * Increase ease and speed of feature development. With predictable, testable component interfaces, we can add new features more quickly without sacrificing reliability.
 * Increase security of the platform. We’ll use automated tools and best practices to evaluate the security of our software. We want to add features that protect the identity and privacy of our users and the integrity of our projects’ content.

Increase our technical capabilities to achieve our strategy

 * Increase feature parity among clients by structuring content and providing a full featured API. We want to enable access to the same tools and content independent of client - no matter the device, browser, application or screen size. Doing this requires adding structure and semantic meaning to our content. On top of this, we need to expose this data, as well as all the features of the platform, via a consistent, easy to use, and full featured API. This will allow all client developers to create powerful and rich experiences across desktop, mobile, voice and unanticipated future clients.
 * Increase equity and power of contribution tools. We want to support the contribution of more content types of content, including media, in more interactive ways and across all projects. This means making some existing tools - like templates - available to all projects and languages. It also means improving translation tools to remove silos of content. Finally, we also want to enable the creation of new tools which are designed to work for all projects and languages.
 * Increase equity and power of curation tools. Our community has built a wide array of gadgets, tools, and bots to make it easier to curate and patrol the content on our projects. We want to make these tools easier to use as well as bring these tools to all projects and languages. Better tools for all contributors will lead to richer content and a more equitable distribution of content across all projects.
 * Increase equity and power of collaboration tools. Our discussion tools are a crucial part of our platform for our users, communities, chapters and staff. Making our communication systems easier to understand and use allows our communities to be more inclusive. Providing new ways of communicate and manage communication will enable deeper collaboration and better curation of content. Improving channels between our organizations and communities allows us to understand the impact of our work and the needs of our users.
 * Increase reuse and distribution of content. We want to build features for distribution and syndication of content that make it easier to include or cite information in our projects while also encourage users to return to our projects and contribute directly. This work includes exposing standards based metadata, supporting easier embedding of content, and improving access to content and data using APIs.
 * Increase ease of developing data driven applications and features. Capturing content as structured data is critical for advanced applications, visualizations, search, and machine learning. This is also critical for and other Wikimedia projects today are used to train natural language processing (NLP) systems and provide data for personal assistants. We will look at tools and technologies to open up more of the knowledge in our content to AI systems.