So far, on the notable events I observed:

• a few thanks from users when I posted.
• One user at az.wp wrote:

It's a beautiful interface. I saw it on Trwiki and I really liked it.

• A few reactions at German Wikipedia, where individuals shared their opinion, around "these changes aren't a good fit for the wiki." More context was provided, to put the change on a bigger level, and, along with one 'supportive) user, I remind them the possibility of option(gout on an individual basis.

T354395: Communication plan for deployment of "add a link" to 18th round of wikis (en.wp and de.wp) is under progress, we can work on this task so that the configuration option will be available.

Announcements have been made to the wikis (T349547).

In T350622#9727420, @Samwalton9-WMF wrote:

Is anything logged if the user attempts to add a blocked URL and then gives up?

AFACT, it is when they hit "publish". The attempt is blocked and logged, even if not finished. To be confirmed.

Checking after MoveComms-Support was added to this task: what kind of support do you need, if any?

Radio buttons or toggles are better than a checkbox with an "x". This "x" will certainly be one of the first obvious feedback we will get.

I announced it in TN for a deployment starting April 22.

To be covered during the next sprint. I'll cover User-notice

Looks good to me!

As we deployed the feature on Discussion Tools/VE for talk pages with a way for users to opt-out, I think we are safe to deploy, as users who opted-out will remain opted-out from auto-subscription no matter which editing surface they use, correct?

I just published the report: https://www.mediawiki.org/wiki/Structured_Discussions/Deprecation/Report

As a reminder, the extension's name is CommunityConfiguration, while the public name is Community Configuration (without 2.0 anymore).

Special:Log/abusefilterblockeddomainhit lists all attempts to add a blocked by URL to a wiki. Peter and I discussed this yesterday and agreed that a new tag might not be needed because of the log.

In T360493#9646930, @Esanders wrote:

we usually do this by nesting the messages.

Do you mean editing messages locally?
If so, as we are progressively moving to Community Configuration, I think it would be better to have it inside EC's configuration.
If not, can you clarify, please?

The link we will add to know more must be community configurable, and a fallback link should be provided.

Debrief with @jijiki:

The read-only time can happen between 14:00 and 14:30 - the time window allocated by SRE - depending on how smoothly the process goes. As a consequence, the banner shown on wikis should stay longer: at the moment, it is displayed from 13:30 to 14:01, but it should be scheduled to last until 14:30. SRE and Movement Communication reach at each other to declare the read-only done, and then the banner is deactivated.

I updated the documentation accordingly.

I just tested it in production, and it seems to be working as we designed it.

The few reactions I observed from communities came from users who thanked me for the information message I sent last Friday.

Per agreement, https://www.mediawiki.org/wiki/Growth/Community_Spotlight is now https://www.mediawiki.org/wiki/Growth/Community_Updates.

The message was updated to remove the idea of a test. As everything is okay, I can continue with the next steps.

@jijiki, I'll be your host on this journey.

Thank you @jijiki! We will start the process very soon.

For Tech News:

The [[mw:VisualEditor_on_mobile|mobile visual editor]] is now the default editor for users who never edited before, at a small group of wikis. [[mw:VisualEditor_on_mobile/VE_mobile_default#A/B_test_results | Research ]] shows that users using this editor are slightly more successful publishing the edits they started, and slightly less successful publishing non-reverted edits. Users who defined the wikitext editor as their default on desktop will get the wikitext editor on mobile for their first edit on mobile as well.

I am waiting for the two last tasks to be finish before resolving this one.