Given the results in https://www.mediawiki.org/wiki/Talk_pages_project/Usability#Analysis_#2:_Impact and the noticeable lack of complaints from the Wikipedias involved in the A/B test, I think it would be plausible to have an all-at-once deployment.

@cscott, is that Hebrew Wikivoyage, or Hebrew Wikipedia? I'm not sure that hewikivoyage has enough users to meet your goals (though the most active editor there is very helpful, so they would probably be willing to answer any questions you have).

I don't know how much this matters, but 13 and 666 are superstitious numbers in Western culture, and might be off-putting to some users.

@Tacsipacsi, would you please add the accessibility problems to https://www.mediawiki.org/wiki/Extension:Graph/Plans#8)_What_requests_(e.g._wishes)_have_volunteers_made_over_time_to_improve_support_for_storing_and_representing/visualizing_data_on-wiki? That's an important consideration, and I don't think anyone else has mentioned it yet.

Thanks for your help. I appreciate your help. I haven't yet talked to any of the devs about it, but I figured that it was better to prevent unfortunate results first and find an elegant solution second.

There are two main options:

• a central page at [[mw:Edit_check/False_positives]], with links to pages on how to configure it, etc.
• local pages, e.g., [[Help:Edit_check]], and the talk page could be used for reporting false positives.

I prefer "serial" (even though it won't be perfectly in order; even though some numbers will be skipped). Because of the format (which we expect to reach approximately User:~2023-12345-678 in a typical year), the serial numbers in the middle of the year will look something like this:

@Tacsipacsi, do you already know who/how graphs is used at huwiki? I'm most interested in hearing from the editors who use it regularly.

See also https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Council&oldid=1173895091#User_Stats_for_activity_in_projects

I've been looking through [[mw:Neil's spreadsheet]], and have narrowed down the options significantly. Among the Wikipedias, I excluded those that have too few new editors each month, too few edits from the mobile site, and too few edits in the visual editor, as well as a few wikis for particular linguistic or local considerations (e.g., to avoid overloading the same community with requests from multiple teams).

There's another request for this at mw.org. We should get this done.

If you'd like to put this in Tech/News, then I think this wording would be appropriate:

In the past, at enwiki, there have been a couple of editors who objected to this kind of merging. Some of the discussions will be in the archives of [[w:en:WT:CITE]], but if memory serves, it irritated them to see the reference numbers "out of order". That is, they disliked Sentence.[1] Sentence.[2] Sentence.[1] and preferred Sentence.[1] Sentence.[2] Sentence.[3], even though [1] and [3] were the same source.

@abi_ I think that one year is the best place to start. It will solve most of the problem, with very little risk of unsubscribing an occasional translator. I would even be happy to see 18 months or 2 years of inactivity as the cutoff.

"Remember the last option selected" is the usual default for https://www.mediawiki.org/wiki/VisualEditor/Single_edit_tab and this has occasionally created confusion, especially for less experienced users. They end up switching away from their favorite (voluntarily or otherwise) and then can't find their way back.

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 it.

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: