Hey all, A quick update from me about the work of the Asynchronous Content Fragments working group. *TL;DR* We're meeting each week to talk about adding async content support to MW. This week we discussed possible upper-level use cases, with initial thoughts documented on this page <https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Asynchronous_content_fragments#Draft_use_cases_and_their_sources>. Comments welcome! *Context* The overall goal <https://phabricator.wikimedia.org/T282585> is to explore, decide on, and build a way to include asynchronously-available content fragments in MediaWiki pages, to allow new forms of content (like Wikifunctions) and a faster, less tightly-coupled design for MediaWiki overall. The working group (Subbu and C. Scott from Content Transformation, Tim from Platform, Moriel from Architecture, and me from Abstract Wikipedia) exists to turn the Decision Statement Overview <https://docs.google.com/document/d/1kU7a5V-exubbXcyyMA0jKlqioQkoRptexgoWrZovnpE/edit#heading=h.5tjhe7ka6tr7> agreed by the Technical Decision Forum into a set of options for implementation <https://www.mediawiki.org/wiki/Technical_Decision_Forum/Technical_Decision_Making_Process#Research_and_Prototyping_Stage_(Timeboxed_with_check-ins_every_two_weeks)> (as will be finally agreed in a Decision Record). *Work this week* This week we discussed some use cases that I proposed. There was a lot of talk around the differing needs in what readers, most API consumers, search engines, *etc.* will want vs. what editors (and other logged-in users) will need to be effective. In particular, we considered the need for anti-abuse features, Notifications, Recent Changes and Watchlist entries to all trigger immediately (as is current behaviour) despite not having the full result yet, and then needing the final renders to update wherever they're stored. This will be complicated, and vary by specific use case. For example the product need for immediacy will be very high and second results not wanted (e.g. talk page notification e-mails should be sent immediately and not wait, but also not be duplicated later); in others, it will be lower and so things can wait a little bit for some things (e.g. link notifications can wait a few minutes). We also talked about the need for having default values, placeholders, timeouts, and handling errors, and whether that should be controlled by MediaWiki centrally or if each fragment provider could be synchronously called to provide default/placeholders as needed. Much more of this will be discussed next week. Hope this is of interest. If you have thoughts or comments, please do let us know on the discussion page <https://www.mediawiki.org/wiki/Talk:Abstract_Wikipedia_team/Asynchronous_content_fragments> or directly. Yours, -- *James D. Forrester* (he/him <http://pronoun.is/he> or they/themself <http://pronoun.is/they/.../themself>) Wikimedia Foundation <https://wikimediafoundation.org/>