The next significant phase of this work is blocked on T302358: [A/B Test] Run an A/B test to evaluate impact of Usability Improvements, because we'll want to know what the results of the test are before we discuss deployments.

The timing of this is up to @ppelberg. Whether this should be done before/simultaneously with/after the deployment of the Usability features (currently blocked on the A/B test's completion and evaluation) to the talk namespaces is up to him. IMO there is no inherent need to stagger this deployment. I suggest that it not be delayed very long, since its absence produces requests for t.

This is posted at https://www.mediawiki.org/wiki/Talk_pages_project/Usability/Analysis

I don't think that raw length should be the primary consideration. As eight digits is a reasonably foreseeable number of accounts, we might want to consider formatting the usernames for readability:

I wrote something at https://www.mediawiki.org/wiki/Help:Temporary_accounts Please link to it in all of the relevant messages. It might not be necessary eventually, but it will be helpful during the first year or so (until this becomes a familiar concept in the communities).

Should "If you log in or create an account..." say something like "If you log in or create a permanent account..." or "If you log in or create a regular account..." or "If you log in or create a personal account..."? People seeing this message will have a (temporary) account.

Proposed simple, translatable text:

Would it be helpful to link to something (e.g., https://www.mediawiki.org/wiki/Help:Temporary_accounts) in the new messages?

The (existing) first sentence in "For yourself" – "People on Testwiki can use this talk page to post a public message for you and you will be notified when they do." – should have a comma in the middle ("...for you, and you will be...").

@matmarex: https://www.mediawiki.org/wiki/Talk_pages_project/New_discussion/Empty_pages has seven different messages. You have four existing messages here. Have you checked to make sure the others don't need to be updated?

Because of the Vector 2022 deployment schedule, I think we should remove plwiki and zhwiki from this list.

@MNeisler, I'm assigning this back to you, with a request that you double-check the numbers to see whether this will be enough to produce skin-specific results for Vector 2010 and Vector 2022. At the moment, I believe that plwiki, hiwiki, nlwiki, ukwiki, azwiki, and zhwiki default to Vector 2010, and at the others, it's likely that about 20% of senior contributors have switched back to Vector 2010. If we need to add more to the list, then that's possible.

I've joined the conversation at fiwiki. I think this is do-able.

There is also a built-in opt-out button that makes it easy for people to opt out.

I've inquired at https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Ver%C3%A4nderung (one of the pages that would be affected by this change).

As soon as this new tag is available, @Dyolf77_WMF and I want to take a set of diffs to the French and English Wikipedias to see what they think of the result.

This was done weeks ago; it's since been deployed to everyone at these three wikis.

Requirements: Not arwiki, huwiki, cswiki (all of which already have this). Not huge wikis (if we use >10K active editors per month, then this excludes enwiki, dewiki, frwiki, jawiki, eswiki, and ruwiki). They need to be big enough to get a medium-to-high use of talk pages. Also, I believe that Peter would prefer the wikis in this test to be all Wikipedias.

These three: ~ ^ \ are all hard to type on an iPhone (English), because you have to click through to the third keyboard before you can find them.

I don't think that - (the hyphen-minus) is a good choice for the first character, because the same character is used to exclude items from a search, which could result in finding everything except the user you were looking for.

Testing note: This template/system only exists at the English Wikipedia.

Huwiki has offered to test this for us and to let us know if there are any problems or unexpected results. I recommend that we do this (just for the one wiki).

volunteers who might come to wonder why an edit made, with say, the source editor (where Edit Check will not be available) that includes a reference being added did not get tagged as such.

@Esanders, I have no strong views on how to divide it, or even if it needs to be divided. The English Wikipedia is half of traffic, though, so if there is any concern from an SRE viewpoint, then putting "enwiki" and "everyone else" in different buckets would be an easy way to spread things out. But if there's no technical concern, then they could all be done at once, at any time, as far as I'm concerned.

Once it becomes possible to edit <references />, will editing through {{reflist}} require rich editing of templates?

The visual editor has a couple of onboarding/informational bits:

@PrimeHunter, @Redrose64, and some other volunteers might be able to give some good advice.

Changing IP addresses is an issue for all users, not just temporary ones.

I believe this is related to Vector 2022.

Will this change the appearance of the whole page, if there is an "Add section" button, but there are no signed comments anywhere on the page?

I didn't make these edits. I believe that the steps to reproduce are just:

While Edit Check is (probably) limited to VisualEditor, I think this tag should be applied to all published edits.

Realistically, I don't expect to make any progress on this during the current fiscal year.

"Most subscribed to" is a terrible metric because it's easily gamed. Anyone (logged in) can involuntarily subscribe as many people as they want to a task. If you tell me that T89970 needs to have a hundred subscribers to win, I can accomplish that in less than five minutes, without consent (or often even knowledge) of the people I "subscribe" to it.

About external links:

This is done and deployed. A volunteer from kowiki has asked that this style be used there, too.

This feature has been deployed to all wikis except fiwiki, which was so late in getting the Reply tool that we skipped them during this round. That deployment can be done at any time.

if someone is trying to add references to the lead, they should probably be informed of LEADCITE and told they should probably place them in the body instead.

I'd add to @Sdkb 's list:

NPOV is not a tractable problem for an automated check, especially if you are looking only at new additions and not at the overall effect. If you are looking for other ideas, consider these:

This is what I'm seeing today in Safari/macOS at enwiki.

Some ideas:

I've added a longer description to https://meta.wikimedia.org/wiki/Tech/News/2023/03

Nobody can make new invalid signatures. However, we haven't get disabled the old/existing signatures. There is no timeline to get this done. It could be years from now.

This can be re-opened in the future if there is more interest.