MediaWiki Product Insights/Artifacts/KR 5.2: Simplify feature development/Details and updates
This will contain links to results, documents, or any updates for the exploration to find architectural patterns that simplify feature development in MediaWiki platform. Please add this page to your watchlist if you’re interested in this exploration, and feel free to engage us in the talk page.
Work in Q1
[edit]Initially, we set out to better understand how developers are interacting with the platform from two perspectives: 1) Examine how core mechanisms support extensions and where those entry points can be improved, and 2) Identify existing feature(s) that would benefit the most from directly redesigning the architecture to make it more modular and flexible. These initiatives were captured in two hypotheses executed in Q1 FY24-25:
- [Complete] Hypothesis 5.2.1: If we make a classification of the types of hooks and extension registry properties used to influence the behavior of MediaWiki core, we will be able to focus further research and interventions on the most impactful (Read the report)
- [Complete] Hypothesis 5.2.2: If we explore a new architecture for notifications in MW core and Echo, we will discover new ways to provide modularity and new ways for extensions to interact with core. (Read the report)
Work in Q2
[edit]In Q2, we followed up on some of the recommendations that came out of the investigations conducted in Q1.
- [Complete] Hypothesis 5.2.3: If we conduct an experiment to reimplement at least [1-3] existing Core and Extension features using a new Domain Event and Listener platform component pattern as an alternative to traditional hooks, we will be able to confirm our assumption of this intervention enabling simpler implementation with more consistent feature behavior. (Read the report)
- [Complete] Hypothesis 5.2.4: If we create proofs of concept and service level interface proposals that demonstrate better notification feature support through simplified, modular platform capabilities, we will be able to scope the expected effort to implement the proposed changes in production and confirm what is most feasible and valuable to implement this year. (Read the report)
Work in Q3
[edit]In Q3, we continued the implementation of Domain Events and started implementation of Notifications in MediaWiki core.
- [Complete] Hypothesis 5.2.5: If we model at least one more page state change (e.g. PageDelete) as a PHP event and drive further adoption of in-process domain events across MediaWiki components and extensions currently utilizing event-like hooks, then we will build confidence in events as a platform sustainability pattern by improving component boundaries, improving interface flexibility, and reducing high risk boilerplate code. (Read the report)
- [Complete] Hypothesis 5.2.6: If we explore designing an architecture for serializing and broadcasting events generated within MediaWiki core, we will create a foundation for offering first class event support that will enable us to consume events outside of the originating MediaWiki PHP process (e.g. JobQueue, EventBus). This will make MediaWiki data more reusable beyond the MediaWiki platform.
- [Complete] Hypothesis 5.2.7: If we identify and align on a set of domains that can be used for MediaWiki platform events by the end of Q3, we will have an initial map of core component boundaries and can improve consistency across MediaWiki interfaces by utilizing the same domains for the MediaWiki REST API modules.
- [Complete] Hypothesis 5.2.9: If we design an interface and domain model for notifications as a platform-level capability in MediaWiki core, we will be able to reduce complexity and improve developer experience for feature teams, by using interface-driven design to ensure sustainability and consistency. (Read the report)
- [Complete] Hypothesis 5.2.10: If we implement an interface and domain model for notifications in MediaWiki core by re-using functionality from Echo, we will be able to validate the interface and model design, by porting at least two notification types and maintaining backwards compatibility to minimize disruption. (Read the report)
Work in Q4
[edit]- [in progress] Hypothesis 5.2.11: If we finalise the new interface for Notifications in MediaWiki core, we will be able to deprecate the existing interfaces used by Echo and move to more sustainable Notifications feature development by moving extensions to an interface that is simpler and more decoupled.
- [in progress] Hypothesis 5.2.12: We will effectively demonstrate a sustainable domain event pattern if we complete modeling, implementation, and adoption of in-process PHP domain events for all page state changes (update, delete, move, create, undelete, protection, visibility) and document the intended next steps to achieve the long term value of this work. (Read the report)
- [Complete] Hypothesis 5.2.13: If we update the EventBus extension to utilize in-process PHP events for page state changes and conduct initial research to verify the feasibility of implementing a long-lived PHP Kafka listener, we will demonstrate that domain events are a viable option for both broadcasting and consuming events for use cases beyond MediaWiki. (Read the report)