MediaWiki Product Insights/Artifacts/KR 5.2: Simplify feature development

The main goal of KR 5.2 in FY2024-25 is to improve and clarify the interaction between MediaWiki's core platform and its extensions, skins, and other parts. Exploring and implementing the potential evolution of the MediaWiki system is a multi-year project, and this KR attempts to approach this systemic change through more manageable scope.

Our intent is to provide functional improvements to MediaWiki’s architecture that enable practical modularity and maintainability, for which it is easier to develop extensions, and to empower the requirements from the wider MediaWiki product vision. This work also aims to inform what should exist (or not) within core, extensions, or the interfaces between them. The year will be divided into two phases: a 5-month research and experimentation phase (initial KR), and a second phase where specific interventions are implemented, informed by the outcomes of the first phase.

From the annual plan: Identify by Q2 and complete by Q4 one or more interventions to evolve the MediaWiki ecosystem’s programming interfaces to empower decoupled, simpler and more sustainable feature development.

Context and challenges

The hooks and the extension registry systems have many use cases and needs, and are stretched into different forms to allow for multiple types of behaviors. Some of these create collisions, inconsistencies and unexpected behaviors, issues between extensions, and increase the level of difficulty when we attempt to change the system or implement new platform features. Over the years, there have been many ideas and projects to improve this system. Now that MediaWiki has a product vision and leadership in place, we have the opportunity to plan out the direction in which the evolution should go.

Phase 1 will concentrate on understanding the space and finding opportunities for improvements:

• Establishing the needs of the programming interfaces: Understanding how extensions communicate with the current system (such as the hooks, extension registry, Providers, etc.), determining what the general needs are, and deciding the scope of the product needs that the system should empower in the future.
• Choosing the architectural patterns with which we will evolve the system: Identifying the opportunities for intervention that support the product vision, which we will need to address during the implementation stages. The aspiration is to create a more modular system that allows us to better define the interfaces used by extensions and to allow for use cases that are not covered with the current system.

Focus and grounding

Practically speaking, we need to balance between looking at the low-level internal working of the system (hooks, extension registry, etc.) and the systemic requirements and capabilities needed in the larger sense from this project. The exploration stage allows us to look at the problem from multiple perspectives, both underlying "code behavior", and required overarching system behavior.

In order to focus and ground the process, we are exploring the idea of taking a more specific use case (or a series of a couple of use cases) and examining them to find actionable opportunities while thinking of the grander solution.

Notifications use case

One option is to look at the needed evolution of the internal patterns by examining the Notifications (a.k.a. Echo) extension. Notifications is one example that has challenges from multiple angles:

• It has a "business logic" that is split up between core and the extension that could be unified
• It functions as a platform: it allows other components and elements to utilize its interface (register new notification types)
• It purposefully injects itself (using hooks) into MediaWiki’s built-in notification process to change or stop it
• The implementation of its frontend is complex and mostly overloaded per skin and for mobile
• It has features and API modules that overlap with core behavior

The purpose of focusing on Notifications is not to say that the target is "just" to fix that extension; the point is to utilize the challenges above and see if we can focus on finding the patterns that could resolve these types of problems, since those are not unique to Notifications. By focusing on notifications we are aiming to ground ourselves so that this systemic change can produce realistic changes that are set to a relatively short timeline.

Details and updates

For more information about the ongoing work, the hypotheses, documents and questions, please see the details and updates sub page.