Hi Thomas, Thanks for your thoughtful response and concerns about MediaWiki's product approach. Let me clarify what we mean and address your key points. MediaWiki "as a product"
I understand why "product" sounds commercial, but our use of this term doesn't change our mission of free knowledge for all. The "product" lens is more of a framework for prioritization and decision-making. Treating MediaWiki "as a product" <https://www.mediawiki.org/wiki/Manual:What_is_MediaWiki%3F> simply means: - Shifting from loosely related projects to continuous, iterative improvement across the platform - Better understanding our users’ needs so that we may prioritize features based on user impact - Thinking strategically about MediaWiki's ongoing goal to support Wikimedia projects To emphasize, our domain exploration work identified some essential product values for MediaWiki + Wikimedia, including Community, Extensibility, Privacy, Transparency, and Open Source. Domain-driven design and complexity This work reflects the actual nature of what we're doing—making MediaWiki more sustainable and developer-friendly while preserving what makes it special. You're absolutely right that complexity has to live somewhere. The goal is to organize complexity within the platform so developers can build on it more easily. We believe that by creating better technical boundaries between logical steps (like managing wikitext, rendering pages, calculating derived data), we can improve the consistency, reliability, and sustainability of our platform. This will in turn make the platform more manageable for extension and tool developers. While in some cases this means taking a more opinionated approach on how folks can and should interact with the platform (such as introducing post-transaction events), we are being intentional with that evolution and keeping extensibility in mind. Thanks again for raising your questions and concerns – we plan to post a lot more on this topic, so keep an eye out for more write-ups <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts>, MediaWiki newsletters <https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports> and other announcements, too! Cheers, Halley *Halley Coplin* (she/her) Sr. Product Manager, MediaWiki Interfaces Wikimedia Foundation <https://wikimediafoundation.org/> On Wed, Jul 16, 2025 at 6:06 AM Thomas <[email protected]> wrote: > hi Daniel, > thanks for the clarifications. Indeed I didn't read properly > the entire document and therefore I was reading the first > passage merely from the perspective of the hook dispatcher / hook > handler perspective, while now I see the concern to minimize > the transactions exposed to the client. (at macroscopic level, so to say) > With regard to the second point "This clarifies the semantics of extension > callbacks invoked as a result of a change, particularly with respect to > transactional context." > it also makes complete sense when you are familiar with the topic (of after > the explanation) I don't know if there is a way to reword it for newcomers, > possibly not, at least as a list item. > > In general I was aware of the efforts to apply Domain-Driven Design > methodologies > to tackle the intricacies of the current code-base however I do not think > there is > a way to simplify MediaWiki in a significant way without reducing its > overall consistency and even potential > (which is the reason why extensions exist) unless indeed you don't > increase the > complexity in some other way, as a result indeed of the disambiguation > that I see you (as a team) are doing and which is of course a remarkable > work. > > So I just want to express my concern about the goal of making of MW or > also Wikipedia, > which as far as I understand is the organic and still on-going outcome > of a community of pioneers, professionals and volunteers, specifically a > "product", > as I have heard in the context of "evolving Wikipedia", which is > something that in my view implies a commercial logic (not fully > compatible with that of community) and especially something > which intrinsically discourages or hinders other uses except those > set or predefined, which again (from a logical point of view) > undermines the rationale for the extensions as something > which complement a software of which Wikipedia is one of > the applications, although the most notable. > > Of course I see that the refactoring/redesign work is being carried out > taking all necessary precautions and by qualified people, however in the > same time, > specifically for this reason, wouldn't be preferable to adjust the goal > statement or approach in order to reflect the actual nature of the work > rather than the commercial or administrative perspective ? > > Thank you again for the clarifications and all the best > (Thomas) > > > > > > > ---- On Tue, 15 Jul 2025 13:55:02 +0100 *Daniel Kinzler > <[email protected] <[email protected]>>* wrote --- > > Hi Thomas! > > Am Di., 15. Juli 2025 um 13:18 Uhr schrieb Thomas <[email protected]>: > > > > 1) here "Hooks are typically, but not always, invoked synchronously during > the main transaction, while the client waits for a response." -- shouldn't > be rather "while the caller waits" or "where the caller waits" instead of > "while the client waits" if with "client" you mean the hook dispatcher ? > > > Both, really. If the hook handler (or event listener) is executed > synchronously while the caller waits, that typically also means that the > client that made the web request is still waiting for a response. That's > the case because we only send the web response after the main transaction > is complete, otherwise we would not be able to inform the client about > errors. > > If on the other hand we delay invocation of the listener until after the > main transaction is complete, we can also defer it until after the response > has been sent to the client, to reduce latency. > > The implication is that listeners can be sure that the original change has > been persisted in the database, but it also means that if the listener > fails, this will be invisible to the client. > > This behavior is equivalent to what you would get from a hook handler the > schedules a DeferredUpdate, which is already the case for the majority of > handlers that perform database updates. > > 2) here "Events get delivered to listeners via a DeferredUpdate after the > main transaction was successful and the response has been sent to the > client. This clarifies the semantics of extension callbacks invoked as a > result of a change, particularly with respect to transactional context." do > you mean that in case of events the hook handlers cannot anymore modify the > source data before are saved, if that's needed for any reason ? Can you > also clarify more the second part of the paragraph ? > > > Yes, event listeners cannot modify data before it is saved. Events are > notifications about things that happened in the past. If you need to > intercept or manipulate an action, you cannot use events, you would just > keep using hooks for that, as before. Hooks that allow for the cancellation > of actions or manipulation of data will not be replaced by events (though > we may look into other ways to make them nicer). > > With respect to the invocation semantics, the idea is that events > guarantee that they are *always* invoked only after the transaction is > complete, and only if that transaction is successful. With hooks, there is > no such clarity - most hooks are invoked synchronously, but not all - some > are invoked in a DeferredUpdated. And this may change without notice, it's > not documented or guaranteed. That means that a hook handler that receives > e.g. the ID of a newly inserted revision has no guarantee that the > transaction won't be rolled back so that revision ID would vanish or might > even be re-used for a different revision later. > > I hope this clears things up a bit. Feel free to edit the manual pages to > make them more clear, it's a wiki! > > -- daniel > _______________________________________________ > Wikitech-l mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ > > > > _______________________________________________ > Wikitech-l mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
_______________________________________________ Wikitech-l mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
