I think this could be as simple as adding the following rules:

Is the level of specificity of some of the example CSS rules required, e.g. .mw-rcfilters-ui-filterTagMultiselectWidget-views-select-widget.oo-ui-widget.oo-ui-widget-enabled.oo-ui-selectWidget.oo-ui-selectWidget-unpressed.oo-ui-selectWidget-depressed.oo-ui-buttonSelectWidget ?

… gIven that the bugs are minor.

I've kicked off the request for a physical KaiOS device for @Edtadros.

Thanks for the great write up, @Isaac, and to Research for such deep consideration of how best to include everyone.

In T223206#5238087, @MNeisler wrote:

@phuedx - Do you know which user property controls the "group" preference for this question?

[Which] combinations of filters are popular?

In T223408#5198738, @Gilles wrote:

Ian Marlier participated in the site maps project as his own personal initiative, but it has always been out of scope for the Performance Team. And his knowledge of that project left with him, so we're not better equipped than anyone else to do something about this.

Per T209377#5197164 and T209377#5200890.

• Delete PageSplitTester and PageSplitTesterTest from Wikibase (this will move to Core in T209319)
• Delete PageRandomLookup and PageRandomLookupTest
• Delete related configuration variables from Wikibase

How frequently is live updates enabled?

@MNeisler: As discussed: I'll take How frequently to users change the limit and days parameters?

AIUI this isn't High priority but a nice to have. Is that correct, @bearND?

Ping @Jdlrobson (the extension's author IIRC).

Setting up a development environment could be as trivial as adding the following to MobileFrontendHooks::onOutputPageParserOutput:

This LGTM.

🎉🎉🎉

Increase in JS bundlesizes should be consistent with the removal of the size of ResourceLoader's mobile.startup module. Change in bytes shipped to client should be recorded.

There are a few nitpicks (their words) from Timo Tijhof on @Jdrewniak's change: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/RelatedArticles/+/502529/3/resources/ext.relatedArticles.cards/CardView.js

I feel comfortable signing this off in @ovasileva's absence.

In T220627#5125187, @Nuria wrote:

Moving to radar as further steps of code chnages to Quicksurveys to fix loading issues with JS should be done by (i think) @phuedx team?

💪

Document the oversampling behaviour for AMC on the schema's talk page so Tilman can understand it

Update the schema revision number in MobileFrontend and move to Minerva codebase
Sampling rate should be 100% if the user is AMC, otherwise use the configurable sampling rate
Log whether the user is in AMC mode using the new schema revision ID

Update the schema to have an AMC flag

Thanks to @Krinkle both for discussing this issue and for the prompt review and merge.

2. Add an annotation to https://grafana.wikimedia.org/d/000000566/overview?panelId=15&fullscreen&orgId=1 at the time when the change is deploying

AIUI this task has been blocked on a request for privileges on some (all?) of the Wikipedias. The request has stalled, insofar as it hasn't been rejected nor has it been resolved, since giving a test account such privileges on production wikis will be viewed with suspicion by the community and may result in unintended outcomes.

I feel comfortable signing this off in @ovasileva's absence.

Per T220751#5137468, above.

I'd meant to follow up on this:

In the interest of fixing the discrepancy (at the expense of punting the more general problem, captured in T65459: Allow configuration of the Minerva menu), can we update MediaWiki\Minerva\Menu\Definitions::insertRandomItem to use

I'll follow up with Kate Zimmerman and Megan Neisler about how the ReadingDepth instrumentation fits in with their priorities.

In T214715#5134590, @pmiazga wrote:

Editors can update URIs of menu items e.g. On Commons, Special:Random can be replaced with Special:Random/file (see T188697)

• override the Definitions::insertRandomItem() to use the message cache. Instead of hardcoding Special:Random, we can load the title from Mediawiki:Random-url

I'm comfortable signing this off. Although one AC isn't satisfied, there's at least one task covering the community request. I'll follow up on that task with a simple suggestion that could get it unstuck.

Editors can update URIs of menu items e.g. On Commons, Special:Random can be replaced with Special:Random/file (see T188697)

A menu can be converted to a JSON of template properties so that it can be rendered by JavaScript via Mustache

A menu itself be made of multiple menus e.g. left hamburger navigation has 4 menus right now in stable
A menu uses a [Mustache] template for rendering so that it can also be used on the client.
Menus should work without JS

A menu can have completely different contents in a given mode e.g. contributions might be in left menu on stable but in a new user menu that shows on hover in AMC mode

It should be possible for an extension to register a menu item in a certain menu without any knowledge of how the menu is rendered.

Also! Thanks, everyone!